> tpl_ops_009
Felaket Kurtarma ve Teknoloji Sürekliliği Planı
Kurtarma Süresi Hedeflerini (RTO), Kurtarma Noktası Hedeflerini (RPO), çok bölgeli replikasyon mimarilerini (Warm Standby / Pilot Light), otomatik arıza geçiş işletim kitaplarını ve yıllık habersiz DR tatbikat protokollerini belirleyen kurumsal felaket kurtarma ve teknoloji sürekliliği planı.
RTO/RPO hedeflerini, çok bölgeli veritabanı replikasyonunu, otomatik DNS arıza geçişini ve habersiz felaket testlerini düzenleyen ana DR planı.
Önemli Teknik Doküman Şablonu ve Hukuki Uyarı
TinyCTO.tv Teknik Doküman Şablon Bildirimi: Bu şablon genel eğitim ve operasyon amaçlı bir başlangıç materyalidir. Hukuki, vergisel, muhasebesel, yatırım, satın alma, mevzuat, güvenlik veya sertifikasyon danışmanlığı değildir. Gereklilikler ülkeye, kuruma, sözleşmeye ve riske göre değişir. Kullanmadan önce yetkin uzmanlarla gözden geçirip uyarlayın.
Çözülen Üretim Problemi
Kuruluşlar hiç test edilmemiş teorik kağıt üzeri felaket planları tutar; gerçek bir bölgesel bulut çöküşünde replikasyonun kopuk olduğunu ve veritabanlarının kurtarılamadığını dehşetle keşfeder.
Ne Zaman Kullanılmalı?
- •Seviye 1 finansal veya sağlık sistemleri için sözleşmeye bağlı RTO (<15 dk) ve RPO (<1 dk) garantileri kurarken
- •Çok bölgeli veya hibrit bulut arıza geçiş stratejileri tasarlarken (Aktif/Pasif veya Aktif/Aktif)
- •Dış denetçiler eşliğinde zorunlu yıllık mevzuatsal felaket kurtarma simülasyon tatbikatları yürütürken
Ne Zaman Kullanılmamalı?
- •Tekil bir dosyanın kazara silinmesi sonrası yapılan günlük geri yüklemelerde (TPL-OPS-010 kullanın)
- •Taktiksel kriz odası olay müdahalesinde (TPL-OPS-007 kullanın)
5 Şablon Bölümü ve Yapısal İskelet
İş yüklerini Seviye 1 (RTO <15 dk, RPO <1 dk), Seviye 2 (RTO <2 sa, RPO <15 dk) ve Seviye 3 (RTO <24 sa, RPO <4 sa) olarak sınıflandırma.
Stratejilerin değerlendirilmesi: Yedekten Dönüş (Cold), Pilot Light (minimum çekirdek aktif), Warm Standby (küçültülmüş kopya) ve Aktif/Aktif.
Sürekli blok/akış eşitlemesi, nesne kilitli (WORM) bölgeler arası S3 replikasyonu ve fidye yazılımlarına karşı tamamen izole AWS hesabı.
Sağlık kontrollü Route 53 yönlendirmesi, Anycast IP geçişi (Global Accelerator) ve veritabanı replikasının ana sunucuya yükseltilmesi.
Zorunlu arıza geçiş tatbikatları, simüle edilmiş tam bulut bölge çöküşü, geçiş süresi ölçümü ve bağımsız denetçi doğrulaması.
Doldurma ve Uygulama Yönergeleri
Bağımsız İnceleme ve Onay Kontrol Listesi
- Tüm zorunlu bölümler dolduruldu
- Gizli anahtar veya parola içermiyor
- Yönetici sponsor onayı alındı
Felaket Kurtarma ve Teknoloji Sürekliliği Planı - Örnek Vaka Analizi
Örnek Organizasyon: Sovereign Dijital Banka Çok Bölgeli Pilot Light Felaket Kurtarma Mimarisi
Sovereign Dijital Banka Çok Bölgeli Pilot Light Felaket Kurtarma Mimarisi için eksiksiz operasyonel uygulamayı gösteren gerçek dünya vaka analizi.
- •Frankfurt'tan Dublin'e uzanan Pilot Light mimarisi ile 11 dakikalık RTO ve 35 saniyelik RPO elde edildi
- •Finansal işlem günlüklerinin %100'ü fidye yazılımlarına karşı korumalı hava boşluklu WORM deposunda güvenceye alındı
- •Merkez Bankası'nın habersiz bölgesel çöküş denetiminden sıfır veri kaybı ve otomatik geçiş doğrulaması ile tam not alındı
Sıkça Sorulan Sorular
RTO (Kurtarma Süresi Hedefi) ile RPO (Kurtarma Noktası Hedefi) arasındaki kesin fark nedir?
RTO, iş operasyonları geri yüklenene kadar sistemin kapalı kalabileceği azami kabul edilebilir süredir ("15 dakika içinde tekrar yayında olmalıyız"). RPO ise zaman cinsinden ölçülen azami kabul edilebilir veri kaybı miktarıdır ("Veritabanı kurtarıldığında 60 saniyeden daha eski işlemleri kaybetmiş olamayız").
"Pilot Light" felaket kurtarma modeli nedir ve bulut mimarilerinde neden popülerdir?
Pilot Light modelinde, kritik veri çekirdeği (veritabanları ve nesne depoları) ikinci bir bulut bölgesine gerçek zamanlı eşitlemeyle sürekli akar; ancak sunucular ve API ağ geçitleri kapalı veya sıfıra ölçeklenmiş tutulur. Felaket anında otomatik betikler dakikalar içinde sunucuları açar; böylece tam Aktif/Aktif maliyetinden %70-80 tasarruf ederken 15 dakika altı RTO sağlar.
Felaket kurtarma yedekleri neden ayrı, hava boşluklu (air-gapped) bir bulut hesabında tutulmalıdır?
Modern fidye yazılımı korsanları sadece sunucuları şifrelemekle kalmaz; önce yedekleme kimlik bilgilerini ele geçirip snapshot'ları ve S3 depolarını siler. Değiştirilemez yedekleri hesaplar arası IAM, MFA silme ve Nesne Kilidi (WORM) ile tamamen ayrı bir hesapta tutmak, ana hesap ele geçirilse bile yedeklerin yok edilmesini imkânsız kılar.
Teknik Doküman Şablon Paketi
Giriş GerekliTüm boş şablonları, işlenmiş senaryoları ve doğrulama manifestolarını tek bir arşivde indirin.
Yetkili Standartlar ve Kaynaklar
- ISO 22301:2019 Security and Resilience — Business Continuity Management SystemsInternational Organization for Standardization • OFFICIAL REQUIREMENT
- AWS Disaster Recovery Architecture StrategiesAmazon Web Services • OFFICIAL REQUIREMENT