Yedekleme Yönetimi

Yönetilen yedekleme hizmeti kapsamında neler kontrol edilir?

Yedekleme yönetimi, mevcut yedekleme altyapısının günlük operasyonunu devralır: yeni bir depolama alanı satın almak yerine var olan yedek işlerinin sağlıklı çalıştığı, saklama kurallarına uyulduğu ve geri dönüşün gerçekten mümkün olduğu düzenli olarak kanıtlanır. Kontrol listesi ortamın büyüklüğüne göre genişletilir; temel başlıklar şunlardır:

• İş sağlığı: başarısız, uyarıyla biten ya da beklenenden uzun süren yedek işleri, atlanan sanal makineler ve kapsam dışında kalan yeni sunucular.
• Depo durumu: yedek deposunun doluluk eğilimi, saklama zincirinin bütünlüğü ve eski restore noktalarının planlandığı gibi temizlenmesi.
• Kopya kuralı: yedeğin en az bir kopyasının farklı lokasyonda ve mümkünse değiştirilemez (immutable) biçimde tutulması.
• Erişim ve kimlik: yedek konsoluna erişen hesaplar, servis hesaplarının yetkileri ve şifreleme anahtarlarının güvenli saklanması.
• Raporlama: başarı oranı, geri dönüş testi sonuçları ve açık aksiyonların yönetime ve denetime sunulabilir biçimde raporlanması.

Yedeklerin fidye yazılımına karşı korunması için immutable backup nedir rehberinde anlatılan değiştirilemez saklama modeli, yönetim kapsamında düzenli olarak doğrulanır.

Yedekleme yönetimi ile bulut yedekleme arasındaki fark

İki hizmet sıkça karıştırılır, ancak farklı sorulara cevap verir. Bulut yedekleme verinin nereye kopyalanacağını çözer; yedekleme yönetimi ise yedekleme sürecinin kim tarafından, hangi disiplinle yürütüleceğini belirler.

Tesis dışı kopya ihtiyacı için cloud veri yedekleme hizmeti, yönetilen yedekleme kapsamıyla aynı sözleşmede birleştirilebilir.

Yedekleme yönetiminde sık yapılan hatalar

• Başarılı iş ile kullanılabilir yedeği aynı saymak: işin yeşil görünmesi, uygulamanın o yedekten tutarlı şekilde ayağa kalkacağını göstermez.
• Yeni sunucuları kapsama eklemeyi unutmak: sonradan kurulan sistemler yedek planına girmediğinde sorun ancak veri kaybında fark edilir.
• Yedek ile üretimi aynı kimlik altyapısında tutmak: ele geçirilen bir yönetici hesabı hem sunuculara hem yedeklere ulaşabilir.
• Uyarıları sahipsiz bırakmak: e-postaya düşen hata bildirimlerini takip eden bir sorumlu yoksa uyarı sistemi işlevini yitirir.
• RPO ve RTO hedeflerini yazılı hâle getirmemek: hangi sistemin en fazla ne kadar veri kaybını ve ne kadar kesintiyi tolere edebileceği belirlenmeden yedek sıklığı ve saklama süresi doğru ayarlanamaz.
• Geri dönüş sırasını planlamamak: geniş çaplı bir olayda hangi sunucunun önce ayağa kaldırılacağı önceden belirlenmemişse kurtarma süresi uzar.

Bu hataların çoğu teknik değil, süreçle ilgilidir. Yönetilen hizmette her kontrolün bir sorumlusu, bir sıklığı ve raporda karşılığı olur; yedekleme böylece bir kez kurulup unutulan bir yazılım olmaktan çıkar, düzenli denetlenen bir operasyona dönüşür. Geniş kapsamlı senaryolar için felaket kurtarma planı nasıl hazırlanır rehberi yedekleme yönetimiyle birlikte ele alınabilir.