Tipik Başlangıç Durumu
Yedeklerin aynı kimlik bilgileriyle erişilebilir olması, restore testlerinin yapılmaması veya yalnız snapshot/RAID'e güvenilmesi, gerçek bir olayda kurtarma kabiliyetini zayıflatabilir.
Teknik Çözüm Yaklaşımı
İş yükleri, veri hacmi, günlük değişim oranı, saklama süreleri ve kritik sistemler analiz edilir. Yedekleme job'ları, repository mimarisi, immutable veya izole kopya, off-site kopya ve düzenli restore testleri planlanır.
Proje Kapsamındaki Teknik Bileşenler
- Veeam Backup & Replication job tasarımı
- Immutable veya izole yedek repository
- 3-2-1-1-0 yaklaşımına uygun kopya planı
- Kritik sistemler için RPO/RTO hedefleri
- Periyodik restore testleri
- Yedekleme hesapları ve erişim yetkilerinin ayrıştırılması
Bu Mimari Ne Sağlamayı Amaçlar?
Amaç; yedeklerin yalnız oluşturulmasını değil, ihtiyaç anında geri döndürülebilirliğinin düzenli olarak doğrulanmasını ve fidye yazılımı gibi olaylara karşı kurtarma dayanıklılığının artırılmasını sağlamaktır.
İlgili Hizmet ve Çözümler
Mimari ve çalışma modeli
Bu senaryoda koruma kopyasını saldırganın değiştirmesinden korumak ile uygulamayı temiz hedefte çalıştırmak birlikte sınanır. Repository kilidi ilk hedefi, izole recovery ağı ve iş doğrulaması ikinci hedefi destekler. Ana backup sunucusu ve üretim kimliğinin kaybı varsayımı, gerçek bağımsızlığı görünür kılar.
- 1Korunan nokta seçimi
- 2Ayrı kurtarma erişimi
- 3İzole uygulama açılışı
- 4Kontrollü yeniden bağlantı
Tasarım parametreleri
- Temiz hedef
- Üretim hypervisorı veya yönetim sistemi kaybedildiğinde alternatif restore hedefini önceden hazırlayın.
- Katalog ve kimlik
- Katalog, yapılandırma ve kurtarma kimliğinin bağımsız erişimini sınayın; veri kilidi tek başına restore zinciri değildir.
- Kurtarma birimi
- Dosya, uygulama, veritabanı ve tüm sistem için kurtarma gereksinimlerini ayrı ayrı belirleyin. Her birinin bağımlılığı ve test yöntemi farklıdır.
- Kopyanın tutarlılığı
- Yedekleme işinin başarıyla tamamlanmasıyla yetinmeyin. Uygulama hazırlığı, günlük zinciri ve gerçek geri yükleme sonucu üzerinden tutarlılığı doğrulayın.
- Kapasite ve aktarım
- Günlük değişim, saklama, tam kopya yöntemi ve ölçülen net hızla hesap yapın. Sıkıştırma veya deduplication oranını varsaymak yerine pilotta ölçün.
- Bağımsız kurtarma
- Yedek yönetimi, anahtar, katalog ve hedef altyapının üretim kaybından sonra erişilebilirliğini sınayın.
Hesap ve uygulama örneği
Örnek tatbikatta son kullanılabilir noktayı seçin, ayrı yönetim erişimi kurun ve uygulamayı test VLAN’ında açın. Kullanıcı yazma işlemi doğrulanmadan üretime bağlamayın. Kopya silme denemesi, anahtar erişimi ve uygulama kabulünü tek raporda fakat ayrı sonuçlar olarak gösterin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Repo sağlam, yönetim sunucusu yok | Kurtarma erişimi ve katalog yeniden kurma prosedürü eksik olabilir. | Üretim yönetimi olmadan yeni hedefte desteklenen import/restore yolunu test edin. |
| Yedekleme başarılı ancak geri yüklenen sistem açılamıyor | Zincir, şifreleme anahtarı, katalog veya uygulama tutarlılığı sorunu olabilir. | Ayrı hedefe küçük bir gerçek kurtarma yapın; ürün loglarını uygulama doğrulamasıyla birlikte inceleyin. |
| Aktarım süresi hedefi aşıyor | Kaynak okuma, ağ, hedef yazma veya çok sayıda küçük nesne sınırlayıcı olabilir. | Aynı zaman aralığında üç katmanın hız ve gecikmesini ölçün; yalnız hat hızına bakmayın. |
| Kapasite tahminden hızlı büyüyor | Değişim oranı, tam kopyalar, kilit süreleri veya temizleme beklemeleri hesap dışı kalmış olabilir. | Politika bazında gerçek kullanım ve silinmeye uygun noktaları karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Testte üretim yönetim erişimi kayıp kabul edilerek kurtarma tamamlanmalıdır.
- Seçilen kurtarma noktasını temiz bir hedefe geri yükleyin ve iş verilerini doğrulayın.
- Gözlenen veri kaybı penceresini hedef RPO ile karşılaştırın.
- Hazırlık, transfer, açılış ve iş onayını ayrı süreler olarak kaydedin.
- Üretim yönetim hesabı olmadan gerekli kurtarma erişimini test edin.
- Korunan kopyayı kontrollü silme denemesi ve gerçek restore ile sınayın.
İlgili kavramlar
RPO ve gerçek veri kaybı penceresi
RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.
RTO ve uçtan uca kurtarma süresi
RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Test süresinin hangi olayla başlayıp hangi olayla sona erdiğini açıkça belirtin. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Değiştirilemezlik ve silme yetkisi
Immutable saklama, belirlenen süre içinde verinin değiştirilmesini veya silinmesini sınırlayan bir kontrol mekanizmasıdır. Uygulamanın verdiği söz, depolama katmanındaki zorunlu koruma ve fiziksel izolasyon aynı şey değildir. Kilit süresi, saat yönetimi, yönetici yetkileri ve veri silme yolu birlikte incelenmelidir. Süre dolunca verinin otomatik silinip silinmediği de ürün politikasına bağlıdır. Kontrollü bir test kopyası üzerinde normal ve ayrıcalıklı hesapla silme denemesi yapın; ardından korunan kopyadan geri dönüşü doğrulayın. Koruma, okunabilirlik testinin yerine geçmez.
Saklama politikası ve kapasite
Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.
Şifreleme ve anahtarın yaşam döngüsü
Şifreleme, verinin anahtar olmadan okunmasını zorlaştırır; erişim kontrolü, silinme koruması ve yedekleme farklı ihtiyaçları karşılar. Taşınan veri ile disk üzerindeki veri için hangi katmanın şifreleme sağladığını belirtin. Anahtarların oluşturulması, korunması, döndürülmesi ve acil geri kazanımı tasarımın parçasıdır. Yedeği kurtarmak için gereken anahtar yalnız felaket sırasında kaybedilecek sunucuda bulunmamalıdır. Test ortamında ayrı bir yöneticiyle veriyi açma ve anahtar erişimini geri kazanma adımlarını uygulayın; gerçek anahtarları dokümana veya destek mesajına koymayın.
Birincil teknik dokümantasyon
Bu Senaryo Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
Bu örnek teknik senaryo, Doz Teknoloji'nin kurumsal IT ve altyapı projelerinde kullandığı değerlendirme başlıkları temel alınarak hazırlanmıştır.
Doz Teknoloji hakkındaTeknik Kriterler + Birincil Kaynaklar
Immutable repository tasarımı, değiştirilemezlik süresi ve ransomware sonrası kurtarma yaklaşımı Veeam dokümantasyonu ve CISA önerileriyle karşılaştırıldı.
Karar Kalitesini Artırmak
Yedeğin var olmasının tek başına yeterli olmadığını; silme direnci, izole kopya ve geri yükleme testinin birlikte tasarlanması gerektiğini göstermek.
İçerik ve birincil kaynaklar yeniden kontrol edildi.
İlgili Sonraki Adımlar
Konuyu teknik rehber, ürün/lisans veya proje senaryosu üzerinden ayrıntılı olarak inceleyin.
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Benzer Bir Altyapıyı Değerlendirmek İster misiniz?
Mevcut altyapınızı, kritik sistemlerinizi ve proje hedeflerinizi paylaşın; ihtiyaç analizi sonrasında uygun teknik kapsamı birlikte oluşturalım.