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

Felaket kurtarma toplantıları çoğu zaman kaç sanal makinenin replike edileceğiyle başlıyor. İlk sorduğum soru ise hangi iş sürecinin önce dönmesi gerektiğidir. Çünkü yüz sunucuyu yanlış sırada açmak, üç kritik hizmeti doğru sırada açmaktan daha az değerli olabilir.

22 Şubat 2026 tarihli çalışmada teknik envanteri iş etkisi analiziyle eşleştirdik. Uygulama sahibi, altyapı ekibi ve yönetim aynı “kritik” kelimesine farklı anlam verdiği için kararları ölçülebilir süre ve kabul edilebilir veri kaybıyla ifade ettik.

Atölyelerde “Bu sistem duramaz” cevabını doğrudan kabul etmedik; kesintinin bir saat, bir gün ve üç gün sonraki etkisini ayrı sorduk. Finansal kayıp tek ölçüt değildi. İş güvenliği, yasal bildirim, müşteri taahhüdü, üretim planı ve biriken manuel işlem yükü de değerlendirildi. Ayrıca geçici manuel yöntem gerçekten uygulanabilir mi, gereken form ve yetki çevrimdışı bulunabilir mi diye kontrol ettik. Bu görüşmeler bazı sistemlerin beklenenden daha kritik, bazılarının ise birkaç gün kontrollü biçimde bekleyebileceğini gösterdi. Sonuçta DR kapasitesi eşit dağıtılmadı; işin kritik yoluna ve doğrulanmış bağımlılıklara yönlendirildi.

Sorunun ortaya çıkışı

Çok sayıda uygulama DR kapsamına alınmak isteniyor, fakat iş önceliği ve bağımlılık bilgisi bulunmuyordu. Her sistem kritik işaretlenince kapasite ve proje maliyeti gerçekçi olmaktan çıktı.

BIA atölyelerinde süreç kesintisinin zaman içindeki etkisi, manuel çalışma alternatifi, veri kaybı toleransı ve mevzuat yükümlülüğü soruldu. Teknik ekip bu sonuçları servis ve altyapı bağımlılıklarına çevirdi.

İlk belirtiler ve yanlış varsayımlar

Uygulamanın açılması hizmetin dönmesi sayılıyordu. Kimlik, ağ, DNS, veri tabanı, dosya paylaşımı ve dış entegrasyon çalışmadan uygulama kullanılamaz. Her sistem için sıfıra yakın RPO/RTO istemek de teknik ve mali gerçekliği göz ardı eder.

DR lokasyonunun her senaryoda kullanılabilir olacağı varsayılamaz. Aynı kimlik bağımlılığı, ortak telekom güzergâhı veya bölgesel olay iki ortamı birden etkileyebilir. Personel erişimi ve karar yetkisi de tasarımın parçasıdır.

Teknik analiz

Servis kataloğu sunucu envanteriyle eşleştirildi. Her servis için sahip, kullanıcı grubu, veri kaynağı, upstream ve downstream bağımlılık, RPO, RTO, minimum kapasite ve doğrulama adımı yazıldı. Kritik yol diyagramı kurtarma dalgalarını belirledi.

Kapasite hesabı normal zirveyi kopyalamak yerine felaket anındaki minimum kabul edilebilir hizmete göre yapıldı. Ağ adresleme, isim çözümleme, sertifika, lisans ve üçüncü taraf izinleri test sorularına eklendi.

Uygulanan çözüm veya önerilen mimari

Servisler üç kurtarma dalgasına ayrıldı. Runbook teknik komut listesinden ibaret tutulmadı; karar, iletişim, bağımlılık kontrolü, iş birimi testi ve normale dönüş adımlarını içerdi.

Masa başı tatbikatla belirsiz roller bulundu, ardından izole teknik test yapıldı. Test sonucu gerçek RTO, veri noktası, başarısız bağımlılık ve düzeltme sahibiyle kaydedildi. Mimari bu ölçümlere göre güncellendi.

Alternatifler ve karar gerekçesi

Aktif-aktif, sıcak bekleme, pilot light ve yedekten geri yükleme farklı maliyet ve süre profillerine sahiptir. En pahalı model her iş yükü için en doğru model değildir. Uygulama mimarisi ve iş etkisi seçimde belirleyicidir.

Karma yaklaşım seçildi: en kritik servisler hazır kapasiteye, toleranslı servisler yedekten dönüşe bağlandı. Karar üretici özelliklerinden önce ölçülebilir iş hedefleriyle gerekçelendirildi.

Güvenlik ve operasyonel riskler

DR ortamı daha seyrek kullanıldığı için yama ve erişim açısından zayıf kalabilir. Üretimle aynı güvenlik tabanı, ayrıcalık kontrolü ve izleme uygulanmalıdır. Replikasyon zararlı değişikliği taşıyabileceğinden temiz kurtarma noktası korunmalıdır.

Eski iletişim listesi ve tek kişiye bağlı runbook tatbikatta başarısız olur. Roller yedeklenmeli, çevrimdışı erişilebilir kopyalar tutulmalı ve üçüncü tarafların kriz yükümlülükleri sözleşmede doğrulanmalıdır.

Çıkarılan Dersler

Kontrol Listesi