Yedek Almak Yeterli mi? Geri Yükleme Kontrolünü Planlamak

Birçok kurumda yedekleme panelinde yeşil bir onay işareti görünür ve konu kapanmış sayılır. Oysa o işaret yalnızca bir işin çalıştığını söyler; verinin gerektiğinde geri getirilebileceğini söylemez. Geri yükleme kontrolü, yedeğin gerçekten işe yarayıp yaramadığını görmenin tek yoludur ve altyapı yönetiminde yedek almaktan ayrı, planlı bir adım olarak ele alınmalıdır.

Bu yazıda yedek doğrulamanın neden ayrı bir kontrol olduğunu, hangi noktaların denetlenmesi gerektiğini ve izleme, uyarı ile bakım planının birbirine nasıl bağlandığını karar vericilerin sorabileceği somut sorularla ele alıyoruz.

01Yedek almak ile geri yükleyebilmek aynı şey değildir

Yedekleme işi “tamamlandı” dediğinde genellikle şunu kastedir: bir dosya ya da anlık görüntü hedef konuma yazıldı. Bu dosyanın bozulmadığı, eksiksiz olduğu ve doğru sırayla açılabileceği ayrı bir sorudur. Pratikte sık görülen birkaç durum şunlardır:

• Boş ya da eksik yedek: İş hatasız bitmiş görünür, ancak yedeklenen dizin yanlış tanımlandığı için kritik veri kapsam dışında kalmıştır.
• Tutarsız veritabanı yedeği: Dosya kopyalanmıştır, ancak yazma işlemleri sürerken alındığı için geri yüklendiğinde veritabanı açılmaz ya da kayıtlar çelişir.
• Kaybolan anahtar: Yedek şifrelidir, fakat şifre çözme anahtarı yalnızca çöken sunucuda durmaktadır.
• Aynı yerde duran yedek: Yedek, asıl veriyle aynı hesap veya aynı depolama alanındadır; bir yetki hatası ya da kötü amaçlı yazılım ikisini birlikte etkiler.
• Dokümante edilmemiş adımlar: Geri yükleme yalnızca bir kişinin bildiği sırayla mümkündür ve o kişi ulaşılamaz durumdadır.

Bu durumların ortak noktası, sorunun yedek alındığı gün değil, veriye ihtiyaç duyulduğu gün fark edilmesidir. Kontrolü önceden planlamak, bu sürprizi bir tatbikat bulgusuna dönüştürür.

02Geri yükleme kontrolü neleri doğrulamalı?

Geri yükleme kontrolü tek bir test değil, farklı derinlikte birkaç doğrulamadan oluşur. Aşağıdaki tablo, her kontrolün hangi soruya yanıt verdiğini ve karar vericinin ne tür bir kanıt isteyebileceğini özetler.

Kontrolleri iki hedefle ilişkilendirmek de faydalıdır. RPO, en fazla ne kadarlık veri kaybını kabul edebileceğinizi; RTO ise sistemin ne kadar sürede yeniden hizmet vermesi gerektiğini anlatır. Bu iki hedef yazılı değilse, bir geri yükleme tatbikatının “başarılı” sayılıp sayılmayacağına karar vermek de zorlaşır.

03İzleme, uyarı ve bakım planı nasıl birbirine bağlanır?

Üç kavram sıklıkla ayrı konular gibi ele alınır; oysa birbirini tamamlarlar:

• İzleme neyin olduğunu görünür kılar: yedek işi çalıştı mı, ne kadar veri yazıldı, ne kadar sürdü?
• Uyarı ilgili kişiye zamanında haber verir: iş hata verdi, yedek boyutu beklenmedik şekilde küçüldü ya da hedef depolama dolmak üzere.
• Bakım planı düzenli işi sahibine bağlar: hangi tatbikat ne zaman yapılır, bulgular kime gider, kim kapatır?

Prometheus ve Grafana gibi izleme araçları ya da Uptime Kuma gibi basit durum izleyiciler, yedek işinin sonucunu ve süresini bir metrik olarak toplayabilir. Ancak yalnızca “iş çalıştı” bilgisine bakmak yetmez. Daha anlamlı uyarı örnekleri şunlardır:

1. Yedek işi belirlenen saatte başlamadı ya da hata koduyla bitti.
2. Yedek boyutu önceki haftanın belirgin biçimde altında kaldı; bu, kapsam dışı kalan veriye işaret edebilir.
3. Otomatik bütünlük kontrolü başarısız oldu.
4. Planlanan geri yükleme tatbikatı takvimde yapılmadı.

Dördüncü madde önemlidir: tatbikatın yapılmaması da bir uyarı konusudur. Böylece geri yükleme kontrolü kişilerin hatırlamasına değil, takvime ve kayda bağlı bir sürece dönüşür.

Bakım planına yerleştirirken şu sıralama makul bir başlangıçtır:

1. Kritik sistemleri ve her biri için RPO ile RTO hedefini yazın.
2. Her sistem için otomatik bütünlük kontrolünü ve uyarı kurallarını tanımlayın.
3. Örnek geri yükleme için düzenli bir takvim belirleyin; sıklık verinin değişim hızına ve kritikliğine göre seçilir.
4. Tam tatbikatı belirli aralıklarla ve büyük mimari değişikliklerden sonra yapın.
5. Her tatbikatın sonunda bulguları, ölçülen süreyi ve düzeltici aksiyonları tek bir rapora işleyin.

04Karar vericilerin sorabileceği sorular

Teknik ekibe ya da hizmet sağlayıcıya yöneltebileceğiniz birkaç soru, tablonun ne kadar sağlam olduğunu hızla gösterir:

• Son geri yükleme testini ne zaman yaptık ve sonucu nerede kayıtlı? Yanıt belirsizse kontrol fiilen yapılmıyor olabilir.
• Hangi sistemler yedeğin kapsamında, hangileri değil? Kapsam listesi yazılı olmalı; “her şey” yanıtı yeterli sayılmaz.
• Yedek bozulduğunda ya da boş geldiğinde kime, ne kadar sürede haber gider? Uyarı yoksa sorun ancak ihtiyaç anında ortaya çıkar.
• Şifre çözme anahtarı ve yedeğe erişim yetkisi kimde? Tek kişiye bağlı bilgi, operasyonel bir risktir.
• Yedek, asıl verinin etkilendiği bir olaydan bağımsız mı? Farklı hesap, farklı konum ya da değiştirilemez depolama gibi ayrım var mı?
• Geri yükleme adımları yazılı mı ve ekipte birden fazla kişi uygulayabiliyor mu?
• RTO hedefimiz ne ve tatbikatta bunu ölçtük mü? Ölçülmemiş bir hedef yalnızca beklentidir.

Bu soruların yanıtları kısa bir toplantıda alınabilir ve çoğu zaman bir sonraki bakım döngüsünde ele alınacak somut bir iş listesi çıkarır.

05Sık sorulan sorular

Yedek doğrulama ile geri yükleme testi aynı şey mi?

Hayır. Yedek doğrulama genellikle dosyanın bozuk olup olmadığını denetleyen, otomatikleştirilebilir bir bütünlük kontrolüdür. Geri yükleme testi ise veriyi gerçekten bir ortama alıp çalışıp çalışmadığına bakar. İlki hızlı ve sık yapılabilir; ikincisi daha kapsamlıdır ve takvimli planlanmalıdır. İkisi birbirinin yerine geçmez.

Geri yükleme kontrolü ne sıklıkla yapılmalı?

Tek bir doğru sıklık yoktur. Veri ne kadar hızlı değişiyorsa ve sistem iş sürekliliği için ne kadar kritikse kontrol o kadar sık olmalıdır. Başlangıç noktası olarak otomatik bütünlük kontrollerinin her yedekte, örnek geri yüklemenin düzenli aralıklarla, tam tatbikatın ise belirli dönemlerde ve büyük altyapı değişikliklerinden sonra yapılması düşünülebilir. Asıl önemli olan sıklığın yazılı olması ve gerçekten uygulanmasıdır.

Bulut sağlayıcısının sunduğu yedek özelliği bu kontrolü gereksiz kılar mı?

Hayır. Bulut sağlayıcıları altyapının dayanıklılığına büyük katkı sağlar; ancak hangi verinin yedekleneceği, saklama süresi, erişim yetkileri ve geri yükleme adımlarının doğru çalıştığının sınanması çoğunlukla sizin sorumluluğunuzdadır. Sağlayıcının özelliğini açmış olmak, kendi senaryonuzda geri dönüşü test etmiş olmak anlamına gelmez.

06Sonuç

Yedek almak gerekli ama tek başına yeterli değildir. Geri yükleme kontrolü; yazılı hedefler, otomatik uyarılar ve takvimli tatbikatlarla bakım planının doğal bir parçası olduğunda yedek, güvenilir bir güvence olmaya başlar. İlk adım olarak kritik sistemlerinizi ve bu sistemlerin son geri yükleme testini gözden geçirmeniz yeterlidir.

Yazılımınızı ve altyapınızı izleme, güncelleme, yedek doğrulama ve destek masasıyla birlikte tek sözleşme kapsamında yönetmeyi düşünüyorsanız, Bakım, Destek ve Yönetilen Hizmetler sayfamızdaki kapsamı inceleyebilirsiniz.