Yedekleme politikası nasıl kurulur?

Çoğu kurumda bir yedekleme yazılımı kuruludur ve her gece bir iş çalışır. Sorun, o işin başarıyla bitip bitmediğine ve alınan kopyadan gerçekten dönülüp dönülemeyeceğine kimsenin bakmamasıdır. Kayıp yaşandığında yedeğin eksik, bozuk veya fidye yazılımıyla birlikte şifrelenmiş olduğu anlaşılır.

Yedekleme politikası bu belirsizliği kaldıran yazılı bir karardır: neyin, ne sıklıkla, nereye, ne kadar süreyle yedekleneceğini ve geri dönüşün nasıl test edileceğini tanımlar.

Politikanın temeli her sistem için sorulan iki sorudur.

• Kaybedilebilir veri miktarı (RPO): son yedekten sonra oluşan veriyi kaybetmek ne kadar süre için kabul edilebilir? Bir saat, bir gün, bir hafta?
• Geri dönüş süresi (RTO): sistem durduğunda ne kadar sürede tekrar çalışır hâle gelmeli? Muhasebe sunucusu için bir gün kabul edilebilirken, üretim hattını yöneten sistem için bir saat bile uzun olabilir.

Bu değerleri bilgi işlem tek başına belirlememeli; her sistemin sahibi olan birimle birlikte yazılı hâle getirilmelidir.

Yedeklerin nerede duracağı için yaygın kabul gören kural basittir: verinin en az üç kopyası olsun, bu kopyalar iki farklı ortamda dursun ve bir kopya kurumun dışında saklansın.

• Birinci kopya canlı sistemin kendisidir.
• İkinci kopya aynı binadaki yedekleme cihazında veya NAS üzerinde durur; hızlı geri dönüş bu kopyadan yapılır.
• Üçüncü kopya bulutta veya başka bir lokasyondadır; yangın, su baskını ya da hırsızlıkta ayakta kalan kopya budur.

Fidye yazılımları ağdan erişilebilen yedekleri de şifreler. Bu yüzden kopyalardan en az birinin değiştirilemez (immutable) olması veya ağdan fiziksel olarak ayrılmış olması gerekir. Günümüzde bu şart, 3-2-1 kuralının pratikteki dördüncü maddesidir.

Her gün alınan yedeği sonsuza kadar saklamak hem pahalıdır hem de gereksizdir. Saklama planı, hangi yedeğin ne kadar süre tutulacağını belirler.

Yasal saklama süreleri sektöre ve veri türüne göre değişir. Muhasebe kayıtları, personel dosyaları ve kişisel veriler için süreleri hukuk birimiyle birlikte belirleyin. Kişisel verilerde saklama süresinin dolduğu kopyaların imha edilmesi de politikanın parçasıdır.

Politikanın en çok atlanan adımı budur. Tatbikat, gerçek bir kayıp yaşanmadan önce yedekten dönülebildiğini ve bunun ne kadar sürdüğünü gösterir.

• Üç ayda bir, kritik sistemlerden birini test ortamına yedekten geri yükleyin.
• Geri yüklemenin ne kadar sürdüğünü ölçün ve hedeflenen geri dönüş süresiyle karşılaştırın.
• Uygulamanın gerçekten açıldığını ve verinin tutarlı olduğunu sistemin kullanıcısına doğrulatın.
• Sonucu tarih, süre ve karşılaşılan sorunlarla birlikte kayda geçirin.

Hiç geri yüklenmemiş bir yedeğin çalıştığını varsaymak, politikadaki en büyük risktir.

Yedekleme işleri sessizce başarısız olabilir: disk dolar, bir parola değişir, bir sunucu kapsam dışında kalır. Her sabah yedek raporuna birinin bakması ve başarısız işin aynı gün düzeltilmesi gerekir.

• Başarısız yedek işleri için otomatik e-posta veya mesaj bildirimi kurun.
• Yeni kurulan her sunucunun yedek kapsamına alındığını devreye alma kontrol listesine ekleyin.
• Politikanın sahibi olan kişiyi ve yedeğini isimle yazın.

• Sistem envanterini çıkarın ve her biri için kaybedilebilir veri ile geri dönüş süresini yazın
• Kopyaları 3-2-1 kuralına göre yerleştirin, en az birini değiştirilemez yapın
• Günlük, haftalık, aylık ve yıllık saklama sürelerini belirleyin
• Üç ayda bir geri dönüş tatbikatı yapın ve sonucu kaydedin
• Başarısız yedekler için bildirim kurun ve sorumluyu isimle atayın
• Politikayı yılda bir, altyapıdaki değişikliklere göre gözden geçirin