Yedekleme, verinin veya sistemin geri yüklenebilir kopyalarını oluşturur. Felaket kurtarma ise bir kesinti sonrasında sistemlerin ve hizmetlerin nasıl yeniden çalıştırılacağını planlar. Ortam, erişim, bağımlılıklar ve testler de bu planın parçasıdır.
Bir sunucunun kopyasını almak, o sunucunun çalıştırdığı işi başka bir ortamda devam ettirmekle aynı hazırlık değildir. Yedekleme veri korumasına, yüksek erişilebilirlik belirli arızaların etkisini azaltmaya, felaket kurtarma ise kullanılamayan bir ortamdan sonra hizmeti yeniden çalıştırmaya odaklanır. İş sürekliliği bu teknik yapıları iş süreçleri, insanlar ve alternatif çalışma yöntemleriyle bir araya getirir.
Bu ayrım özellikle iki durumda önemlidir: yedekleri bulunduğu için uzun bir kesintiye hazır olduğunu düşünen işletmelerde ve replikasyonu bulunduğu için geçmiş veri kopyasına ihtiyaç duymadığını varsayan ortamlarda. İki durumda da korunan risk ile beklenen sonuç birbirinden farklı olabilir.
1. Dört kavram, dört ayrı tasarım sorusu
| Katman | Temel soru | Örnek yapı |
|---|---|---|
| Yüksek erişilebilirlik | Bir bileşen arızasında hizmet nasıl sürecek? | Yedekli erişim, cluster ve devralma |
| Yedekleme | Verinin hangi geçmiş noktasına dönebiliriz? | Saklama politikası ve doğrulanmış kopyalar |
| Felaket kurtarma | Ana ortam yoksa hizmeti nerede çalıştırırız? | Alternatif ortam, veri ve erişim planı |
| İş sürekliliği | Kritik işler olay boyunca nasıl devam eder? | Teknik dayanıklılık, görevler ve alternatif işleyiş |
Tablonun tamamı için yana kaydırabilirsiniz.
Örneğin sanallaştırma HA’sı, arızalanan fiziksel sunucudaki sanal makineyi başka bir sunucuda yeniden başlatabilir. Ancak uygulama verisi yanlışlıkla silindiyse aynı yanlış veri diğer ortamda da bulunabilir. Öte yandan sağlam bir yedek olsa bile onu çalıştıracak donanım, bağlantı ve yetki yoksa hizmetin geri dönüşü uzar.
2. RPO ile RTO aynı hedef değildir
RPO, olaydan sonra dönülebilecek veri noktasının ne kadar geride olabileceğini tanımlar. RTO, hizmetin geri getirilmesi için hedeflenen süredir. İş birimi bir saatlik veri kaybını tolere edebilir ama uygulamanın dört saat kapalı kalmasını kabul etmeyebilir; iki karar ayrı görüşülmelidir.
Örnek olarak kesinti 14.00’te oluşsun, kullanılabilir en güncel veri noktası 13.40 olsun ve hizmet 15.10’da doğrulanarak açılsın. Bu testte veri noktası olaydan 20 dakika geridedir; hizmetin geri dönüşü 70 dakika sürmüştür. Bunlar ölçülen sonuçlardır. Hedefler RPO 15 dakika ve RTO 60 dakika ise test her iki hedefi de karşılamamıştır.
NIST’in süreklilik planlama yaklaşımı, bu hedeflerin iş etkisi ve sistem önceliğiyle bağlantısını kurar. NIST SP 800-34 Rev. 1. Bir hedefin sözleşmeye yazılması teknik mimarinin onu otomatik karşılayacağı anlamına gelmez; veri aktarımı, kapasite ve kabul testleriyle doğrulanmalıdır.
3. Replikasyon geçmişe dönüş ihtiyacını ortadan kaldırmaz
Replikasyon bir ortamdaki değişiklikleri diğerine taşır. Bu değişiklik doğru bir işlem olabileceği gibi yanlış silme veya uygulama hatası da olabilir. Bu nedenle güncel replika ile geçmişteki güvenilir veri noktası farklı korumalardır. RAID de disk arızasının belirli etkilerine karşı tasarlanır; dosya silme veya bütün lokasyonun kaybı için tek başına yedek sayılmaz.
Asenkron replikasyonda henüz hedefe ulaşmamış değişiklikler bulunabilir. Senkron modellerde onay davranışı veri kaybı penceresini azaltabilir; buna karşılık bağlantı ve hedef sistemin durumu işlem gecikmesini veya yazma erişilebilirliğini etkileyebilir. PostgreSQL’in standby ve replikasyon dokümantasyonu bu farkları ürün özelinde açıklar. Tasarım yalnız “replika var” bilgisiyle değerlendirilmemelidir.
Veri bütünlüğü için tek yetkili yazım noktası, güvenli devralma ve yeniden eşitleme yöntemi de gerekir. Ana ortam geri geldiğinde otomatik olarak eski rolüne dönmesi beklenmez; hangi tarafın güncel veriyi taşıdığı doğrulanarak dönüş planlanır.
4. Kurtarma ortamının hazırlık seviyesi süreyi değiştirir
Yedekten kurulum modelinde önce hesaplama, ağ ve gerekli servisler hazırlanır; ardından veri yüklenir. Pilot light yaklaşımında bazı temel bileşenler hazır tutulur, olay anında kalan kapasite devreye alınır. Warm standby modelinde daha küçük ölçekte çalışan bir ortam bulunabilir. Aktif/aktif tasarım ise iş yükünü birden fazla çalışan ortam arasında dağıtabilir, fakat veri ve uygulama tasarımını daha karmaşık hâle getirir.
Bu seçeneklerin adları tek başına bir süre taahhüt etmez. AWS’nin felaket kurtarma stratejileri açıklaması, farklı hazırlık seviyelerini karşılaştırmak için yararlı bir çerçeve sunar. Hangi ürün kullanılırsa kullanılsın kapasite açma, veri tutarlılığı ve kullanıcı erişimi gerçek ortamda sınanmalıdır.
ERP’yi geri getirmek için yalnız ERP sanal makinesi yetmeyebilir: ağ → DNS ve kimlik → veritabanı → dosya deposu → uygulama → entegrasyonlar → kullanıcı kabulü. Bazı adımlar paralel yapılabilir; gerçek sıra uygulamanın bağımlılıklarına göre çıkarılır.
5. Yedeğin geri yüklenebilirliğini katmanlı doğrulayın
Başarılı görev kaydı ilk kontroldür. Ardından kopya bütünlüğü, uygulama tutarlılığı ve iş işleminin çalışması değerlendirilir. Veritabanının açılması, bütün entegrasyonların doğru veriyle çalışacağını göstermez. Veritabanı ve dosya deposu farklı zaman noktalarından geliyorsa uygulamada eksik belge veya tutarsız kayıt oluşabilir.
Belirli bir zamana dönüş için ürünün gerektirdiği temel kopyalar ve günlük zinciri eksiksiz olmalıdır. PostgreSQL PITR örneğinde temel yedekle birlikte hedef zamana kadar gerekli WAL kayıtları gerekir. Yapılandırma dosyalarının, anahtarların ve dış dosya depolarının ayrıca korunması gerekebilir. PostgreSQL sürekli arşivleme ve PITR.
Test raporu hangi kopyanın kullanıldığını, ne kadar verinin geri getirildiğini, geçen süreyi ve uygulanan iş kontrolünü kaydetmelidir. Sadece küçük bir dosyanın geri yüklenmesiyle büyük veritabanının aynı sürede açılacağı çıkarımı yapılamaz.
6. Yedekleri ana ortamın saldırı ve arıza alanından ayırın
Canlı sistem ve yedek deposu aynı ayrıcalıklı hesaplarla yönetiliyorsa hesap ele geçirilmesi her iki alanı etkileyebilir. Yönetim erişimi, saklama yetkisi ve silme işlemleri ayrı değerlendirilmelidir. Fiziksel ya da mantıksal olarak ayrılmış kopyalar, aynı olayın bütün geri dönüş yollarını etkilemesini azaltmayı amaçlar.
Değiştirilemezlik (immutability), belirli saklama koşullarında verinin değiştirilmesini veya silinmesini sınırlayan bir mekanizmadır. Çevrimdışı kopya ise erişim yolunun ayrılmasıyla ilgilidir. Aynı kavram değildirler. Saklama süresi, yetkili yönetici davranışı, anahtarların korunması ve ürünün desteklediği koruma modeli incelenmelidir. Hiçbir etiket, yapılandırma ve geri yükleme testinin yerine geçmez.
7. Tatbikatın bitiş noktası işin yeniden çalışmasıdır
İyi bir tatbikat yalnız teknik ekibin kurulum hızını ölçmez. Karar verme, olay iletişimi, alternatif ortama erişim, iş birimi doğrulaması ve normal ortama dönüş adımlarını da kapsar. Başlangıçta masa başı senaryosu yapılabilir; ardından izole kurtarma testi ve uygun koşullarda planlı devralma denenebilir.
Sonuçta RTO/RPO hedefleri, erişim sorunları, eksik belgeler ve manuel adımlar birlikte değerlendirilir. Açık kalan bulguların sorumlusu ve tamamlanma planı belirlenir. Böylece yedekleme bir “başarılı görev” ekranı olmaktan çıkar; yüksek erişilebilirlik ve felaket kurtarmayla birlikte işletmenin devamlılığına ölçülebilir katkı verir.
Sık sorulan sorular
Replikasyon yedekleme yerine geçer mi?
Her risk için geçmez. Hatalı veya zararlı değişiklikler başka kopyalara da taşınabilir. Saklama ve geri dönüş senaryoları ayrıca değerlendirilmelidir.
Kurtarma hedeflerini belirledikten sonra iş biter mi?
Hayır. Tasarımın bu hedefleri karşılayıp karşılamadığı test edilmeli; ortam değiştikçe plan güncellenmelidir.