Immutable Backup ve Felaket Kurtarma Aynı Şey Değildir

Değiştirilemez yedek devreye alındığında “artık DR tamam” cümlesini sık duyarım. Oysa sağlam bir yedek kopyası, uygulamanın nerede çalışacağını, kullanıcıların nasıl bağlanacağını veya bağımlı servislerin hangi sırayla açılacağını cevaplamaz.

Kasım 2025 ile 22 Şubat 2026 arasındaki mimari çalışmada birincil veri merkezi, private cloud, DR ortamı ve immutable repository rolleri ayrıştırıldı. Her bileşenin farklı arızaya cevap verdiği, ancak ortak test programı olmadan hiçbirinin tek başına iş sürekliliği sağlamadığı görüldü.

Mimariyi yönetimle konuşurken üç somut senaryo kullandık: tek bir veritabanının yanlışlıkla silinmesi, ana veri merkezinin erişilemez olması ve yönetici kimliklerinin ele geçirilerek yedeklerin hedef alınması. İlk senaryo tarihsel ve tutarlı geri yükleme noktası, ikincisi çalışabilir alternatif kapasite, üçüncüsü ise yönetim düzlemi ayrımı ve değiştirilemezlik gerektiriyordu. Aynı ürün bu ihtiyaçların bazılarını destekleyebilir, fakat kontrol hedefleri birbirine karıştırılmamalıdır. Senaryo bazlı yaklaşım sayesinde “yedek var mı?” sorusu, “hangi olayda hangi kopyayı, kim, ne kadar sürede kullanacak?” sorusuna dönüştü.

Sorunun ortaya çıkışı

Kurum yedekleri değiştirilemez depoya taşırken ikinci lokasyonda iş yükü çalıştırmayı da planlıyordu. Yedek, replikasyon ve DR kavramları aynı proje adı altında kullanıldığı için yönetimin beklediği dönüş süresiyle teknik tasarım uyuşmuyordu.

Önce veri koruma ile hizmet kurtarma ayrıldı. Hangi veri kaybının kabul edilebilir olduğu RPO, hizmetin ne kadar sürede dönmesi gerektiği RTO ile ifade edildi. Bu hedefler uygulama sahipleri tarafından onaylanmadan teknoloji seçimine geçilmedi.

İlk belirtiler ve yanlış varsayımlar

Replika sistemin yedek olduğu sanılıyordu; kaynakta silinen veya bozulan veri replikaya da taşınabilir. Immutable kopyanın her felakette hızlı dönüş sağlayacağı varsayılıyordu; büyük veri hacmi, ağ kapasitesi ve yeniden kurulum süresi RTO’yu aşabilir.

Başarılı yedekleme işi de geri dönüş kanıtı değildir. Uygulama tutarlılığı, şifreleme anahtarı, DNS, kimlik, sertifika ve ağ bağımlılığı test edilmeden açılan sanal makine kullanılır hizmet anlamına gelmez.

Teknik analiz

Yedek veri noktası üretir; immutable katman bu noktaların belirli süre değiştirilmesini sınırlar. Replikasyon hazır kopyayı güncel tutar. DR ise altyapı, bağlantı, bağımlılık, runbook, karar yetkisi ve kullanıcı doğrulamasıyla hizmeti geri getirir. Katmanlar ayrı hata senaryolarına göre tasarlandı.

Her uygulama için veri kaynağı, bağımlı servis, yedek sıklığı, saklama, replikasyon, kurtarma sırası ve test yöntemi kaydedildi. Repository yönetim düzlemi ayrıldı; silme yetkileri ve saklama kilidi denetlendi.

Uygulanan çözüm veya önerilen mimari

3-2-1 yaklaşımını destekleyen, farklı hata alanlarında ve bir değiştirilemez kopya içeren katmanlı mimari kuruldu. Kritik iş yükleri için DR kapasitesi ayrıldı; daha düşük öncelikli sistemler yedekten geri yükleme planına alındı.

Runbook altyapı açılışından önce kimlik, DNS, ağ ve güvenlik bağımlılıklarını sıraladı. İzole kurtarma testleri üç aylık teknik doğrulama ve yıllık iş birimi tatbikatıyla yürütüldü. Ölçülen gerçek süreler hedef RTO ile karşılaştırıldı.

Alternatifler ve karar gerekçesi

Sürekli replikasyon düşük RPO sağlar fakat maliyet ve bozulma yayılımı riski getirir. Yedekten kurtarma daha ekonomik olabilir ancak büyük sistemlerde RTO uzar. Bulut DR esneklik sunar; veri çıkışı, bağımlılık, yetkinlik ve düzenli çalışma maliyeti değerlendirilmelidir.

Tek yöntem bütün uygulamalara uygulanmadı. İş etkisi yüksek sistemlere hazır kapasite, diğerlerine kademeli geri yükleme seçildi. Ürün adı değil ölçülen kurtarma hedefi karar ölçütü oldu.

Güvenlik ve operasyonel riskler

Yedek yöneticisi ile üretim yöneticisinin aynı kimlik alanına bağımlılığı fidye yazılımı etkisini büyütebilir. Ayrıcalıklar ayrılmalı, MFA ve değiştirilemezlik politikası korunmalı, silme girişimleri alarm üretmelidir.

Test edilmeyen runbook güncelliğini kaybeder. Lisans, DNS, sertifika ve üçüncü taraf bağlantıları kurtarmayı durdurabilir. Test verisi kişisel veri gereksinimlerine uygun korunmalı ve tatbikat üretim hizmetini riske atmamalıdır.

Çıkarılan Dersler

Kontrol Listesi