Kurumsal yedekleme: kopyadan geri dönüş planına

Yedeğin amacı dosya saklamak değil, geri dönebilmektir

Yedek dosyasının varlığı, işletmenizin hizmete geri dönebileceğini tek başına göstermez. Web dosyaları sağlamken veritabanı eski kalmış olabilir; e-posta kutuları plana hiç dahil edilmemiş olabilir. Yedekleme stratejisinin gerçek sınaması, veriyi kullanılabilir bir ortamda geri yüklemektir.

Önce hangi hizmetlerin işinizi durdurabileceğini listeleyin. Web sitesi, sipariş verileri, müşteri dosyaları, e-postalar, DNS yapılandırması ve lisans bilgileri farklı yöntemlerle korunabilir. Her kalemin sorumlusunu belirleyin.

Ne kadar veri kaybı ve ne kadar bekleme kabul edilebilir?

RPO, kabul edebileceğiniz veri kaybının zaman karşılığıdır. Günde bir yedeklenen ve son yedeği gece alınmış bir sitede gün içindeki yeni kayıtlar kaybedilebilir. Sık sipariş alan bir uygulamanın ihtiyacı, seyrek güncellenen tanıtım sitesinden farklıdır.

RTO, olay sonrasında hizmeti ne kadar sürede geri getirmeyi hedeflediğinizdir. Yedeği indirme, yeni ortam hazırlama, veritabanını geri yükleme, DNS ve uygulama testleri bu süreye dahildir. RPO ve RTO hedeflerini bir sayı olarak yazın; bunun sözleşmeyle garanti edilen süre mi yoksa kurum içi hedef mi olduğunu ayırın.

Bağımsız kopyalar oluşturun

Yaygın 3-2-1 yaklaşımı; üretim verisiyle birlikte üç kopya, farklı iki ortam ve bunlardan birinin ayrı bir konumda bulunması fikrine dayanır. Amaç, tek bir arıza veya hesap ihlalinin bütün kopyaları etkilemesini önlemektir. İhtiyaca göre çevrimdışı ya da değiştirilemez kopyalar da değerlendirilebilir.

Aynı sunucudaki başka bir klasör bağımsız yedek sayılmaz. Aynı erişim bilgileriyle silinebilen bütün kopyalar ortak bir risk taşır. Yedek depolamasına erişimi sınırlayın; şifreleme kullanıyorsanız anahtarın güvenli kurtarma yolunu da planlayın.

Yedek hizmetini satın alırken bunları sorun

• Dosyalar, veritabanları ve e-postalar aynı plana dahil mi?
• Yedek ne sıklıkta alınır ve kaç sürüm tutulur?
• Yedekler nerede, hangi erişim yetkileriyle saklanır?
• Tek dosya, tek hesap veya tam sunucu geri yüklemesi yapılabilir mi?
• Başarısız yedek işi nasıl fark edilir ve kime bildirilir?
• Geri yükleme işlemi nasıl talep edilir; ayrıca ücretli mi?
• Hizmet iptalinde yedeklere ne olur?

Anlık görüntü (snapshot) hızlı geri dönüş için yararlı olabilir. Ancak depolama bağımlılıkları ve saklama koşulları nedeniyle her snapshot bağımsız bir yedek değildir. RAID ve disk çoğaltma da yanlışlıkla silme veya zararlı değişiklikten korunmak için tek başına yeterli olmaz.

Geri yükleme tatbikatını takvime koyun

Temsil edici bir yedeği üretimden ayrı ve erişimi sınırlı bir test ortamına geri yükleyin. Dosya bütünlüğünü, veritabanı bağlantısını, kullanıcı girişini ve temel iş akışlarını kontrol edin. Gerçek müşterilere test e-postası veya ödeme isteği gönderilmesini önleyin.

İşlemi başlatan kişinin kim olduğunu, toplam süreyi, hangi adımda sorun yaşandığını ve kullanılan yedeğin tarihini kaydedin. Yeni uygulama sürümü, altyapı değişikliği veya önemli veri artışı sonrasında tatbikatı tekrarlayın. Kişisel veri içeren test kopyalarının erişim ve silme sürecini de belirleyin.

Olay anında kullanılacak kısa planı yazın

Planınız olayın doğrulanması, etkilenen sistemin sınırlandırılması, kullanılacak temiz yedeğin seçimi, geri yükleme, işlev testleri ve iletişim adımlarını içermelidir. Yalnızca teknik ekip değil, müşteriye veya kurum içine kimin bilgi vereceği de belli olmalıdır.

Yedekleme kapsamınızı seçerken güven merkezindeki sorumluluk tablosunu kullanabilirsiniz. Site taşımadan önce de güncel yedeğinizi alın; taşıma bir yedekleme stratejisinin yerine geçmez.

RPO ve RTO için örnek bir olay çizelgesi

Bu zamanlar eğitim amaçlıdır; hizmet taahhüdü veya gerçek müşteri olayı değildir. Son kullanılabilir yedek 09.00'da alınmış, olay 10.30'da başlamış ve kritik işlevler 11.15'te doğrulanmış olsun.

RPO/RTO işin kabul ettiği hedeflerdir; olayda hesaplanan süreler hedeflere karşı değerlendirilen sonuçlardır. Dosyanın hızlı kopyalanması, sipariş, e-posta ve kullanıcı erişimleri doğrulanmadan hizmetin toparlandığını göstermez. Planlama çerçevesi için NIST SP 800-34 iş sürekliliği kaynağını inceleyebilirsiniz.

Geri yükleme tatbikatını bu kayıtla kapatın

Yedek tarihi ve saat dilimi:
Kapsamdaki dosya / veritabanı / e-posta:
Hedef test ortamı ve sorumlu:
Geri yükleme başlangıç / bitiş zamanı:
Doğrulanan giriş, form, sipariş ve posta işlemleri:
Eksik veri veya başarısız işlev:
RPO / RTO hedefi ve karşılaştırma sonucu:
Düzeltme işi, sorumlu ve bir sonraki test:

Üretime geri yazmadan önce ayrı bir ortamda doğrulama yapın. E-ticaret veya e-posta uygulamasının test kopyasında gerçek bildirim ve ödemeleri tetiklemeyin. Geri yükleme yetkisini, şifreleme anahtarının erişimini ve yedek bütünlüğünü de tatbikata dahil edin.