Kritik iş uygulamalarında yaşanan bir kesinti yalnızca teknik bir sorun olarak görülmemeli. Sipariş akışı durur, müşteri hizmetleri yavaşlar, finansal kayıtlar eksik kalabilir. Özellikle ERP, CRM, e-ticaret, üretim takip, saha operasyonu ve ödeme altyapıları gibi sistemlerde birkaç saatlik duruş bile ciddi sonuçlar doğurur. İyi kurgulanmış bir felaket kurtarma planı, bu riskleri tamamen ortadan kaldırmaz; ancak etki alanını sınırlar, toparlanma süresini kısaltır ve veri kaybını kabul edilebilir seviyede tutar.

Uygulamada en sık yapılan hata, yedek almayı felaket kurtarma ile aynı şey sanmaktır. Yedekleme gereklidir ama tek başına yeterli değildir. Asıl soru şudur: Sistem ne kadar sürede ayağa kalkacak? En fazla ne kadar veri kaybı kabul edilebilir? Hangi uygulama önce devreye alınmalı? Kim, hangi adımı uygulayacak? Bu rehberde, iş açısından kritik uygulamalar için uygulanabilir bir planın nasıl kurulacağını somut başlıklarla ele alıyoruz.

Felaket kurtarma planı tam olarak neyi kapsar?

Felaket kurtarma planı; sistem arızası, veri bozulması, insan hatası, siber saldırı ya da bölgesel altyapı problemi sonrasında BT hizmetlerini kontrollü biçimde geri getirme yaklaşımıdır. Kapsam sadece sunucularla sınırlı değildir. Veritabanı, dosya depoları, uygulama servisleri, ağ yapılandırmaları, DNS kayıtları, API entegrasyonları, erişim anahtarları ve bağımlı üçüncü taraf servisler de bu planın parçasıdır.

Burada iki temel ölçüt öne çıkar: RPO ve RTO. RPO, kabul edilebilir veri kaybı penceresini ifade eder. Örneğin RPO 15 dakika ise en fazla son 15 dakikalık veri kaybı tolere edilebilir. RTO ise sistemin yeniden ayağa kalkması için hedeflenen süredir. Bir sipariş yönetim sistemi için RTO 1 saat belirlenebilirken, iç raporlama ekranı için bu süre 8 saat olabilir. Aynı şirket içinde her uygulama için tek bir hedef kullanmak çoğu zaman doğru sonuç vermez.

Örnek bir senaryo düşünelim: B2B sipariş platformu, SQL veritabanı, Redis önbelleği, dosya depolama ve kargo API entegrasyonlarıyla çalışıyor. Platform 09:40'ta erişilemez hale geldiğinde, ekip yalnızca veritabanını geri yüklerse sorun çözülmez. Uygulama sırları, kuyruk servisleri, statik dosyalar ve dış servis erişimleri de kontrol edilmelidir. Bu nedenle felaket kurtarma planı, sistemin tamamını kapsayan operasyonel bir dökümandır.

İlk adım: iş etki analizi ve kritik sistem sınıflandırması

Planın temeli teknik envanter değil, iş etkisi analizidir. Hangi uygulama gelir üretimini etkiliyor? Hangisi yasal yükümlülük doğuruyor? Hangisi müşteri deneyimini doğrudan bozuyor? Bu sorular yanıtlanmadan yapılan yedekleme yatırımı çoğu zaman ya eksik kalır ya da gereksiz maliyet üretir.

İşe, uygulamaları kritik seviyelere ayırarak başlayın. Örneğin:

  • Seviye 1: Kesintisi 1 saat içinde gelir veya operasyon kaybı yaratan sistemler. ERP sipariş modülü, ödeme servisi, üretim planlama ekranı.
  • Seviye 2: Aynı gün içinde geri dönmesi gereken ama anlık kesintisi tolere edilebilen sistemler. CRM rapor ekranları, bayi portalı.
  • Seviye 3: Gecikmeli toparlanması kabul edilebilen sistemler. Arşiv, iç dokümantasyon, tarihsel raporlar.

Bu sınıflandırmanın ardından her uygulama için hedefler yazılı hale getirilir. Örneğin müşteri destek platformunda RTO 4 saat, RPO 30 dakika olabilir. Finansal mutabakat veritabanında ise RPO 5 dakikanın üstüne çıkmak istenmeyebilir. Ölçü koymadığınız her başlık belirsiz kalır; belirsizlik de kriz anında zaman kaybına yol açar.

Bağımlılık haritası çıkarın

Bir web uygulaması tek başına çalışmaz. DNS, kimlik doğrulama servisi, mesaj kuyruğu, nesne depolama, lisans sunucusu veya banka entegrasyonu olmadan açılış tamamlansa bile işlev oluşmaz. Bu yüzden en azından tablo düzeyinde bir bağımlılık matrisi hazırlanmalıdır. Örneğin “Mobil saha uygulaması → API Gateway → PostgreSQL → Nesne Depolama → SMS Servisi” gibi bir akış, toparlanma sırasını netleştirir.

Yedekleme mimarisi: 3-2-1 mantığı ve versiyonlama

Felaket kurtarma planının omurgasını yedekleme mimarisi oluşturur. Sektörde sık kullanılan yaklaşım 3-2-1 kuralıdır: Verinin en az 3 kopyası bulunur; 2 farklı ortamda tutulur; bunlardan 1'i ana sistemden ayrı lokasyondadır. Bu model her kuruma birebir aynı şekilde uygulanmak zorunda değildir. Yine de tek disk, tek bulut hesabı ya da aynı ağ segmentindeki kopyalar gerçek koruma sağlamaz.

Veritabanı yedeği ile dosya yedeğini aynı stratejiyle ele almak da yanlıştır. İlişkisel veritabanlarında tam yedek, artımlı yedek ve işlem günlüğü yaklaşımı birlikte kullanılabilir. Büyük dosya depolarında ise nesne versiyonlama, silme koruması ve yaşam döngüsü politikaları daha verimli sonuç verir. 500 GB'lık bir medya arşivini her gece sıfırdan kopyalamak yerine blok seviyesinde ya da artımlı yaklaşım tercih edilir.

Özellikle fidye yazılımı riskinde değiştirilemez yedekler büyük önem taşır. Bir saldırgan üretim ortamına sızdıysa, ağ üzerinde yazılabilir durumdaki yedekleri de şifreleyebilir. Bu nedenle belirli süre boyunca silinemeyen ya da değiştirilemeyen saklama politikaları değerlidir. Burada teknoloji seçimi kadar erişim modeli de belirleyicidir: üretim erişimi ile yedek erişimi aynı kimlik ve aynı yetki setiyle yönetilmemelidir.

Uygulama-tutarlı yedek alın

Yedek dosyası almak ile çalışan bir sistemi geri getirmek arasında ciddi fark vardır. Örneğin çalışan bir veritabanı sunucusunun disk görüntüsünü almak, bazı durumlarda tutarsız veri üretebilir. Uygulama-tutarlı yedekleme için servislerin kısa süreli dondurulması, snapshot koordinasyonu ya da veritabanı seviyesinde dump ve log alma süreçleri gerekir. Özellikle ERP ve muhasebe uygulamalarında bu ayrım kritiktir.

# PostgreSQL örnek mantık
pg_basebackup -D /backup/base -Ft -z -P
# ardından WAL arşivleme ile nokta atışı geri dönüş planlanır

Kurtarma hedefleri nasıl belirlenir?

Her sistem için en pahalı altyapıyı kurmak doğru yaklaşım değildir. RTO ve RPO hedefleri, iş önceliğine göre belirlenmelidir. Örnek bir dağılım üzerinden gidelim:

  • E-ticaret ödeme akışı: RTO 30 dakika, RPO 5 dakika
  • Bayi sipariş ekranı: RTO 2 saat, RPO 15 dakika
  • İç insan kaynakları portalı: RTO 8 saat, RPO 24 saat

Bu hedefler mimari tercihi doğrudan etkiler. 5 dakikalık RPO istiyorsanız günlük gece yedeği yeterli olmaz. Replikasyon, sık snapshot, transaction log shipping ya da sürekli veri koruma benzeri yöntemler gerekebilir. Benzer biçimde 30 dakikalık RTO için sadece “gerekirse yeniden kurarız” yaklaşımı gerçekçi değildir; otomasyon, hazır altyapı şablonları ve test edilmiş geri dönüş adımları gerekir.

Bulut tabanlı ortamlarda altyapıyı kod olarak tanımlamak burada ciddi avantaj sağlar. Sanal ağ, güvenlik grupları, veritabanı parametreleri, konteyner servisleri ve gizli anahtar referansları tekrar üretilebilir hale gelir. Elle yapılan kurulumlarda 20 adım varsa, kriz anında bu adımların 1-2'sinin atlanması bile toparlanmayı uzatır.

Failover, yeniden ayağa kaldırma ve iletişim akışı

Plan yalnızca teknik geri yükleme komutlarından ibaret olmamalı. Hangi olayda failover yapılacak, hangi olayda mevcut ortam onarılacak, kararı kim verecek; bunlar da net şekilde tanımlanmalı. Çünkü her kesinti felaket seviyesi değildir. Yanlış zamanda ikincil ortama geçmek, teknik sorundan daha büyük veri tutarsızlıkları yaratabilir.

Örneğin tek bölgedeki bir bulut altyapısında çalışan SaaS uygulamasını ele alalım. Ana veritabanı erişimi 25 dakikadır yoksa ve sağlayıcı tarafında çözüm süresi belirsizse, olay yöneticisi ikincil bölgeye geçiş onayı verebilir. Plan dokümanında şu başlıklar yer almalıdır:

  • Olayın seviye tanımı ve tetikleyicisi
  • Karar yetkisi: teknik lider, ürün sahibi, operasyon yöneticisi
  • Geçiş sırası: veritabanı, uygulama servisleri, kuyruklar, DNS
  • İç iletişim kanalı: telefon, mesajlaşma, acil durum grubu
  • Müşteri iletişimi: durum sayfası, e-posta, SLA bildirimi

DNS TTL değeri bile burada belirgin fark yaratır. 300 saniyelik TTL ile 24 saatlik TTL aynı davranışı üretmez. Eğer failover stratejiniz alan adı yönlendirmesine dayanıyorsa, bu parametre önceden planlanmalıdır. Kriz anında fark edilen ayrıntılar genellikle pahalıya mal olur.

Test edilmeyen plan, plan değildir

En sık karşılaşılan açık budur. Doküman vardır, yedek vardır, hatta izleme ekranları da vardır. Ancak geri dönüş hiç denenmemiştir. İlk gerçek test, gerçek kesinti anında yapılır. Bu oldukça riskli bir durumdur.

En az yılda 2 kez masa başı tatbikat yapılması iyi bir başlangıçtır. Kritik sistemler için yılda 1 kez tam veya kısmi geri yükleme provası önerilir. Örneğin 1 TB veritabanı kullanan bir üretim sistemi için, seçilen yöntemin test ortamında kaç dakikada geri döndüğü ölçülmelidir. “Hızlı geri döner” ifadesi yerine “47 dakikada servis verdi” gibi sonuçlar kayda geçirilmelidir.

Test senaryolarını çeşitlendirin

Tek bir senaryo yeterli olmaz. Şu durumlar ayrı ayrı ele alınabilir:

  • Yanlışlıkla veri silinmesi ve nokta atışı geri dönüş
  • Uygulama sunucusunun tamamen kaybı
  • Bölgesel bulut kesintisi
  • Şifrelenmiş yedek anahtarının erişilememesi
  • API sağlayıcısının devre dışı kalması

Her testin sonunda süre, hata, manuel müdahale ihtiyacı ve eksik dokümantasyon not edilmelidir. Plan yaşayan bir varlıktır. Yeni modül eklendiyse, veritabanı yapısı değiştiyse veya monolit servis mikroservislere ayrıldıysa doküman da buna göre güncellenmelidir.

Sık yapılan hatalar ve daha sağlam bir yaklaşım

Kurumların önemli bir kısmı yedek aldığını düşünür ama geri dönüş kabiliyeti sınırlıdır. Bunun birkaç tipik nedeni vardır. İlk olarak, üretim ve yedek ortamının aynı kimlik bilgileriyle yönetilmesi yaygındır. İkinci olarak, yalnızca veritabanına odaklanılıp dosya depoları, entegrasyon sırları ve uygulama konfigürasyonları gözden kaçırılır. Bir diğer sorun da tüm sistemlere aynı RTO/RPO hedefinin verilmesidir.

Daha sağlam bir yaklaşım şu çerçevede kurulur: uygulamaları kritik seviyeye göre ayırın, her biri için ölçülebilir hedefler belirleyin, yedekleri ayrıştırın, geri dönüşü otomasyona bağlayın ve düzenli test edin. Felaket kurtarma planı pahalı olmak zorunda değildir; gereksinime göre katmanlı biçimde kurgulanabilir. 20 kullanıcıya hizmet veren iç portal ile 7/24 sipariş alan platform aynı modelle korunmaz.

Kurumsal ölçekte bakıldığında en iyi sonuç, yazılım mimarisi ile operasyon tasarımının birlikte ele alınmasıyla elde edilir. Uygulama geliştirirken yedekleme, gözlemlenebilirlik, sır yönetimi, altyapı kodu ve olay müdahale adımlarını en baştan kurgulamak; sonradan eklenen yamalı çözümlere göre çok daha güvenilir bir yaklaşım sunar.

Özetle, iyi bir felaket kurtarma planı yalnızca veri kopyalamaz; iş sürekliliğini yönetir. Hangi sistemin ne kadar sürede geri döneceğini, ne kadar veri kaybının tolere edileceğini ve bu hedefe hangi teknik düzenekle ulaşılacağını netleştirir. Kritik iş uygulamalarında asıl fark, kriz çıktığında değil, krizden önce yapılan bu hazırlıkta ortaya çıkar.