Kısaca: Felaket kurtarma planı, sunucu arızası, fidye yazılımı, yangın veya uzun süreli bir kesinti gibi olaylardan sonra kritik sistemlerin hangi sırayla, ne kadar sürede ve kimin sorumluluğunda yeniden çalışır hale getirileceğini yazılı olarak tanımlayan belgedir. İyi bir plan yedeğin varlığıyla değil, o yedekten belirlenen sürede geri dönülebildiğinin test edilmesiyle ölçülür.
Birçok işletme düzenli yedek aldığı için hazırlıklı olduğunu düşünür. Oysa bir kriz anında asıl sorular şunlardır: Hangi sistem önce açılacak? Yedek nereden, kim tarafından ve ne kadar sürede geri yüklenecek? Müşterilere ve çalışanlara ne söylenecek? Bu yazıda KOBİ’lerin bu sorulara önceden cevap veren bir planı nasıl hazırlayabileceğini adım adım anlatıyoruz.
Felaket Kurtarma ile İş Sürekliliği Arasındaki Fark
İki kavram sık karıştırılır. İş sürekliliği planı, bir kesinti sırasında işletmenin tüm faaliyetlerini (insan, mekân, tedarik, iletişim) nasıl sürdüreceğini ele alır. Felaket kurtarma planı ise bu planın BT ayağıdır; sunucuların, uygulamaların ve verinin nasıl geri getirileceğini tanımlar. Küçük işletmelerde ikisi tek bir belgede toplanabilir, ancak BT tarafının adımları mutlaka ayrıntılı yazılmalıdır.
Adım 1: Kritik Sistemleri ve İş Etkisini Belirleyin
Plan, hangi sistemin durmasının işe ne kadar zarar verdiğini anlamakla başlar. Buna iş etki analizi denir. Her sistem için şu sorular cevaplanmalıdır:
- Bu sistem durursa hangi süreçler etkilenir (sipariş, sevkiyat, fatura, üretim, muhasebe)?
- Kaç saat kesinti tolere edilebilir, hangi noktadan sonra müşteri veya yasal yükümlülük etkilenir?
- Sistem başka hangi sistemlere bağlı (veritabanı, Active Directory, internet bağlantısı, lisans sunucusu)?
- Sistemin sahibi ve teknik sorumlusu kim?
Bu çalışmanın sonunda sistemler önem sırasına göre gruplanır. Genellikle ERP, veritabanı ve e-posta en üst grupta yer alır; dosya arşivi veya test ortamları daha alt sıralara düşer.
Adım 2: RTO ve RPO Hedeflerini Tanımlayın
Her kritik sistem için iki hedef belirlenmelidir:
- RTO (Recovery Time Objective): Sistemin kesintiden sonra en geç ne kadar sürede yeniden çalışması gerektiği.
- RPO (Recovery Point Objective): En fazla ne kadarlık veri kaybının kabul edilebileceği. RPO bir saatse, en az saatlik yedek veya kopya gerekir.
Aşağıdaki tablo yalnızca örnektir; değerler her işletmenin kendi iş etki analizine göre belirlenmelidir.
| Sistem | Örnek RTO | Örnek RPO | Gerekçe |
|---|---|---|---|
| ERP ve veritabanı | 4 saat | 1 saat | Sipariş, sevkiyat ve faturalama durur |
| Kurumsal e-posta | 8 saat | 4 saat | Müşteri ve tedarikçi iletişimi aksar |
| Dosya sunucusu | 24 saat | 24 saat | Çalışma sürer, bazı belgeler gecikir |
| Kurumsal web sitesi | 24 saat | 1 hafta | İçerik seyrek değişir |
Daha kısa RTO ve RPO daha yüksek maliyet demektir. Bu yüzden hedefler BT ekibinin tek başına değil, yönetimle birlikte vereceği bir karardır.
Adım 3: Yedekleme Stratejisini Hedeflere Göre Kurun
Yedekleme, belirlediğiniz RPO hedefini karşılamalıdır. Yaygın kabul gören yaklaşım 3-2-1 kuralıdır: verinin en az üç kopyası, iki farklı ortamda ve bir kopyası farklı bir konumda tutulur.
- Fidye yazılımına karşı: En az bir kopya, ağdan ayrılmış (çevrimdışı) veya değiştirilemez (immutable) olmalıdır. Aynı ağdaki ve aynı yetkiyle erişilen yedekler saldırıda birlikte şifrelenebilir.
- Veritabanları için: Dosya kopyası yerine veritabanının kendi yedekleme yöntemi kullanılmalı, işlem günlüğü yedekleriyle RPO kısaltılmalıdır. Ayrıntıları SQL veritabanı yedekleme yazımızda anlattık.
- Yapılandırmalar için: Güvenlik duvarı, anahtar, sanallaştırma ve uygulama ayarları da yedeklenmelidir; yalnızca veri yedeği sistemi ayağa kaldırmaya yetmez.
- Saklama süresi için: Fark edilmesi geç olan bozulma veya saldırılarda eski bir temiz yedeğe dönebilmek için birden fazla gün ve hafta geriye giden kopyalar tutulmalıdır.
Adım 4: Kurtarma Senaryolarını ve Adımlarını Yazın
Plan, olası olaylar için ayrı ayrı yazılmış senaryolar içermelidir. Her olayın kurtarma yolu farklıdır:
Donanım veya sunucu arızası
Yedek donanım veya sanallaştırma ortamında sistemin yeniden kurulması, yedeğin geri yüklenmesi ve bağımlı sistemlerin sırayla açılması adımları yazılır.
Fidye yazılımı saldırısı
Önce yayılmayı durdurmak için etkilenen sistemler ağdan ayrılır. Geri yüklemeden önce saldırının giriş noktası ve temiz yedeğin tarihi belirlenir; aksi halde aynı açıktan yeniden saldırı yaşanabilir. Sunucu ve ağ tarafındaki ön hazırlık için sunucu ve ağ altyapısı kontrol listemize bakabilirsiniz.
Mekân veya bağlantı kaybı
Ofise veya sistem odasına erişilemediğinde çalışanların nereden ve hangi araçlarla çalışacağı, kritik sistemlerin farklı bir konumda nasıl çalıştırılacağı tanımlanır.
Her senaryoda adımlar, sorumlu kişi, gereken erişim bilgileri ve beklenen süre açıkça yazılmalıdır. Kriz anında planı yazan kişinin ulaşılabilir olacağı varsayılmamalıdır.
Adım 5: Roller, Erişim ve İletişimi Belirleyin
- Krizi kimin ilan edeceği ve kararları kimin vereceği yazılı olmalıdır.
- Yedek yöneticisi, sistem yöneticisi ve dış destek firmalarının iletişim bilgileri güncel tutulmalıdır.
- Yönetici parolaları, lisans anahtarları ve yedek erişim bilgileri güvenli ama erişilebilir bir yerde saklanmalıdır.
- Çalışanlara, müşterilere ve tedarikçilere hangi kanaldan ne zaman bilgi verileceği önceden belirlenmelidir.
- Kişisel veri içeren bir olayda yasal bildirim yükümlülükleri ve süreleri planda yer almalıdır.
Adım 6: Planı Test Edin ve Güncel Tutun
Test edilmemiş bir plan, kriz anında ilk kez denenen bir varsayımdır. Testler zorluk derecesine göre planlanabilir:
- Masa başı tatbikat: Ekip bir senaryo üzerinden planı adım adım konuşur ve eksikleri not eder.
- Kısmi geri yükleme testi: Bir veritabanı veya sunucu yedekten ayrı bir ortama geri yüklenir ve gerçek sürenin RTO hedefini karşılayıp karşılamadığı ölçülür.
- Tam geçiş testi: Kritik sistemler planlı bir zamanda yedek ortama geçirilir ve iş süreçleri orada çalıştırılır.
Plan en az yılda bir ve her önemli altyapı değişikliğinden sonra (yeni ERP, yeni sunucu, bulut geçişi) gözden geçirilmelidir. Yeni eklenen bir sistem planda yoksa, kriz anında da unutulur.
Felaket Kurtarma Planında Sık Yapılan Hatalar
- Yedeği kurtarma sanmak: Yedeğin alındığı biliniyor ama hiç geri yükleme denenmemiş.
- Bağımlılıkları unutmak: Uygulama geri yüklenmiş, ancak kimlik doğrulama, DNS veya lisans sunucusu olmadan açılmıyor.
- Planı tek kişiye bağlamak: Adımlar yalnızca bir çalışanın bilgisinde, o kişi ulaşılamaz durumda.
- Planı bir kez yazıp bırakmak: Belge yıllar önceki altyapıyı anlatıyor.
- Yedeklerin aynı ağda olması: Fidye yazılımı canlı sistemlerle birlikte yedekleri de şifreliyor.
Felaket Kurtarma Planı Kontrol Listesi
- Kritik sistemler ve önem sıraları belirlendi mi?
- Her kritik sistem için RTO ve RPO hedefi yönetimle birlikte kararlaştırıldı mı?
- Yedekleme 3-2-1 kuralına uyuyor ve en az bir kopya çevrimdışı veya değiştirilemez mi?
- Yapılandırmalar ve erişim bilgileri de yedekleniyor mu?
- Her senaryo için adımlar, sorumlular ve süreler yazılı mı?
- İletişim listesi ve bildirim adımları güncel mi?
- Son geri yükleme testi ne zaman yapıldı, gerçek süre hedefi karşıladı mı?
- Plan son altyapı değişikliğinden sonra güncellendi mi?
Felaket kurtarma planı, kapsamlı bir teknoloji danışmanlığı çalışmasının en somut çıktılarından biridir. Mevcut altyapınızı, yedekleme düzeninizi ve kurtarma sürelerinizi birlikte değerlendirmek isterseniz sunucu ve ağ danışmanlığı hizmetimizi inceleyebilir veya bizimle iletişime geçebilirsiniz.
Sıkça Sorulan Sorular
Felaket kurtarma planı nedir?
Felaket kurtarma planı; sunucu arızası, fidye yazılımı veya uzun süreli kesinti gibi olaylardan sonra kritik BT sistemlerinin hangi sırayla, ne kadar sürede ve kimin sorumluluğunda yeniden çalıştırılacağını tanımlayan yazılı belgedir. Yedekleme, kurtarma adımları, roller ve test takvimini içerir.
RTO ve RPO arasındaki fark nedir?
RTO, bir sistemin kesintiden sonra en geç ne kadar sürede yeniden çalışması gerektiğini; RPO ise en fazla ne kadarlık veri kaybının kabul edilebileceğini gösterir. Örneğin RPO bir saatse, sistemin en az saatlik yedeği veya kopyası bulunmalıdır.
Düzenli yedek almak felaket kurtarma için yeterli mi?
Hayır. Yedek, kurtarmanın yalnızca bir parçasıdır. Hangi sistemin önce açılacağı, bağımlılıkların nasıl kurulacağı, kimin ne yapacağı ve geri yüklemenin gerçekte ne kadar sürdüğü bilinmiyorsa, yedek olduğu halde kesinti hedeflenenden çok daha uzun sürebilir.
Felaket kurtarma planı ne sıklıkla test edilmeli?
Plan en az yılda bir test edilmeli ve her önemli altyapı değişikliğinden sonra gözden geçirilmelidir. Kritik veritabanları için yedekten geri yükleme testinin daha sık, örneğin üç ayda bir yapılması önerilir.
Küçük bir işletmenin de felaket kurtarma planına ihtiyacı var mı?
Evet. Küçük işletmeler bir kesintiyi telafi edecek kaynağa genellikle daha az sahiptir. Plan büyük bir belge olmak zorunda değildir; kritik sistemler, yedekleme düzeni, kurtarma adımları ve iletişim listesini içeren kısa bir belge bile kriz anında ciddi zaman kazandırır.