Çoğu kurumun yedeği vardır ve yedekleme yazılımının günlük raporu yeşildir. Ama önemli soru “yedeğimiz var mı?” değil; “sunucuyu bugün kaybetsek kaç saatte ve ne kadar eksiksiz geri gelir?” sorusudur. Bu makale, bu soruyu yanıtlamak için kullandığım yöntemi anlatıyor; Golrokh Teb görüntüleme merkezi projesinde otomatik Veeam yedeklemesiyle kullanılan yaklaşımın aynısı.
“Başarılı yedek” neden yetmez?
“Başarılı” mesajı yalnızca yedekleme işinin hatasız bittiğini söyler. Şunları garanti etmez:
- gereken her şeyin yedeklendiğini; sonradan eklenen bir sunucu işe dahil olmayabilir.
- veritabanının yedek anında sağlıklı ve tutarlı olduğunu.
- yedeğin kendisinin bozulmadığını ya da fidye yazılımına yakalanmadığını.
- geri yüklemenin işin dayanabileceği sürede bittiğini.
1. adım: neyin, ne zamana kadar geri gelmesi gerektiğini yazın
Her kritik servis için yönetimle iki sayı üzerinde anlaşın:
- Kabul edilebilir en fazla veri kaybı (RPO): gece yedeklemesinde bir iş gününe kadar veri kaybolabilir. Bu kabul edilemiyorsa yedekleme daha sık yapılmalıdır.
- En fazla kesinti süresi (RTO): servisin kaç saatte geri gelmesi gerektiği.
Bu iki sayı olmadan geri yükleme testinin başarılı olup olmadığını söyleyemezsiniz.
2. adım: raporları gerçekten okuyun
- Uyarıları görmezden gelmeyin; birçok sorun önce uyarı olarak görünür.
- Yeni bir sunucu ya da sanal makine eklendiğinde yedekleme işinde olduğunu kontrol edin.
- Boş alanı ve saklama süresini dönemsel olarak kontrol edin.
3. adım: dosya geri yükleme testi
En basit test: farklı tarihlerden birkaç dosya ve klasörü ayrı bir konuma geri yükleyip açın. Test dosyalarını değil, insanların gerçekten kullandığı dosyaları seçin.
4. adım: sanal makineyi açma testi
Tam bir sanal makineyi yalıtılmış bir ağa (orijinalle çakışmasın diye üretim ağına bağlı olmayan) geri yükleyin ve kontrol edin:
- İşletim sistemi açılıyor mu?
- Servisler başlıyor mu, oturum açılabiliyor mu?
Veeam’de SureBackup bu testi otomatikleştirir: makineyi yedekten yalıtılmış bir ortamda çalıştırır ve sağlıklı olduğunu kontrol eder.
5. adım: uygulama ve veritabanı testi
Sunucunun açılması işletim sisteminin sağlam olduğunu gösterir, verinin değil. Kritik veritabanlarını (örneğin muhasebe yazılımının ya da kabul sisteminin SQL Server’ını) geri yükleyin ve:
- veritabanı bütünlüğünü kontrol edin; SQL Server’da
DBCC CHECKDBile. - o uygulamanın anahtar bir kullanıcısından son kayıtlara bakıp verilerin beklenen tarihe kadar geldiğini onaylamasını isteyin.
6. adım: geri yükleme süresini ölçün
Geri yüklemeyi baştan sona saatle ölçün ve RTO ile karşılaştırın. Tam geri yükleme 12 saat sürüyor ve iş 4 saate dayanabiliyorsa sorun testte değil tasarımdadır.
7. adım: bir kopyayı fidye yazılımından uzak tutun
- 3-2-1 kuralı: üç kopya, iki tür ortamda, biri kurum dışında. Ayrıntılar Veeam Backup ile yedekleme: 3-2-1 kuralı makalesinde.
- En az bir kopya değiştirilemez (immutable) ya da ağdan ayrı olsun.
- Yedekleme yönetici hesabını etki alanı hesaplarından ayrı tutun; etki alanına ulaşan bir fidye yazılımı yedekleri silememeli.
8. adım: sonucu kaydedin ve bir prosedür yazın
Her testten sonra bir sayfa yeterlidir: tarih, neyin geri yüklendiği, ne kadar sürdüğü, ne sorun çıktığı ve neyin düzeltilmesi gerektiği. Kriz gününde başka birinin de yapabilmesi için adım adım bir geri yükleme prosedürü de yazın.
Önerilen takvim
- Her gün: raporlar ve uyarılar
- Her ay: birkaç dosya ve bir veritabanı geri yükleme
- Üç ayda bir: kritik sanal makineleri yalıtılmış ortamda tam açma ve süreyi ölçme
- Her büyük değişiklikten sonra: yeniden test; örneğin sunucu taşıma ya da yedekleme yazılımı değişikliği sonrası
Sunucularınızın yedeğinin gerçekten geri yüklenebildiğinden emin değilseniz HPE sunucu ve sanallaştırma hizmetinden inceleme isteyin.
Fotoğraf: NOIRLab/NSF/AURA/T. Slovinský, CC BY 4.0 lisansıyla, Wikimedia Commons.jpg) üzerinden; kırpılmıştır.
