Felaket kurtarma planı nasıl hazırlanır? Örnekle adım adım
Felaket kurtarma planı; bir sistem çöktüğünde hangi uygulamanın hangi sırayla, kimin tarafından, ne kadar sürede ve hangi yedekten geri getirileceğini yazan belgedir. Literatürde DRP (Disaster Recovery Plan, felaket kurtarma planı) denir ve daha geniş olan BCP’nin (Business Continuity Plan, iş sürekliliği planı) BT ayağıdır.
Felaket kurtarma planı nedir? İş sürekliliği planından farkı
Arkadaşlar, “felaket” kelimesi deprem, yangın, sel gibi geliyor ama sahada en sık gördüğümüz felaketler çok daha sıradan: fidye yazılımı, sunucu diskinin bozulması, yanlışlıkla silinen bir veritabanı, binanın elektriğinin iki gün gitmesi. Hepsinde soru aynı: Yarın sabah faturayı kesebilecek miyiz, üretim planını görebilecek miyiz?
İş sürekliliği planı (BCP) işin kendisini kapsar: hangi süreç ne kadar durabilir, insanlar nerede çalışacak, müşteriye ne söylenecek, tedarikçi nasıl aranacak. Felaket kurtarma planı (DRP) bunun BT tarafıdır: sunucu, veri, uygulama, ağ. Önce BCP’deki iş önceliklerini, sonra DRP’deki teknik adımları yazmak doğru sıradır. İş sürekliliği yönetimi için uluslararası standart ISO 22301’dir; KOBİ’nin sertifika alması gerekmez ama mantığını kullanmak işe yarar.
RTO ve RPO nedir? Felaket kurtarma planının öncelikli hedefi
Planın kalbinde iki sayı var ve bu sayıları BT değil, yönetim vermeli:
- RTO (Recovery Time Objective, kurtarma süresi hedefi): Sistem çöktükten sonra en geç kaç saatte yeniden çalışır olmalı?
- RPO (Recovery Point Objective, kurtarma noktası hedefi): En fazla kaç saatlik veri kaybını kabul edebiliriz? Yani son yedek en fazla ne kadar eski olabilir?
RTO ve RPO nasıl belirlenir? Örnek verelim
Örnek verelim: ERP sistemi durduğunda 40 kişilik ofis ve sevkiyat ekibi işini yapamıyor. Sistem 8 saat dönmezse 40 × 8 = 320 kişi-saatlik emek boşa gidiyor; üstüne o gün sevk edilemeyen siparişler var. Yönetim burada “ERP en geç 4 saatte dönmeli” derse RTO 4 saattir.
Aynı ERP’de günde ortalama 120 sipariş satırı giriliyor ve mesai 10 saat sürüyor; saatte 12 satır eder. Yedek sadece gece alınıyorsa öğleden sonra yaşanan bir çökmede 8–9 saatlik, yaklaşık 100 satırlık kayıt elle yeniden girilecek. Yönetim “en fazla 1 saatlik kayıp kabul ederiz” derse RPO 1 saattir ve gece yedeği yetmez; saatlik yedek ya da sürekli kopyalama gerekir.
Burada önemli olan şu: RTO ve RPO küçüldükçe çözüm pahalılaşır. Her sisteme “sıfır kayıp, sıfır süre” demek yerine sistemleri öneme göre sınıflandırmak gerekir.
Felaket kurtarma planı nasıl hazırlanır? Adım adım
Bizim sahada izlediğimiz sıra şu:
- 1. Sistem envanterini çıkarın: sunucular, uygulamalar, veritabanları, bulut hizmetleri, ağ cihazları, lisanslar.
- 2. İş etki analizi yapın (BIA, Business Impact Analysis): Her sistem durduğunda hangi süreç duruyor, ilk saatte, ilk günde ne kaybediliyor?
- 3. Her sistem için RTO ve RPO’yu yönetimle birlikte yazın.
- 4. Bağımlılıkları sıralayın: ERP çalışmadan önce ağ, alan adı sunucusu ve veritabanı ayakta olmalı. Geri getirme sırası buradan çıkar.
- 5. Yedek ve kurtarma yöntemini RPO’ya göre seçin; en az bir kopya ayrı yerde ve değiştirilemez olsun.
- 6. Roller ve iletişim listesini yazın: planı kim devreye alır, kim kimi arar, dış firmaların ve tedarikçilerin numaraları.
- 7. Her sistem için adım adım geri yükleme talimatı hazırlayın; şifrelerin nerede saklandığı dahil.
- 8. Planı kâğıda da basın; sunucu çöktüğünde planın kendisi de o sunucuda olabilir.
- 9. Yılda en az bir kez test edin ve testten sonra planı güncelleyin.
Felaket kurtarma planı örneği: hangi başlıklar olmalı?
Aşağıdaki iskelet bir KOBİ için yeterli. Her sistem için tek satırlık bir tablo bile işin büyük kısmını çözer:
- Amaç, kapsam ve planın son güncellenme tarihi
- Planı devreye alma yetkisi olan kişi ve yedeği
- Olay sınıfları: tek bilgisayar, tek sunucu, tüm bina, fidye yazılımı
- Sistem tablosu: sistem adı, sorumlu, RTO, RPO, yedek yeri, geri getirme sırası
- İletişim listesi: iç ekip, dış BT firması, internet servis sağlayıcı, yazılım tedarikçileri
- Geri yükleme talimatları ve gerekli şifrelerin güvenli saklama yeri
- Geçici çalışma düzeni: sistem dönene kadar sipariş, sevkiyat, üretim nasıl yürüyecek
- Test kayıtları: tarih, senaryo, ölçülen süre, çıkan eksikler
İş sürekliliği planı ne zaman ve kimin kararıyla devreye girer?
Plan, olay tanımlandığında değil, önceden yazılmış eşik aşıldığında devreye girer. Örneğin “ERP 1 saattir erişilemiyor ve sebebi bilinmiyor” ya da “fidye yazılımı şüphesi var” gibi açık eşikler yazın. Kararı kimin vereceği planda isim ve yedek isimle belli olmalı; gece yarısı herkesin birbirine bakması en çok zaman kaybettiren şey.
Fidye yazılımı durumunda dikkat: Geri yüklemeye başlamadan önce saldırganın giriş noktası kapatılmalı. Bu ayrımı fidye yazılımı rehberimizde anlattık. Kişisel veri etkilendiyse KVKK bildirim süreleri de işler; güncel düzenlemeyi kontrol edin.
Felaket kurtarma planı nasıl test edilir?
Test edilmemiş plan, iyi niyetli bir belgeden öteye geçmez. Testin amacı planın çalıştığını kanıtlamak değil, eksiklerini bulmaktır. Üç seviyede test yapıyoruz:
- 1. Masa başı tatbikat: Ekip toplanır, “sunucu odası su bastı” senaryosu okunur, herkes ne yapacağını anlatır. Eksik numara, bilinmeyen şifre burada çıkar.
- 2. Kısmi geri yükleme: Bir sistemi test ortamına yedekten geri getirip süreyi ölçeriz. Ölçülen süre RTO’dan uzunsa plan değişmeli.
- 3. Tam tatbikat: Kritik sistemlerin tamamı belirlenen sırayla ayrı ortamda ayağa kaldırılır; genelde yılda bir yapılır.
Plan, insanların gece yarısı yalnız kalmaması içindir
Bir felaket anında en çok yükü BT’den sorumlu bir iki arkadaşımız taşır. Yazılı ve test edilmiş bir plan, o arkadaşların kriz anında hafızasına ve şansına kalmamasını, emeklerinin doğru sırayla doğru işe gitmesini sağlar.
Siz de kendi felaket kurtarma ve iş sürekliliği planınızı hazırlamak ya da mevcut planınızı test etmek isterseniz bizimle iletişime geçebilirsiniz. Sormak istediğiniz her konuda gerekli desteği vermeye hazırız.
Sık sorulan sorular
Felaket kurtarma planı nedir?
Bir sistem çöktüğünde hangi uygulamanın hangi sırayla, kim tarafından, ne kadar sürede ve hangi yedekten geri getirileceğini yazan belgedir. Literatürde DRP (Disaster Recovery Plan) olarak geçer ve iş sürekliliği planının BT ayağıdır.
Felaket kurtarma planı kapsamında öncelikli hedef nedir?
Kritik iş süreçlerini kabul edilen süre ve veri kaybı sınırları içinde yeniden çalışır hale getirmektir. Bu sınırlar RTO (en geç kaç saatte dönülmeli) ve RPO (en fazla ne kadar veri kaybı kabul edilir) ile tanımlanır.
İş sürekliliği planı nasıl hazırlanır?
Önce iş etki analiziyle hangi sürecin ne kadar durabileceği belirlenir. Sonra her kritik süreç ve sistem için RTO ve RPO yazılır, roller ve iletişim listesi çıkarılır, geçici çalışma düzeni ve BT kurtarma adımları tanımlanır, plan yılda en az bir kez test edilir.
RTO ile RPO arasındaki fark nedir?
RTO, sistemin çöktükten sonra en geç ne kadar sürede yeniden çalışması gerektiğidir. RPO ise kabul edilebilir en fazla veri kaybıdır; son yedeğin en fazla ne kadar eski olabileceğini belirler. Örneğin RPO 1 saatse gece yedeği yetmez.
İş sürekliliği planının test edilmesinin amacı nedir?
Planın eksiklerini kriz yaşanmadan bulmaktır: eksik telefon numarası, bilinmeyen şifre, RTO’dan uzun süren geri yükleme gibi. Test sonucunda ölçülen süreler kaydedilir ve plan güncellenir.
İlgili hizmet: Bilgi teknolojileri