Felaket kurtarma planı (Disaster Recovery / DR), bir yangın, sel, donanım arızası, fidye yazılımı saldırısı veya elektrik kesintisi gibi olağandışı bir olay sonrası BT sistemlerinizi ve verilerinizi belirlenmiş bir süre içinde yeniden çalışır hale getirmek için önceden hazırlanmış, yazılı ve test edilmiş bir prosedürler bütünüdür. İyi bir DR planı iki temel soruya net cevap verir: “Sistemleri ne kadar sürede ayağa kaldırabiliriz?” ve “En fazla ne kadarlık veriyi kaybetmeyi göze alıyoruz?” Bu yazıda, Gaziantep ve çevresindeki kurumsal işletmeler için adım adım uygulanabilir bir DR planının nasıl hazırlanacağını anlatıyoruz.
Felaket kurtarma planı ile iş sürekliliği planı aynı şey mi?
Hayır, ancak iç içe geçmişlerdir. İş sürekliliği planı (BCP), bir kriz anında şirketin tüm operasyonlarının (insan kaynağı, lojistik, iletişim, müşteri hizmetleri) nasıl devam edeceğini kapsayan üst çerçevedir. Felaket kurtarma planı (DRP) ise BCP’nin BT ve veri ayağını oluşturan teknik alt kümesidir; sunucular, uygulamalar, ağ ve verilerin geri yüklenmesine odaklanır.
Pratikte küçük ve orta ölçekli işletmelerin çoğu için DR planı, iş sürekliliğinin en kritik parçasıdır. Çünkü ERP sisteminiz, e-fatura altyapınız, muhasebe verileriniz veya saha satış uygulamanız çalışmadığında işletme fiilen durur. Bu nedenle DR planını “BT olmazsa olmazı” olarak ele almak gerekir.
RTO ve RPO nedir, nasıl belirlenir?
DR planının temelini iki metrik oluşturur ve bunları yanlış belirlemek tüm planı geçersiz kılar:
- RTO (Recovery Time Objective / Kurtarma Süresi Hedefi): Bir kesinti sonrası sistemin yeniden çalışır hale gelmesi için kabul edilebilir maksimum süredir. Örneğin RTO 4 saat ise, felaketten sonra en geç 4 saat içinde sistemler ayakta olmalıdır.
- RPO (Recovery Point Objective / Kurtarma Noktası Hedefi): Kabul edilebilir maksimum veri kaybı miktarıdır, zaman cinsinden ifade edilir. RPO 1 saat ise, en fazla son 1 saatlik verinin kaybını göze alıyorsunuz demektir. Bu da yedeklerinizi en az saatte bir almanızı gerektirir.
RTO ve RPO’yu belirlerken her sistemi tek tek değerlendirin. Tüm sistemlere aynı hedefi koymak hem aşırı maliyet hem de eksik koruma yaratır. Aşağıdaki gibi bir önceliklendirme tablosu işinizi kolaylaştırır:
| Sistem | Kritiklik | RTO hedefi | RPO hedefi |
|---|---|---|---|
| ERP / muhasebe veritabanı | Çok yüksek | 2-4 saat | 15-60 dakika |
| E-fatura / e-dönüşüm altyapısı | Yüksek | 4 saat | 1 saat |
| Saha satış / sipariş uygulaması | Yüksek | 4-8 saat | 1 saat |
| Dosya sunucusu / paylaşımlar | Orta | 8-24 saat | 4-24 saat |
| İç wiki, arşiv, eski projeler | Düşük | 1-3 gün | 24 saat |
Bu değerler örnektir; gerçek hedefleriniz iş hacminize, sektörel yükümlülüklerinize ve kesintinin saatlik maliyetine göre değişir. Bir saatlik duruşun size kaç TL’ye mal olduğunu hesaplamak, RTO/RPO yatırımının ne kadar mantıklı olduğunu gösterir.
Hangi felaket senaryolarına hazırlanmalıyız?
DR planı tek bir olaya değil, olası senaryo ailelerine göre kurgulanmalıdır. En sık karşılaşılan senaryolar şunlardır:
- Donanım arızası: Sunucu disk arızası, RAID çökmesi, anakart/güç kaynağı arızası. En sık yaşanan ve en kolay öngörülebilir senaryodur.
- Fidye yazılımı (ransomware) ve siber saldırı: Veriler şifrelenir ya da çalınır. Bu senaryoda yedeklerin de şifrelenmemiş olması, yani çevrimdışı (air-gapped) veya değiştirilemez (immutable) yedek bulundurmak hayati önemdedir.
- İnsan hatası: Yanlışlıkla silme, hatalı güncelleme, yanlış komut. İstatistiksel olarak veri kayıplarının büyük kısmı buradan gelir.
- Fiziksel felaket: Yangın, sel, deprem, elektrik dalgalanması. Bu senaryo, yedeklerin neden farklı bir fiziksel lokasyonda tutulması gerektiğini açıklar.
- Hizmet sağlayıcı kesintisi: İnternet servis sağlayıcısı, veri merkezi veya bulut sağlayıcısının kesintiye uğraması.
Her senaryo için “kim, neyi, hangi sırayla yapacak” sorusunun cevabını yazıya dökün. Kriz anında doğaçlama yapmak en pahalı hatadır.
Yedek site (DR site) nasıl kurulur?
Yedek site, ana sistemleriniz çöktüğünde devreye girecek alternatif altyapıdır. Maliyet ve hız dengesine göre üç temel model vardır:
- Soğuk site (cold site): Yalnızca yedeklerin saklandığı, donanımın kurulu olmadığı ortam. En ucuzdur ama RTO uzundur (günler).
- Ilık site (warm site): Donanımın hazır ama verinin periyodik kopyalandığı ortam. Orta maliyet, saatler düzeyinde RTO.
- Sıcak site (hot site): Verinin sürekli senkronize edildiği, neredeyse anında devralabilen ortam. En pahalı, en düşük RTO/RPO.
Günümüzde KOBİ’ler için en pratik çözüm hibrit yaklaşımdır: Kritik veritabanlarını bulut tabanlı yedekleme veya çoğaltma (replication) ile uzak bir lokasyona aktarmak, ikincil bir fiziksel sunucuyu yedek olarak hazır tutmak. Bu modelde 3-2-1 yedekleme kuralı altın standarttır: en az 3 kopya, 2 farklı ortam (örn. disk + bulut), 1 kopya tamamen farklı bir lokasyonda (çevrimdışı/off-site).
DR planını nasıl test ederiz? (Tatbikat)
Test edilmemiş bir DR planı, plan değil temennidir. Yedeklerinizin gerçekten geri yüklenebildiğini ancak deneyerek bilirsiniz. Tatbikat türleri:
- Masabaşı tatbikatı (tabletop): Ekip bir senaryoyu sözlü olarak adım adım canlandırır. Eksik rol ve belirsizlikleri ortaya çıkarır.
- Kısmi geri yükleme testi: Belirli bir veritabanı veya sunucu yedekten izole bir ortama geri yüklenir, bütünlüğü doğrulanır.
- Tam devralma tatbikatı (failover): Üretim yükü gerçekten yedek siteye aktarılır ve sistemin tam çalıştığı doğrulanır. En değerli ama en hazırlık gerektiren testtir.
Tatbikatları en az yılda bir, kritik altyapısı sık değişen kurumlarda ise altı ayda bir yapmanızı öneririz. Her tatbikat sonrası ölçülen gerçek kurtarma süresini hedef RTO ile karşılaştırın ve farkı kapatacak iyileştirmeleri plana yazın.
DR planı kontrol listesi
Aşağıdaki listeyi tamamladıysanız, savunulabilir bir DR pozisyonundasınız:
- Tüm kritik sistemler envantere alındı ve önceliklendirildi
- Her sistem için RTO ve RPO hedefleri yazılı olarak belirlendi
- 3-2-1 yedekleme kuralı uygulanıyor (off-site + immutable kopya dahil)
- Fidye yazılımına karşı çevrimdışı/değiştirilemez yedek mevcut
- Yedek site (cold/warm/hot) modeli belirlendi ve kuruldu
- Felaket anı için rol/sorumluluk ve iletişim listesi hazır
- Geri yükleme adımları belge halinde, erişilebilir bir yerde saklanıyor
- En az yılda bir tatbikat yapılıyor ve sonuçlar kayıt altında
- Plan, altyapı değiştikçe güncelleniyor
KVKK kapsamında kişisel veri işleyen kurumların, verilerin güvenliğini ve sürekliliğini sağlamaya yönelik teknik tedbirler alması beklenir; sektörünüze özel saklama ve sürekliliğe ilişkin yükümlülükler için her zaman güncel resmi kaynağı (KVKK ve ilgili düzenleyici kurum mevzuatı) kontrol edin.
Sıkça Sorulan Sorular
RTO ve RPO arasındaki fark tam olarak nedir? RTO sistemin yeniden çalışır hale gelmesi için kabul edilebilir süreyi (zaman kaybı), RPO ise kabul edilebilir maksimum veri kaybı miktarını (verinin tazeliği) ifade eder. Biri “ne kadar sürede ayağa kalkarız”, diğeri “en fazla ne kadar veri kaybederiz” sorusuna cevap verir.
Sadece düzenli yedek almak felaket kurtarma için yeterli mi? Hayır. Yedekleme DR’nin yalnızca bir parçasıdır. Yedeğin nereye, ne sıklıkla alındığı, geri yüklemenin ne kadar sürdüğü, yedeklerin test edilip edilmediği ve fidye yazılımına karşı korunup korunmadığı da en az yedeğin kendisi kadar önemlidir.
Küçük bir işletme için felaket kurtarma planı pahalı değil mi? Plan oluşturmanın kendisi çoğunlukla zaman maliyetidir; teknolojik yatırım ise kritiklik düzeyine göre ölçeklenir. Bulut tabanlı yedekleme ve hibrit modeller sayesinde KOBİ’ler bugün makul bütçelerle ciddi koruma sağlayabilir. Bir saatlik duruşun maliyetini hesaplayınca yatırımın geri dönüşü genelde nettir.
Fidye yazılımına karşı en kritik DR önlemi nedir? Çevrimdışı (air-gapped) veya değiştirilemez (immutable) yedek bulundurmaktır. Saldırgan ağa bağlı yedeklere de ulaşıp şifreleyebileceği için, ağdan izole en az bir temiz kopya kurtarmanın güvencesidir.
DR planını ne sıklıkla güncellemeliyim? Plan canlı bir belgedir. En az yılda bir gözden geçirin; sunucu, uygulama, personel veya lokasyon değişikliği olduğunda ise hemen güncelleyin. Her tatbikat sonucunu da plana yansıtın.
İşletmenizin verileri ve sistemleri için savunulabilir bir felaket kurtarma planı kurmak istiyorsanız, Giza Teknoloji olarak Gaziantep/Şehitkamil’den tüm Türkiye’ye destek veriyoruz. Yedekleme mimarisi, Server ve Güvenlik (Fortinet) çözümlerimiz, donanım ve bakım hizmetlerimiz ve proje yönetimi / iş zekası ekosistemimizle DR planınızı uçtan uca kurgulayabiliriz. Ayrıca Netsis 3 ERP, e-dönüşüm ve Xenon saha satış sistemlerinizin sürekliliğini de aynı çerçevede güvenceye alıyoruz.
İhtiyacınıza özel bir değerlendirme için WhatsApp hattımızdan 0532 599 51 12 ile yazın, 0532 599 51 12 numaralı destek hattımızı arayın veya iletişim sayfamız üzerinden bize ulaşın. Firmamız ve çözümlerimiz hakkında daha fazla bilgi için hakkımızda sayfamızı ziyaret edebilirsiniz.