Yedekleme görüşmeleri genellikle kapasiteyle başlar: Kaç terabayt veri var, ne kadar alan gerekecek? Bu soru önemlidir ama ilk soru değildir. Yedeklemenin amacı veriyi kopyalamak değil, bir sorun yaşandığında işi yeniden çalışır hâle getirmektir. Bu yüzden plan, geri dönüş ihtiyacından geriye doğru kurulmalıdır.
Önce işleri ve verileri eşleştirin
Hangi işin hangi veriye bağlı olduğunu çıkararak başlayın. Dosya sunucusu, ERP veya muhasebe veritabanı, e-posta kutuları ve kullanıcı bilgisayarları aynı önceliğe sahip değildir. Bir sistem bir gün boyunca çalışmadığında işin nasıl etkileneceğini sormak, öncelikleri kendiliğinden ortaya çıkarır.
Bu aşamada verinin nerede durduğunu da netleştirin. Şirket içindeki sunucular, bulut hizmetleri ve kullanıcıların kendi cihazlarında tuttuğu dosyalar farklı yaklaşımlar gerektirebilir. Bulutta çalışan bir hizmetin verisinin otomatik olarak yedeklendiğini varsaymak yerine hizmet koşullarını ve sizin sorumluluğunuzda kalan kısmı kontrol edin.
Bu eşleştirmenin sonunda elinizde kısa bir tablo olmalıdır: sistem, içerdiği veri, iş tarafındaki sahibi ve önceliği. Planın geri kalanı bu tabloya dayanır.
Kabul edilebilir kaybı ve dönüş süresini belirleyin
Her kritik sistem için iki soruyu yanıtlayın. Birincisi: En fazla ne kadarlık veri kaybı kabul edilebilir? Günde bir kez alınan bir yedekte, son yedekten sonra yapılan işler risk altındadır. İkincisi: Sistem en geç ne kadar sürede yeniden çalışır olmalı? Bu iki kavram teknik dilde RPO ve RTO olarak anılır; ancak işletme tarafında her biri için sade bir cümle yeterlidir.
Bu yanıtlar yedekleme sıklığını, saklama süresini ve kopyaların nerede tutulacağını belirler. Yaygın bir yaklaşım, verinin birden fazla kopyasını farklı ortamlarda ve en az birini ana lokasyonun dışında tutmaktır. Yerel kopya hızlı geri dönüş sağlar; lokasyon dışındaki ya da buluttaki kopya ise yangın veya hırsızlık gibi yerel olayların etkilemeyeceği bir konumda durur.
Fidye yazılımı riskine karşı, yedeklere erişimin ayrı yetkilerle korunmasını ve en az bir kopyanın ağdan ayrı ya da değiştirilemez biçimde tutulmasını da değerlendirin.
Geri yüklemeyi test edin
Yedeğin alındığını gösteren bir rapor, geri yüklemenin çalışacağını garanti etmez. Bu nedenle plan düzenli bir geri yükleme kontrolü içermelidir. Kontrolü tanımlarken şu soruları yanıtlayın:
- Hangi sistemden hangi örnek veri geri yüklenecek?
- Geri yükleme nereye yapılacak ve canlı sistemin etkilenmemesi nasıl sağlanacak?
- Sonucu kim doğrulayacak ve nasıl kayda geçirecek?
- Kontrol ne sıklıkla tekrarlanacak?
Test sırasında geri yüklemenin ne kadar sürdüğünü de not edin. Bu süreyi belirlediğiniz dönüş süresiyle karşılaştırmak, planın gerçekçi olup olmadığını gösterir.
Geri yüklemenin yalnızca dosya düzeyinde değil, gerektiğinde sistem düzeyinde nasıl yapılacağını da planlayın. Bir sunucunun tamamen kullanılamaz hâle geldiği senaryoda hangi adımların hangi sırayla izleneceğini anlatan kısa bir geri dönüş prosedürü, baskı altındaki bir anda zaman kazandırır.
Sorumlulukları ve gözden geçirmeyi planlayın
Yedekleme sistemine kimlerin erişebildiği, başarısız işlerin kime bildirildiği ve değişikliklerin nasıl kaydedildiği yazılı olmalıdır. Başarısız bir yedekleme işi günlerce fark edilmeden kalabilir; bildirimlerin gerçekten birinin önüne düştüğünden emin olun. Yedekleme lisanslarının ve depolama alanının ne zaman yetersiz kalacağını izlemek de bu sorumlulukların parçasıdır.
Yeni bir uygulama devreye alındığında, veri hacmi büyüdüğünde veya bir sistem buluta taşındığında planı güncelleyin. Yedekleme ve geri dönüş hizmetimizde Narbulut gibi çözümlerle yedeklenecek verileri, saklama sürelerini ve geri yükleme senaryolarını sizinle birlikte belirliyor; geri dönüş kontrollerini planın bir parçası olarak ele alıyoruz.