Felaket Kurtarma Planı Nasıl Hazırlanır? KOBİ İçin RTO/RPO Rehberi

Yedekleriniz var. Sunucu çökse ya da fidye yazılımı sistemi kilitlese, işi kaç saatte tekrar ayağa kaldırırsınız? Bu soruya net bir sayı veremiyorsanız bir yedeğiniz var ama bir planınız yok — ve ikisi aynı şey değil.

Yedek, verinin kopyasıdır. Felaket kurtarma planı (DRP) ise o kopyayı kullanarak işin kaç saatte, hangi sırayla ve kimin sorumluluğunda yeniden çalışır hale geleceğini yazan belgedir. Sahada gördüğüm en uzun kesintiler yedeği olmayan firmalarda değil; yedeği olup da onu kriz anında ilk kez geri yüklemeye çalışan firmalarda yaşanıyor. Geri yükleme 6 saat sürüyor, kimse hangi sunucunun önce gelmesi gerektiğini bilmiyor, son sağlam yedeğin nerede olduğu tartışılıyor. Bu kaos, planın yokluğundan doğuyor.

Her şey iki sayıyla başlar: RTO ve RPO

Bir plan yapmadan önce iki hedefi netleştirmeniz gerekir.

RTO (Recovery Time Objective) — bir sistem durduktan sonra en geç kaç saat içinde tekrar çalışır olması gerektiği. “Muhasebe sunucusu en fazla 4 saat durabilir” demek, RTO’yu 4 saate koymak demektir.

RPO (Recovery Point Objective) — kabul edebileceğiniz en fazla veri kaybı. Yedeği günde bir kez, gece alıyorsanız RPO’nuz 24 saattir: çökme anıyla bir önceki gece arasındaki her şeyi kaybedebilirsiniz. E-ticaret siparişlerinde bu 24 saat kabul edilemezken, aylık raporlanan bir arşiv için sorun olmayabilir.

Bu iki sayıyı her kritik sistem için ayrı belirlemeden plan kurulmaz. ERP’nin RTO’su ile şirket içi wiki’nin RTO’su aynı olamaz; ikisini eşitlerseniz ya gereksiz para harcarsınız ya da gerçekten önemli olanı yeterince hızlı koruyamazsınız.

Sistem	Örnek RTO	Örnek RPO	Notu
ERP / muhasebe	2-4 saat	1 saat	İş durursa tahsilat ve üretim durur
E-posta	4 saat	1 saat	Müşteri iletişimi kritik
Dosya sunucusu	8 saat	24 saat	Çoğu KOBİ için tolere edilebilir
Pazarlama / blog	48 saat	24 saat	Gelir akışını doğrudan durdurmaz

Bu tablo bir şablon değil, bir başlangıç noktası. Sizin RTO/RPO’larınızı sektörünüz ve müşteri beklentiniz belirler.

İş etki analizi: neyi önce kurtaracaksınız?

RTO/RPO’yu havadan atamazsınız. Bunun arkasında iş etki analizi (BIA) durur: hangi süreç durduğunda işin ne kadar para ve itibar kaybettiğini sistem sistem çıkarmak. ISO 22301 iş sürekliliği standardının kalbinde de bu analiz vardır — kuruluş, her kritik süreç için RTO’yu bu analizin sonucuna göre belirler.

KOBİ ölçeğinde BIA’yı abartmaya gerek yok. Yarım günlük bir çalıştayla şu üç soruyu yanıtlayın:

• Hangi sistem durursa bugün para kaybetmeye başlarız?
• O sistem olmadan kaç saat idare edebiliriz?
• O sistemi geri getirmek başka neye bağlı (önce veritabanı mı, önce ağ mı)?

Bu üç sorunun cevabı, kurtarma sırasını verir. Kriz anında “önce neyi açalım” tartışması yapmak yerine, listeyi açıp sırayla uygularsınız.

Plan kâğıtta kalmazsa işe yarar: tatbikat şart

Yazılmış ama hiç denenmemiş bir plan, plan değil iyi niyettir. Gördüğüm en sık hata bu: klasörde duran 30 sayfalık bir DRP, ama son geri yükleme testinin üzerinden bir yıl geçmiş.

En az yılda bir kez gerçek bir geri yükleme tatbikatı yapın. Tek bir kritik sunucuyu izole bir ortama geri yükleyip “açılıyor mu, veri tutarlı mı, kaç dakika sürdü” diye ölçün. Ölçtüğünüz süre genelde hedeflediğiniz RTO’dan uzun çıkar — iyi ki tatbikatta öğrendiniz, krizde değil.

Tatbikatta üç şeyi not edin: gerçekleşen kurtarma süresi, eksik kalan adımlar ve plandaki yanlış/eski bilgiler (değişmiş IP, ayrılmış personel, kapanmış servis). Sonra planı güncelleyin. Felaket kurtarma planı yaşayan bir belgedir; altyapı değiştikçe değişir.

Planın içinde mutlaka olması gerekenler

• İletişim zinciri — kim kimi arar, telefon numaraları planın içinde (e-postaya erişemeyebilirsiniz)
• Sistem öncelik listesi — BIA’dan çıkan, RTO sırasına göre dizili
• Geri yükleme adımları — her kritik sistem için, ekran görüntüsü düzeyinde somut
• Yedeklerin yeri ve erişimi — hangi yedek nerede, parolası kimde, en az bir kopya çevrimdışı/değişmez
• Tedarikçi ve destek numaraları — internet sağlayıcı, donanım, BT iş ortağı

Sık sorulanlar

Yedeğim bulutta, ayrıca DR planına gerek var mı? Evet. Bulut yedek, RPO’nuzu iyileştirir ama “kim, ne sırayla, kaç saatte geri yükler” sorusunu cevaplamaz. Plan o boşluğu doldurur.

KOBİ için RTO ne kadar olmalı? Tek bir doğru sayı yok. Kritik sistemlerde çoğu KOBİ 2-8 saat aralığında çalışır. Önemli olan sayıyı keyfi seçmek değil, BIA’ya dayandırmak ve altyapınızın o süreyi gerçekten tutabildiğini tatbikatla doğrulamak.

Plan ne sıklıkla güncellenmeli? Yılda en az bir tatbikat sonrası, ayrıca büyük altyapı değişikliklerinde (yeni sunucu, taşınma, ERP geçişi).

Felaket kurtarma planı, satın aldığınız bir ürün değil; işinizi tanıyan birinin sizinle birlikte çıkardığı bir disiplin. Yedekleme, RTO/RPO belirleme ve düzenli tatbikat kurgusunu işletmenize göre kurmak için bizimle iletişime geçin.

---

Kaynaklar

• TSE — TS EN ISO 22301 İş Sürekliliği Yönetim Sistemi: tse.org.tr
• ISO 22301 İş Sürekliliği ve BIA — KPMG Akademi: kpmgakademi.com