Yazılımda yedekleme ve felaket kurtarma planı

Yedekleme, herkesin önemli olduğunu bildiği ama çoğu şirkette yalnızca kâğıt üzerinde var olan bir konudur. Sunucuda bir yedekleme görevi tanımlanmıştır, dosyalar bir yere yazılmaktadır ve kimse yıllardır o dosyaları açmamıştır. Bir arıza anında ortaya çıkan gerçek genellikle acıdır: yedekler bozuktur, eksiktir ya da geri yüklemek düşünülenden çok daha uzun sürer.

Önce iki sayı belirlenir

Teknik çözüm seçmeden önce iki soru cevaplanmalıdır. Birincisi: en fazla kaç saatlik veri kaybını göze alabilirsiniz? Gece yarısı yedek alan bir sistemde öğleden sonra yaşanan bir arıza, yarım günlük veriyi siler. Bu kabul edilebilir mi?

İkincisi: sistem ne kadar süre kapalı kalabilir? Yedekten dönmek dosyaları kopyalamakla bitmez; sunucu kurulumu, veri tabanı geri yüklemesi, ayarların yapılması ve kontrol adımları da süreye dâhildir.

Bu iki sayı, yedekleme sıklığını ve yöntemini doğrudan belirler. Bir saatlik kayıp kabul edilemiyorsa gece yedeği yetmez; sürekli çalışan bir kopyalama kurgusu gerekir. İki saat içinde ayağa kalkmak gerekiyorsa, yedeğin bulunduğu yerin ve geri yükleme adımlarının buna uygun olması şarttır.

Üç kopya kuralı

Yedekleme konusunda yaygın kabul gören basit bir kural vardır: verinin en az üç kopyası olsun, bu kopyalar en az iki farklı ortamda dursun ve bunlardan en az biri fiziksel olarak başka bir yerde bulunsun.

Aynı sunucunun ikinci diskine alınan yedek, sunucu arızasına karşı korur ama yangına, hırsızlığa ya da sunucunun tamamen erişilemez hâle gelmesine karşı korumaz. Aynı veri merkezindeki ikinci sunucu da benzer şekilde sınırlıdır. Bu yüzden yedeklerden en az birinin farklı bir sağlayıcıda ya da farklı bir fiziksel konumda durması gerekir.

Fidye yazılımına karşı değiştirilemez yedek

Klasik yedekleme kurgularının son yıllarda ortaya çıkan açığı şudur: sunucuya erişen bir saldırgan, bağlı duran yedek diskindeki dosyaları da şifreleyebilir ya da silebilir. Yedek sunucuya bağlı olduğu sürece saldırının kapsamı içindedir.

Buna karşı iki önlem vardır. Birincisi, yedeklerin yazıldıktan sonra değiştirilemez olarak işaretlenmesidir; bu özellik birçok bulut depolama hizmetinde bulunur ve belirlenen süre dolmadan dosyanın silinmesini engeller. İkincisi, yedek alan hesabın eski yedekleri silme yetkisinin olmamasıdır. Silme işlemi ayrı ve daha dar bir yetkiyle yapılır.

Geri yükleme denenmemişse yedek yoktur

Bu yazının en önemli cümlesi budur. Bir yedeğin varlığı, geri yüklenebildiğini kanıtlamaz. Bozuk dosya, eksik tablo, yanlış sürüm ya da unutulmuş bir bağımlılık yüzünden geri yükleme başarısız olabilir ve bu ancak denendiğinde anlaşılır.

Bu nedenle düzenli bir geri yükleme tatbikatı yapılmalıdır. Tatbikat şunları ölçer: geri yükleme ne kadar sürdü, hangi adımlar belgede eksikti, veri eksiksiz geldi mi, uygulama geri yüklenen veriyle çalıştı mı? Tatbikat canlı sistem üzerinde değil, ayrı bir ortamda yapılır ve sonucu yazılı olarak kaydedilir.

Neyin yedeklendiği de yazılı olmalı

Yedekleme planı yalnızca veri tabanını kapsamaz. Yüklenen dosyalar ve görseller, uygulama ayarları, sunucu yapılandırması, alan adı ve sertifika bilgileri, dış servislerin erişim anahtarları da listede olmalıdır.

Veri tabanı eksiksiz geri gelse bile ürün görsellerinin bulunduğu klasör yedeklenmemişse site eksik çalışır. Benzer şekilde, erişim anahtarları yalnızca eski sunucuda duruyorsa entegrasyonlar geri yükleme sonrasında çalışmaz. Bu kalemlerin tamamı tek bir belgede listelenmeli ve her yeni bileşen eklendiğinde belge güncellenmelidir.

Felaket anında kim ne yapar

Teknik hazırlığın yanında bir de insan planı gerekir. Arıza fark edildiğinde kime haber verilir, kararı kim verir, müşterilere ne zaman ve nasıl bilgi verilir? Bu soruların cevabı arıza sırasında aranmaz.

Plan kısa olmalı ve erişilebilir bir yerde durmalıdır. Yalnızca arızalı sistemin içinde duran bir acil durum belgesi, tam da ihtiyaç duyulduğu anda okunamaz. Bir çıktısının alınması ya da ayrı bir ortamda tutulması, basit olduğu kadar işe yarayan bir önlemdir.

Yedeğin alındığını kim kontrol ediyor

Yedekleme görevleri sessizce durabilir: disk dolar, parola değişir, sertifika süresi biter. Görev çalışmadığında kimse bir şey fark etmez, çünkü başarısızlığın görünür bir etkisi yoktur. Arıza günü ise son yedeğin aylar öncesine ait olduğu ortaya çıkar.

Bu yüzden izleme, yedeklemenin ayrılmaz parçasıdır. En az iki şey ölçülmelidir: son başarılı yedeğin ne zaman alındığı ve yedek dosyasının boyutu. Boyut kontrolü önemlidir; görev hatasız tamamlanmış görünse de içeriği boş olan bir dosya üretmiş olabilir. Beklenen aralığın dışına çıkan her yedek bildirim üretmelidir.

Geliştirme ortamına kopyalanan veri

Yedekler çoğu zaman test ortamını doldurmak için de kullanılır ve bu, farkında olunmayan bir risk üretir: canlı müşteri verisi, güvenliği daha zayıf bir ortama taşınmış olur. Test ortamında gerçek telefon numaralarının bulunması, yanlışlıkla gönderilen bir toplu e-postanın gerçek müşterilere ulaşması anlamına gelebilir.

Doğru yaklaşım, canlıdan kopyalanan verinin test ortamına girerken maskelenmesidir. Ad, telefon, e-posta ve adres alanları gerçeğe benzer ama gerçek olmayan değerlerle değiştirilir. Böylece test anlamlı veriyle yapılır, kişisel veri ise canlı ortamın dışına çıkmaz.