Felaket Kurtarma Planı Nasıl Hazırlanır? RTO, RPO ve Adım Adım DR Rehberi

Bir felaket kurtarma planı (Disaster Recovery, DR), sistemleriniz durduğunda neyi, hangi sırayla, ne kadar sürede ve ne kadar veri kaybını kabul ederek geri getireceğinizi önceden yazılı hâle getirir. Uptime Institute'un 2026 kesinti analizine göre katılımcıların yüzde 57'si son büyük kesintilerinin 100 bin doları aştığını, her beş katılımcıdan biri ise 1 milyon doları geçtiğini söylüyor. 12 Kasım'daki küresel Microsoft 365 kesintisi de bir kez daha gösterdi: kesinti "olursa" değil, "olduğunda" sorusudur. Bu rehberde RTO ve RPO kavramlarını, doğru DR modelini seçmeyi ve planınızı gerçekten çalışır hâle getirmeyi bir veri merkezi işletmecisinin gözünden anlatıyoruz.

Felaket Kurtarma Planı Neden Artık Ertelenemez?

Uptime Institute'un 13 Mayıs 2026'da yayımladığı yıllık kesinti analizi, kesinti sıklığının site başına düşmeye devam ettiğini ama iyileşmenin yavaşladığını gösteriyor. Rapora göre etkili kesintilerin önde gelen nedeni hâlâ güç altyapısı; UPS, transfer anahtarı ve jeneratör arızaları başı çekiyor. İnsan kaynaklı kesintilerde ise en büyük etken, belirlenmiş prosedürlere uyulmaması. Fiber ve bağlantı sorunlarından kaynaklanan kesintilerin arttığı ve daha uzun sürmeye yatkın olduğu da raporun dikkat çeken bulguları arasında.

Kesinti her zaman sizin altyapınızda başlamıyor. Microsoft 365 kesintisi yazımızda anlattığımız gibi, kullandığınız bir SaaS hizmeti saatlerce erişilemez olabilir. Fidye yazılımı, yanlış bir yapılandırma değişikliği, silinen bir veritabanı ya da bir binada çıkan yangın da aynı soruyu sorar: işinizi ne kadar sürede ayağa kaldırabilirsiniz?

RTO ve RPO Nedir? Felaket Kurtarmanın İki Temel Ölçüsü

RTO (Recovery Time Objective): Ne kadar süre kapalı kalabilirsiniz?

RTO, bir sistemin kesintiden sonra en geç ne kadar sürede yeniden hizmet vermesi gerektiğini tanımlar. Bir e-ticaret sitesinin ödeme sistemi için 15 dakika, bir iç raporlama aracı için 24 saat olabilir. RTO ne kadar kısaysa çözüm o kadar pahalıdır.

RPO (Recovery Point Objective): Ne kadar veri kaybını kabul edebilirsiniz?

RPO, geri döndüğünüzde en fazla ne kadar geriye ait veriyi kaybetmeyi göze aldığınızı gösterir. Günde bir kez yedek alıyorsanız fiilî RPO'nuz 24 saattir; yani en kötü senaryoda bir günlük siparişi, faturayı ya da müşteri kaydını kaybedersiniz. Sürekli replikasyonla bu süre saniyelere iner.

Bu iki değer teknik değil, iş kararıdır. "Ödeme sistemi bir saat kapalı kalırsa kaç TL kaybederiz?" sorusunun cevabını BT ekibi değil, iş birimleri vermelidir.

Felaket Kurtarma Planı Hazırlama: Adım Adım

ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün NIST SP 800-34 acil durum planlama rehberi, iş etkisi analiziyle başlayan, test ve bakımla süren bir döngü önerir. Aşağıdaki adımlar bu yaklaşımı KOBİ'lerden kurumsal şirketlere kadar uygulanabilir hâle getiriyor.

1. Envanter çıkarın. Tüm sunucuları, sanal makineleri, veritabanlarını, SaaS hizmetlerini, DNS ve alan adı kayıtlarını, lisansları ve kritik parolaların nerede saklandığını listeleyin.

2. İş etkisi analizi yapın. Her sistem için kesintinin saatlik maliyetini, yasal yükümlülükleri ve müşteri etkisini belirleyin.

3. Sistemleri kademelendirin. Örneğin Kademe 1 (kritik, dakikalar), Kademe 2 (önemli, saatler), Kademe 3 (destekleyici, günler). Her kademeye bir RTO ve RPO atayın.

4. Bağımlılıkları haritalayın. Uygulamanız ayağa kalksa bile kimlik doğrulama, DNS, lisans sunucusu veya ödeme sağlayıcısı yoksa çalışmaz. Kurtarma sırasını bu haritaya göre yazın.

5. Yedekleme stratejisini kurun. En az 3 kopya, 2 farklı ortam, 1 kopya farklı lokasyonda (3-2-1). Fidye yazılımına karşı en az bir kopyanın değiştirilemez (immutable) veya çevrim dışı olmasını sağlayın.

6. DR modelini seçin. RTO ve RPO hedeflerinize ve bütçenize uyan modeli aşağıdaki tablodan belirleyin.

7. Runbook yazın. Kim kimi arar, hangi komutlar hangi sırayla çalıştırılır, DNS nasıl yönlendirilir, müşteriye ne duyurulur? Adımları, planı hiç görmemiş bir ekip üyesinin uygulayabileceği netlikte yazın.

8. İletişim planı hazırlayın. Kurumsal e-posta da çökmüş olabilir. Alternatif iletişim kanalını, yetkili listesini ve müşteri duyuru şablonlarını önceden belirleyin.

9. Test edin ve güncelleyin. Test edilmemiş plan, plan değildir. En az yılda bir tam geri dönüş testi, her çeyrekte yedekten geri yükleme testi yapın.

Hangi DR Modeli Size Uygun? Karşılaştırma Tablosu

Aşağıdaki RTO ve RPO aralıkları sektörde yaygın kullanılan tipik değerlerdir; gerçek değerler mimarinize, veri büyüklüğünüze ve ağ bağlantınıza göre değişir.

Tüm sistemleri aktif-aktif kurmak çoğu şirket için gereksiz derecede pahalıdır. Doğru yaklaşım, Kademe 1 sistemlere warm standby veya aktif-aktif, geri kalanına yedekten geri yükleme modelini uygulamaktır.

DR Planlarında En Sık Gördüğümüz Hatalar

• Yedeklerin aynı binada durması: Yangın, su baskını veya fidye yazılımı ana sistemle birlikte yedeği de götürür.

• Geri yüklemenin hiç denenmemesi: Yedek almak ile yedekten dönebilmek aynı şey değildir. Bozuk ya da eksik yedek, ancak ihtiyaç anında fark edilir.

• Yedekleme sisteminin ana sistemle aynı kimlik bilgilerini kullanması: Etki alanı yöneticisini ele geçiren saldırgan yedekleri de silebilir. Fidye yazılımına karşı yedekleme stratejisi yazımızda bu konuyu ayrıntılı anlattık.

• DNS TTL değerlerinin yüksek kalması: İkinci lokasyona yönlendirme yaptığınızda kullanıcılar saatlerce eski adrese gitmeye devam edebilir.

• SaaS bağımlılıklarının plana alınmaması: E-posta, CRM ve iş birliği araçları çöktüğünde ne yapılacağı yazılmamış olur.

• Planın tek bir kişinin kafasında olması: O kişi tatildeyse plan da tatildedir.

Sık Sorulan Sorular

Felaket kurtarma planı ile iş sürekliliği planı arasındaki fark nedir?

İş sürekliliği planı, kesinti sırasında şirketin tüm işlevlerini (personel, tedarik, iletişim, müşteri hizmetleri) sürdürmeyi kapsar. Felaket kurtarma planı ise bunun BT ayağıdır: sistemlerin, verilerin ve altyapının geri getirilmesine odaklanır.

RTO ve RPO değerlerini nasıl belirlerim?

Her sistem için kesintinin saatlik maliyetini ve kaybedilen bir saatlik verinin iş etkisini hesaplayın. Ardından bu kaybı önleyecek çözümün maliyetiyle karşılaştırın. Çözümün maliyeti, önlediği kayıptan fazlaysa hedefinizi gevşetebilirsiniz.

Felaket kurtarma testi ne sıklıkla yapılmalı?

Kritik sistemler için yılda en az bir kez uçtan uca geri dönüş testi önerilir. Yedekten geri yükleme testlerini ise her çeyrekte, büyük altyapı değişikliklerinden sonra da mutlaka tekrarlayın.

Felaket kurtarma merkezi ana sistemden ne kadar uzakta olmalı?

İkinci lokasyon, aynı yerel riske (aynı bina, aynı elektrik trafosu, aynı sel bölgesi) maruz kalmayacak kadar uzakta olmalıdır. Öte yandan senkron replikasyon için gecikmenin düşük kalması gerekir. Bu dengeyi iş yükünüze göre kurun.

Olfe ile Felaket Kurtarma Altyapısı

Olfe'nin İzmir Bornova'daki Tier III veri merkezi; çift hat besleme, UPS, jeneratör, biyometrik erişim ve sözleşmeyle garanti altındaki %99.99 uptime ile ikincil lokasyon veya ana barındırma noktası olarak kullanılabilir. Kendi sunucularınız için kabin barındırma, felaket kurtarma ortamı için bulut sunucu ya da fiziksel sunucu, izleme, yama ve yedeklemeyi bizim üstlendiğimiz yönetilen hizmetler seçeneklerimiz var. 10 Gbps'e kadar bağlantı, büyük yedeklerin aktarımını hızlandırır; 7/24 destek ekibimiz acil arızalarda 15 dakika içinde dönüş yapar. DR mimarinizi birlikte planlamak için bize ulaşın.

Sonuç

Felaket kurtarma planı bir doküman değil, düzenli olarak test edilen bir alışkanlıktır. RTO ve RPO hedeflerinizi iş birimleriyle birlikte belirleyin, yedeklerinizi ana sistemden ayırın ve geri dönüşü en az yılda bir kez gerçekten deneyin. Kesinti geldiğinde planınızı ilk kez okuyor olmayın.