1. Felaket Kurtarma Neden Sadece Yedekleme Değildir?
Yedekleme, veriyi bir kopya olarak saklamaktır; DR ise kopyayı kullanarak sistemi belirli hedeflerde ayağa kaldırma kabiliyetidir. Aradaki fark; süreç, sorumluluk, otomasyon, test ve karar mekanizmasında ortaya çıkar. Yedek “var” olabilir; ama kurtarma planı ve tatbikat yoksa kesintide gerçek sonuç belirsizdir.
Yedekleme ile disaster recovery arasındaki fark nedir?
Yedekleme; verinin kopyasını tutar. Disaster recovery ise bu yedeklerle sistemi belirlenmiş RPO/RTO hedeflerinde tekrar çalışır hale getirme planı, altyapısı ve testidir. DR; failover/rollback adımlarını, sorumluları, tatbikatları ve ölçümü içerir.
DR’yi “iş sürekliliği” olarak düşünmek
Otel/B2B bağlamında kritik soru şudur: “Kesinti olduğunda iş devam edebiliyor mu?”
- •Otel: rezervasyon, ödeme, müsaitlik görüntüleme, call center satış
- •B2B: portal erişimi, CRM iş akışları, teklif/servis süreçleri
- •DR hedefleri, bu iş akışlarının kritikliğiyle belirlenmelidir.
☑ Mini Check : DR hazır mıyım? (hızlı test)
- •RPO ve RTO hedefi yazılı mı?
- •Offsite yedek var mı (farklı lokasyon)?
- •Son 90 günde restore testi yapıldı mı?
- •Failover/rollback adımları dokümante mi?
- •Kim hangi durumda karar alır (eskalasyon) net mi?
Ne yapmalıyım?
- • “Yedek var mı?” yerine “RPO/RTO ne?” diye sor ve hedef koy.
- • Offsite zorunlu: aynı lokasyonda yedek DR değildir.
- • Restore testini takvime bağla (aylık/çeyreklik).
- • Runbook ve sorumlulukları yaz; tatbikatla doğrula.
2. RPO/RTO Kavramları
RPO ve RTO, DR’nin “ölçülebilir hedefleri”dir. Yönetimle aynı dili konuşmanızı sağlar; teknik ekip için de tasarım kararlarını netleştirir.
RPO ve RTO ne demek, nasıl belirlenir?
- •RPO (Recovery Point Objective): “Ne kadar veri kaybı kabul edilebilir?” Örn. 15 dakika, 1 saat, 24 saat.
- •RTO (Recovery Time Objective): “Ne kadar sürede ayağa kalkmalıyım?” Örn. 30 dakika, 4 saat, 1 gün.
Belirleme yöntemi; kritik iş akışlarını listelemek (rezervasyon/portal), kesintinin maliyetini ve operasyonel etkisini değerlendirmek ve buna göre hedef koymaktır.
Otel ve B2B için pratik hedefleme yaklaşımı
- •Rezervasyon/ödeme: daha sıkı RPO/RTO
- •İçerik sayfaları: daha esnek olabilir
- •B2B portal/CRM: iş saatleri ve SLA’lara göre değişir
- •Önemli nokta: hedefler “hayal” değil, test edilebilir olmalıdır.
☑ Mini Check : RPO/RTO netliği
- •Hangi sistemler Tier-1 (en kritik) tanımlandı mı?
- •Tier-1 için RPO/RTO yönetimle onaylı mı?
- •Hedefler yedekleme sıklığı ve restore süresiyle uyumlu mu?
- •Ölçüm metriği tanımlı mı (restore süresi, veri kaybı)?
- •Tatbikat sonucu hedefler revize ediliyor mu?
Ne yapmalıyım?
- • Sistemleri Tier-1/2/3 olarak sınıflandır.
- • Tier-1’e RPO/RTO hedefi koy; backup planını buna bağla.
- • Hedefleri test et; tutmuyorsa ya hedefi ya mimariyi güncelle.
- • DR planını bakım-destek süreçlerine entegre et: https://dgtlface.com/tr/yazilim/bakim-ve-destek
3. Yedekleme Türleri (Full, Incremental, Snapshot)
DR planının kalbi, doğru yedek türlerini doğru kombinasyonla kullanmaktır. Tek bir yöntem her şey için ideal değildir; veri türü, değişim hızı ve RPO hedefi belirleyicidir.
Full backup
Tüm verinin komple kopyasıdır. Geri dönüş için sağlamdır; ancak süre ve depolama maliyeti yüksektir. Genelde haftalık/aylık temel taş olarak kullanılır.
Incremental / differential yaklaşımlar (prensip)
Artımlı yedekler, değişen veriyi daha sık almayı sağlar. RPO’yu iyileştirir; ancak restore süreci zincire bağlı olabilir. Bu nedenle “restore süresi” RTO hedefiyle birlikte düşünülmelidir.
Snapshot ve imaj yedekleri
Snapshot’lar hızlı geri dönüş sağlar; imaj yedekleri ise komple sistemin belirli bir anını taşır. Bu yöntemler, hızlı ayağa kalkma isteyen senaryolarda (düşük RTO) avantaj sunar; ancak offsite ve test şarttır.
☑ Mini Check : Yedek türü seçimi
- •DB ve dosya sistemi ayrı stratejiyle ele alındı mı?
- •Full + incremental/snapshot dengesi kuruldu mu?
- •Restore zinciri RTO hedefini bozuyor mu?
- •Snapshot’lar offsite’a taşınıyor mu?
- •Yedeklerin bütünlük doğrulaması yapılıyor mu?
Ne yapmalıyım?
- • Veriyi sınıflandır: DB, dosya, config, secrets (secrets ayrı yönetim).
- • RPO sıkıysa incremental/snapshot’ı artır; RTO sıkıysa imaj/snapshot’ı güçlendir.
- • Restore süresini ölç; zincir uzunsa sadeleştir.
- • Yedek bütünlüğü ve geri dönüş doğrulamasını otomatikleştir.
4. On-Prem ve Bulut Yedekleme Senaryoları
DR’nin en kritik prensibi: farklı lokasyon (offsite). Aynı veri merkezinde veya aynı hesapta tutulan yedekler, felaket senaryosunda “birlikte yanabilir.”
On-prem senaryosu
- •Ayrı lokasyonda replikasyon veya offsite kaset/depoya çıkış
- •Ağ erişimi ve güvenliği (kopya güvenliği)
- •Failover için ikinci lokasyon planı
Bulut senaryosu
- •Çoklu bölge (region) veya ayrı hesap yaklaşımı
- •Depolama sınıfları ve maliyet/erişim dengesi
- •IAM ve erişim güvenliği (yedekler de korunmalı)
Offsite sadece “kopya” değil, “erişilebilir kopya”
Offsite kopya var ama erişim yoksa (yetki yok, şifre yok, prosedür yok) yine işe yaramaz. Bu nedenle erişim politikası ve runbook DR’nin parçasıdır. Ayrıca KVKK açısından yedeklerin saklama/erişim yönetimi önemlidir: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
☑ Mini Check : Offsite doğrulama
- •Offsite lokasyon fiziksel/hesap olarak ayrık mı?
- •Erişim politikası ve yetkiler net mi?
- •Offsite restore testi yapıldı mı?
- •Yedekler şifreli ve yetki kontrollü mü?
- •Saklama süresi ve KVKK politikası tanımlı mı?
Ne yapmalıyım?
- • Offsite’ı “ayrık” yap (lokasyon/hesap).
- • Erişim ve şifre yönetimini runbook’a yaz.
- • Offsite restore testini tatbik et; sadece kopya yetmez.
- • KVKK saklama ve erişimi DR planına entegre et.
5. DR Planı ve Tatbikatları
DR planı, kağıt üzerinde değil; tatbikatla yaşayan bir süreçtir. Tatbikatlar, en çok “insan ve süreç” zayıflıklarını ortaya çıkarır: kim karar veriyor, hangi sırayla geri dönüyoruz, neyi önce açıyoruz?
Failover ve geri dönme (rollback) testleri
- •Failover: DR ortamına geçiş (kurtarma)
- •Rollback: ana ortama güvenli dönüş
- •Her ikisi de test edilmelidir; çünkü kriz sonrası “geri dönüş” en az “geçiş” kadar risklidir.
Tatbikat türleri (pratik)
- •Tabletop (masa başı): senaryoyu konuşarak yürütme
- •Partial (kısmi): belirli bileşenleri test etme (DB restore, web restore)
- •Full (tam): DR ortamını gerçekten ayağa kaldırma
☑ Mini Check : Tatbikat standardı
- •Tatbikat takvimi var (aylık/çeyreklik)
- •Runbook güncel ve erişilebilir
- •Failover + rollback adımları test edildi
- •RPO/RTO ölçüldü ve raporlandı
- •Tatbikat sonrası aksiyon listesi kapatıldı
Ne yapmalıyım?
- • Tatbikat takvimi koy; “test edilmediyse yok say.”
- • Failover kadar rollback’i de test et.
- • RPO/RTO’yu ölç ve yönetimle paylaş (rapor).
- • Planı bakım-destek ve web geliştirme süreçleriyle birlikte ele al: https://dgtlface.com/tr/yazilim/bakim-ve-destek — https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
6. Otel ve B2B İçin Örnek FELAKET Senaryoları
DR planı senaryosuz olmaz. Senaryolar, önceliklendirmeyi ve test kapsamını belirler.
Otel senaryosu — rezervasyon sisteminin çökmesi
- •Etki: rezervasyon akışı durur, çağrı merkezi yükü artar, gelir kaybı
- •Öncelik: rezervasyon/ödeme/availability uçları önce
- •Hedef: düşük RTO, yönetilebilir RPO
- •Aksiyon: DR ortamına geçiş + minimum işlev setiyle hizmeti sürdürme
B2B senaryosu — portal/CRM kesintisi
- •Etki: müşteri hizmetleri ve satış süreçleri aksar
- •Öncelik: login, kritik kayıt akışları, entegrasyonlar
- •Hedef: iş saatleri SLA’sına uygun RTO
- •Aksiyon: kısmi restore veya failover + entegrasyon kuyruğu yönetimi
Fark yaratan mini bölüm (Competitor Gap): “Yedek alın” seviyesini aşan 4 teslimat
Rakip içerikler çoğu zaman “yedek alın” der; gerçek DR için şu teslimatlar gerekir:
- RPO/RTO hedef dokümanı (tier bazlı)
- Offsite/topoloji ve erişim politikası
- Restore/failover/rollback tatbikat raporları
- Runbook + eskalasyon + iletişim planı
☑ Mini Check : Felaket senaryosu hazırlığı
- •Senaryo bazlı öncelik listesi var (hangi servis önce?)
- •Minimum işlev seti tanımlı (MVP servis listesi)
- •İletişim planı ve sorumlular net
- •Tatbikat raporu ve iyileştirme backlog’u var
- •KVKK ve veri güvenliği kapsamı gözden geçirildi
Ne yapmalıyım?
- • 2 senaryoyu zorunlu test yap: rezervasyon çöküşü + portal kesintisi.
- • Minimum işlev setini belirle; her şeyi aynı anda kurtarmaya çalışma.
- • RPO/RTO’yu ölç; hedefle karşılaştır ve revize et.
- • DR’ı “süreç” olarak sahiplen: bakım-destek + release yönetimiyle bağla.
7. İçerik İçi Tablo: RPO/RTO Hedefleri ve Yedek Türleri Özeti
| Sistem/Tier | RPO hedefi | RTO hedefi | Yedek türü kombinasyonu | Restore/Test sıklığı |
|---|---|---|---|---|
| Tier-1 (Rezervasyon/Portal) | Dakika–saat bandı | Saat bandı | Snapshot + sık yedek + offsite | Aylık/çeyreklik |
| Tier-2 (Entegrasyon/Backoffice) | Saat bandı | Saat–gün bandı | Full + incremental + offsite | Çeyreklik |
| Tier-3 (İçerik/Statik) | Gün bandı | Gün bandı | Full + offsite | 6 ayda bir |
8. Felaket Kurtarma Planı & Yedekleme Checklist Şablonunu İndir
Checklist + Sprint Plan İçeriği
Felaket Kurtarma Planı & Yedekleme Checklist Şablonunu İndir — Yazılım / Sunucu ve Güvenlik (v1.0)
Bu asset, DR’ı “yedek var” seviyesinden çıkarıp RPO/RTO hedefleriyle ölçülen, offsite’la ayrıştırılmış ve tatbikatla doğrulanmış bir modele dönüştürür. Tier bazlı önceliklendirme yaparak kritik sistemlerde hızlı geri dönüş sağlar. Restore/failover/rollback testlerini 14 günlük sprint planına bağlar.
Kim Kullanır?
BT/DevOps, sistem yöneticisi, otel operasyonu (kritik sistem sahibi) ve B2B portal/CRM ekipleri.
Nasıl Kullanılır?
- Tier-1/2/3 sistemleri çıkarıp RPO/RTO hedeflerini yaz.
- Yedek türlerini ve offsite topolojisini seç; erişim politikasını ekle.
- Restore/failover/rollback testlerini planla, sprintte uygula ve raporla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Tier sınıflandırma (rezervasyon/portal = Tier-1) yapıldı
- ▢ ✅ Tier bazlı RPO/RTO hedefi onaylandı
- ▢ ✅ DB + dosya + config kapsamı net
- ▢ ✅ Full/incremental/snapshot kombinasyonu seçildi
- ▢ ✅ Offsite (ayrık lokasyon/hesap) kuruldu
- ▢ ✅ Erişim/şifre/yetki politikası yazıldı
- ▢ ✅ Restore testi takvime bağlandı
- ▢ ✅ Failover + rollback adımları runbook’ta
- ▢ ✅ Tatbikat raporu ve iyileştirme backlog’u var
- ▢ ✅ KVKK saklama/erişim kontrolü eklendi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables listesi
- •Tier bazlı RPO/RTO dokümanı
- •Offsite topoloji + erişim politikası
- •Runbook (failover + rollback)
- •Tatbikat raporu + backlog
Bir Sonraki Adım
RPO/RTO hedeflerini netleştirip, offsite yedek ve tatbikatlarla gerçek kesintide hızlı dönüş planı kurmak isteyen otel ve B2B ekipleri için.