Yedekleriniz düzenli alınıyor, panelde yeşil tikler görünüyor ve dosyalar birikiyor. Peki o yedeklerden gerçekten geri dönebiliyor musunuz? Bunu ilk kez felaket anında denemek, kötü bir plandır.
Bu yazı, yedeklerin işe yaradığını doğrulamayı ele alıyor.
Yedek Neden Çalışmaz?
Alınmış bir yedek birçok nedenle işe yaramaz olabilir:
- Eksik alınmıştır. Bazı dizinler kapsam dışında.
- Veritabanı tutarsızdır. Yazma sırasında alınmış.
- Bozulmuştur. Arşiv açılmıyor.
- Şifresi unutulmuştur.
- Uzun süredir başarısız oluyordur. Kimse bakmamıştır.
Beşinci madde en yaygın ve en acı olanıdır: aylardır başarısız olan bir yedekleme görevi, kimse kontrol etmediği için sessizce çalışmamaya devam eder — ve son geçerli yedek aylık öncesine aittir.
Birinci madde ise en sinsi olanıdır. Yedek başarıyla tamamlanır, dosya oluşur, boyutu makul görünür — ama kritik bir dizin kapsam dışıdır.
Üç Doğrulama Seviyesi
Yedek doğrulaması farklı derinliklerde yapılabilir:
| Seviye | Ne doğrular |
|---|---|
| Varlık kontrolü | Dosya oluşmuş mu |
| Bütünlük kontrolü | Arşiv açılıyor mu |
| Tam geri yükleme | Site gerçekten çalışıyor mu |
İlk iki seviye otomatikleştirilebilir ve günlük yapılabilir. Üçüncü seviye ise elle çaba gerektirir ama tek gerçek kanıttır: yedeğin geçerli olduğunun tek kanıtı, ondan çalışan bir site kurabilmektir.
Arşivin açılması, içindeki veritabanı dökümünün eksiksiz veya tutarlı olduğunu göstermez.
Prova Nasıl Yapılır?
Geri yükleme provası için adımlar:
- Ayrı bir alt alan adı veya dizin hazırlayın.
- Yeni bir veritabanı oluşturun.
- Yedeği oraya açın. Canlıya dokunmadan.
- Yapılandırmayı yeni veritabanına yönlendirin.
- Siteyi açıp kontrol edin.
- Sonucu kaydedin ve temizleyin.
Üçüncü madde kritik bir güvenlik kuralıdır: provayı canlı veritabanına yapmak, prova değil felaket olur — mutlaka ayrı bir hedefe geri yüklenmelidir.
Bu, en sık yapılan ve en pahalı hatadır. Yedeği test etmek isterken canlı veriyi eski hâline döndürmek, gerçek bir veri kaybı üretir.
Altıncı madde ise prova ortamının açık kalmamasını sağlar. Test kopyası unutulursa hem disk tüketir hem güvenlik riski oluşturur.
Neyi Kontrol Etmeli?
Geri yüklenen kopyada bakılacaklar:
| Kontrol | Ne gösterir |
|---|---|
| Ana sayfa açılıyor mu | Temel bütünlük |
| Kayıt sayıları doğru mu | Veri eksiksizliği |
| Son kayıt tarihi ne | Yedek ne kadar güncel |
| Görseller görünüyor mu | Dosyalar da yedeklenmiş mi |
| Giriş yapılabiliyor mu | Kullanıcı tablosu sağlam mı |
Üçüncü satır beklenmedik bir gerçeği ortaya çıkarabilir: yedeğin dosya tarihi bugün olsa bile içindeki en son kayıt haftalar öncesine ait olabilir — bu, yedekleme sürecinin bir noktada bozulduğunu gösterir.
Dördüncü satır ise sık yaşanan bir eksiği yakalar. Veritabanı yedekleniyor ama yükleme dizini kapsam dışıysa, geri yüklenen sitede tüm görseller kırık çıkar.
Ne Sıklıkla Prova Yapmalı?
Prova sıklığı sitenin kritikliğine göre belirlenir:
- Kritik ticari site: Üç ayda bir.
- Normal kurumsal site: Altı ayda bir.
- Düşük öncelikli site: Yılda bir.
- Her büyük değişiklik sonrası: Mutlaka.
Dördüncü madde en önemlisidir: sunucu taşıma, sürüm yükseltme veya yedekleme aracı değişikliği sonrasında prova yapılmazsa, yedekleme sessizce bozulmuş olabilir.
Bu tür değişikliklerden sonra yedek dosyaları oluşmaya devam eder ama içerikleri eksik veya bozuk olabilir.
Süreyi Ölçmek
Provanın ikinci amacı, gerçek kurtarma süresini öğrenmektir:
- Yedeği indirme süresi
- Açma ve hazırlama süresi
- Veritabanı yükleme süresi
- Yapılandırma ve doğrulama süresi
- Toplam
Beşinci madde bir beklenti kurar: "yedeğimiz var" demek kesintinin ne kadar süreceğini söylemez — asıl soru geri dönüşün kaç saat alacağıdır.
Bu süre ölçülmediğinde, kriz anında verilen "birazdan düzelir" sözü tutulamaz. Ölçülmüş bir süre ise hem gerçekçi iletişim hem doğru planlama sağlar.
Üçüncü madde büyük veritabanlarında şaşırtıcı olabilir. Birkaç gigabaytlık bir dökümü yüklemek saatler sürebilir.
Kısmi Geri Yükleme
Her felaket tam geri yükleme gerektirmez:
| Senaryo | Gereken |
|---|---|
| Tek bir dosya silindi | O dosyayı çıkarmak |
| Bir tablo bozuldu | Tek tabloyu yüklemek |
| Yanlış toplu güncelleme | Belirli kayıtları geri almak |
| Site tamamen gitti | Tam geri yükleme |
İlk üç satır çok daha sık yaşanır: gerçek hayatta tam felaket nadirdir, asıl ihtiyaç tek bir dosyayı veya tabloyu geri almaktır.
Bu yüzden yedek biçiminizin kısmi çıkarmaya izin vermesi önemlidir. Tek bir dosya için tüm yedeği açmak zorunda kalmak, kurtarma süresini gereksiz yere uzatır.
Prosedürü Yazmak
Prova sonucunda bir belge üretilmelidir:
- Adım adım geri yükleme talimatı
- Gereken erişim bilgilerinin nerede olduğu
- Ölçülen süreler
- Karşılaşılan sorunlar ve çözümleri
- Kimin yapabileceği
Beşinci madde iş sürekliliği için kritiktir: geri yüklemeyi yalnızca bir kişinin yapabildiği bir yapıda, o kişi ulaşılamaz olduğunda kesinti uzar.
Prosedür yazılı olduğunda, teknik bilgisi olan herhangi biri süreci yürütebilir. Bu, kriz anında beklemeyi ortadan kaldırır.
İkinci madde de sık atlanır. Yedeklere erişim şifresi yalnızca bir kişinin bilgisayarındaysa, yedek fiilen erişilemez demektir.
Otomatik Kontroller
Tam prova arasında otomatik doğrulamalar kurulabilir:
- Yedek dosyası oluştu mu?
- Boyutu beklenen aralıkta mı?
- Arşiv bütünlük testi geçiyor mu?
- Veritabanı dökümü son satırla bitiyor mu?
- Başarısızlıkta uyarı gidiyor mu?
İkinci madde basit ama etkili bir kontroldür: yedek boyutunun aniden düşmesi, kapsamın daraldığını veya bir hatanın oluştuğunu gösterir.
Dördüncü madde veritabanı dökümlerinde kesilmeyi yakalar. Eksik yazılmış bir döküm dosyası, sonundaki tamamlanma işaretini içermez.
Beşinci madde tüm sistemin çalışmasını sağlar. Uyarı gitmiyorsa, aylarca başarısız olan bir yedekleme fark edilmez.
Bu kontrolleri zamanlanmış görev olarak kurabileceğiniz Linux hosting paketleri üzerinde, günlük otomatik doğrulama birkaç satırlık bir betikle sağlanır.
Sonuç
Yedekleme sisteminin en yaygın arızası sessizdir: aylardır başarısız olan bir görev, kimse kontrol etmediği için çalışmamaya devam eder. Arşivin açılması yedeğin geçerli olduğunu göstermez — tek kanıt ondan çalışan bir site kurabilmektir. Provayı mutlaka ayrı bir hedefe yapın; canlı veritabanına yapılan bir prova, prova değil felaket olur. Ve provanın ikinci amacını unutmayın: gerçek kurtarma süresini ölçmek.
Sıkça Sorulan Sorular (SSS)
Yedeğim var, neden test etmeliyim?
Çünkü alınmış bir yedek birçok nedenle işe yaramaz olabilir: eksik kapsam, bozuk arşiv, tutarsız veritabanı veya aylardır sessizce başarısız olan bir görev. Yedeğin geçerli olduğunun tek kanıtı, ondan çalışan bir site kurabilmektir.
Provayı nasıl yapmalıyım?
Ayrı bir alt alan adı ve ayrı bir veritabanı hazırlayıp yedeği oraya açarak — canlıya asla dokunmadan. Provayı canlı veritabanına yapmak en pahalı hatadır; yedeği test etmek isterken gerçek veri kaybı üretirsiniz.
Ne sıklıkla prova yapmalıyım?
Kritik siteler için üç ayda bir, normal siteler için altı ayda bir. Ama asıl önemlisi, her büyük değişiklikten sonra yapmaktır — sunucu taşıma, sürüm yükseltme veya yedekleme aracı değişikliği yedeklemeyi sessizce bozmuş olabilir.
Kurtarma süresi neden önemli?
Çünkü "yedeğimiz var" demek kesintinin ne kadar süreceğini söylemez. Bu süre ölçülmediğinde kriz anında verilen sözler tutulamaz. Provada indirme, açma, veritabanı yükleme ve doğrulama sürelerini ayrı ayrı ölçün.
