Görsel: Pixabay · Pixabay Lisansı
Temel kural
Yedek almak yeterli değildir. Geri yüklenebildiği kanıtlanmamış yedek, yedek sayılmaz.
Yılda en az bir kez gerçek bir geri yükleme testi yapın. Test edilmeyen yedeklerin bozuk çıkma ihtimali düşündüğünüzden yüksektir.
Neyin yedekleneceğini listeleyin
Veritabanları. En bariz olanı ve genellikle tek yedeklenen şey.
Kullanıcı yüklemeleri. Görseller, belgeler ve ekler. Bunlar veritabanında değildir ve çoğu yedekleme planında atlanır.
Yapılandırma dosyaları ve ortam değişkenleri. Bunlar olmadan sistem ayağa kalkmaz.
Sertifikalar ve anahtarlar.
E-posta verisi, kullanılıyorsa.
Sıklık ve saklama
Değişim hızına göre belirleyin. Günlük yedek çoğu iş uygulaması için yeterlidir.
Kaç gün geriye gidebileceğinizi tanımlayın. Bir hatanın fark edilmesi günler alabilir; yalnız son yedeği tutmak yetersizdir.
Haftalık ve aylık kopyalar tutmak, uzun süre fark edilmeyen bozulmalara karşı koruma sağlar.
Dış kopya şart
Yedek aynı sunucuda duruyorsa, sunucu kaybedildiğinde yedek de kaybolur.
En az bir kopya farklı bir fiziksel konumda olmalıdır. Kendi yedekleme düzenimizde sunucuda günlük yedek alınıyor ve ayrıca her gün yerel bir makineye fark kopyası çekiliyor; yerel kopya hiçbir dosyayı silmiyor.
Bulut kopyası eklemek, üçüncü bir katman olarak değerlidir.
Sessiz başarısızlık riski
Yedekleme işleri sessizce bozulur. Disk dolar, izin değişir, bir yol adı kayar.
Bu yüzden yedekleme betiği başarı ve başarısızlık bildirimi göndermelidir. Yalnız günlük dosyasına yazan bir sistemde, arızayı ihtiyaç anında öğrenirsiniz.
Yedek dosyalarının boyutunu izleyin. Aniden küçülen bir yedek, içeriğin boş olduğunun işaretidir.
İzin tuzağı
Bazı dizinlere yalnız yetkili kullanıcı erişebilir. Betikteki tek bir komutu yetkili çalıştırıp diğerlerini çalıştırmamak, sessiz hatalara yol açar.
Bu durumda kontroller izin hatası yüzünden boş sonuç döndürür ve betik dosyaların eksik olduğunu sanır. Betiklerinizde erişim kontrollerini gerçekten doğrulayın.
Geri yükleme senaryosu
Yalnız dosyaları geri koymak yetmez; sistemin nasıl ayağa kaldırılacağı yazılı olmalıdır.
Hangi sırayla hangi servis başlatılır, hangi yapılandırma gerekir? Bu belge kriz anında en değerli varlığınızdır.
Geri yükleme süresini ölçün. Ne kadar sürede ayağa kalkabileceğinizi bilmek, iş sürekliliği planının temelidir.
Silme öncesi disiplin
Üretimde silme veya üzerine yazma işlemi yapmadan önce neyin kaybedileceğini listeleyin ve yedeğin varlığını kanıtlayın.
Bu adımı atlayan bir işlem, kalıcı veri kaybına yol açabilir. Öğrendiğimiz en pahalı derslerden biri bu oldu.
Yedekleme betiğinin kendisini test etmek
Betikler zamanla bozulur: yollar değişir, izinler değişir, yeni servisler eklenir ama yedek listesine girmez.
Yedek içeriğini dönemsel olarak açıp kontrol edin. Arşivin içinde beklediğiniz dosyalar gerçekten var mı?
Boyut izleme basit ve etkili bir kontroldür; aniden küçülen yedek, içeriğin boş olduğunun işaretidir.
Yeni bir servis eklediğinizde yedek listesini güncellemeyi kontrol listesine yazın.
Yedekten geri dönüş tatbikatı
Yılda bir kez gerçek bir tatbikat yapın: ayrı bir sunucuya yedekten sistemi ayağa kaldırın.
Süreyi ölçün ve eksik çıkan her şeyi not edin. Genellikle bir yapılandırma dosyası veya bir anahtar eksik çıkar.
Tatbikat sonrası yedek listesini ve geri yükleme belgesini güncelleyin.
Bu tatbikat, kriz anındaki gerçek kesinti sürenizi önceden bilmenin tek yoludur.
Sık sorulanlar
Ne sıklıkla yedek almalıyım?
Kaybetmeyi göze alabileceğiniz veri miktarına göre. Günlük yedek çoğu iş uygulaması için uygundur; sipariş ve finansal işlem yoğunluğu yüksekse daha sık aralıklar gerekir.
Geri yükleme testini nasıl yaparım?
Ayrı bir test sunucusuna son yedeği geri yükleyip sistemi ayağa kaldırın ve birkaç kaydı gerçek veriyle karşılaştırın. Süreyi kaydedin; bu süre kriz anındaki gerçek kesinti sürenizdir.
Yedekleri şifrelemeli miyim?
Kişisel veya ticari veri içeriyorsa evet, özellikle sunucu dışında saklanan kopyalar için. Şifreleme anahtarını yedeklerden ayrı ve güvenli bir yerde saklayın; anahtar kaybolursa yedek de kullanılamaz.
