Bir yedeğin başka binada tutulması, o kopyaya aynı yönetici hesabıyla erişilebildiği gerçeğini değiştirmez. Silmeye karşı kilitlenmiş bir kopya da bulunduğu tesisin tümü kullanılamaz hale geldiğinde hemen erişilebilir olmayabilir. Yedek tasarımında hangi kopyanın hangi olaya karşı koruma sağladığını açıkça yazmak gerekiyor.
Üç kavramı ayrı değerlendirelim
Immutable, belirli koşullar ve süre boyunca verinin değiştirilmesini veya silinmesini engelleyen korumayı anlatır. Offsite, kopyanın farklı bir konumda bulunmasıdır. Çevrimdışı kopyanın ise normal işletim sırasında erişim yolu kapalıdır. Aynı tasarımda bu özellikler birlikte bulunabilir; birinin varlığından diğerlerini varsaymamak gerekir.
CISA'nın fidye yazılımı rehberi, kritik veriler için çevrimdışı ve şifreli yedeklerle düzenli kurtarma testlerini öneriyor. Bu öneriyi kendi ortamınıza çevirirken lokasyon kaybı, yetkili hesap ele geçirilmesi, yanlış silme ve uzun süre fark edilmeyen veri bozulması için ayrı senaryolar hazırlayın.
Kilidin neyi kapsadığını öğrenelim
Ürün ekranında immutability seçeneğinin işaretli olması tek başına yeterli bilgi vermez. Hangi dosyaların korunduğunu, korumanın ne zaman başladığını, ne zaman bittiğini ve kimlerin yönetim ayarlarına erişebildiğini inceleyin. Örneğin Veeam hardened repository gereksinimleri, yedek dosyalarıyla sürekli güncellenen metadata dosyalarının davranışını ayrı açıklıyor. Ürün sürümü ve depo türü burada önem taşıyor.
Bunu küçük bir kontrol kaydına dönüştürmek faydalı:
- Korunan veri ve kapsam dışında kalan bileşenler
- Kilit süresi ile normal saklama politikasının ilişkisi
- Depoya, yedek sunucusuna ve yönetim katmanına erişen roller
- Yönetim sistemi kaybolursa geri yükleme için gereken bilgiler
- Depo dolduğunda alarmı alacak ve aksiyon verecek kişi
Saklama süresini kapasiteden bağımsız seçmeyelim
Kilit süresi boyunca temizlenemeyen veri kapasite tüketmeye devam eder. Veeam'in immutability açıklaması da silme engelinin süre bitimine kadar devam ettiğini belirtir. Bu nedenle günlük değişim miktarını, tam yedek davranışını ve uzun süreli saklanan noktaları birlikte hesaplayın.
Örnek bir planlamada günlük büyüme sabit kabul edilebilir; ancak gerçek ortamda büyük veri aktarımı veya uygulama güncellemesi bu varsayımı bozabilir. Ortalama tüketimin yanına yüksek değişim senaryosu ekleyin. Depo dolduğunda korumayı gevşetmeyi varsayılan çözüm haline getirmek yerine, kapasite ekleme süresini önceden planlayın.
Uzak kopyadan dönüşü de ölçelim
Yerel yedekten hızlı dönen bir uygulama, uzak kopyadan aynı sürede dönmeyebilir. Verinin ulaşacağı hedef, aktarım kapasitesi, gerekli erişimler ve kurtarma sırasındaki diğer yükler sonucu değiştirir. Uzak kopyayla yapılan prova, normal yedek işinin raporundan ayrı tutulmalı.
Kurtarma denemesinde üretim ortamını taklit etmek kadar dış bağlantıları sınırlandırmak da önemli. Şifre çözme bilgilerinin erişilebilirliğini doğrulayın; bu bilgileri rapora veya genel dokümantasyona yazmayın. Güvenli kasadaki kaydın konumu ve erişim prosedürü yeterlidir.
Tasarımı gözden geçirirken son soru şu olsun: “Ana tesis ve günlük yönetim hesapları aynı anda kullanılamazsa hangi kopyayla başlayacağız?” Bu soruya cevap verebilen, kapasitesi ve erişim yolu denenmiş bir yedek zinciri, satın alınan özellikleri gerçek bir kurtarma kabiliyetine dönüştürür.
Yorumlar (0)
Henüz onaylanmış yorum yok.