Kısaca özet
- Felaket kurtarma planı, sunucu, veri ya da hizmet kaybı yaşandığında sistemleri hangi sırayla, kim tarafından ve ne kadar sürede geri getireceğinizi önceden yazan belgedir.
- Planın iki temel ölçüsü vardır: RPO, kaybetmeye razı olduğunuz en fazla veri süresi; RTO, hizmetin en geç ne kadar sürede yeniden açılması gerektiğidir.
- Küçük işletme için dört senaryo yeterli bir başlangıçtır: donanım arızası, fidye yazılımı, yanlış silme ve sağlayıcı ya da hesap kaynaklı kesinti.
- Sade bir plan tek sayfaya sığar: sistem listesi, her sistem için RPO ve RTO, yedeklerin yeri, erişim bilgilerinin yeri, sorumlu kişi ve adım sırası.
- Test edilmemiş plan varsayımdır; yılda en az bir kez yedekten gerçek bir geri dönüş denemesi yapılmadan RTO rakamına güvenilmez.
Çoğu küçük işletme felaket kurtarmayı bankaların ve büyük şirketlerin işi olarak görür. Oysa bir gün e-ticaret sitesinin açılmaması, muhasebe dosyalarının şifrelenmesi ya da tek sunucunun diskinin bozulması, küçük işletmeyi büyük şirketten daha sert vurur; çünkü yedek ekip, yedek sistem ve ayrılmış bütçe yoktur. Felaket kurtarma planı bu açığı kapatmanın en ucuz yoludur. Bir öğleden sonra yazılır, kriz anında ise saatler kazandırır.
Felaket Kurtarma Planı Nedir
Felaket kurtarma planı (disaster recovery plan), bir kesinti ya da veri kaybından sonra BT sistemlerini yeniden çalışır hâle getirmek için izlenecek adımları, sorumluları ve hedef süreleri tanımlayan yazılı bir belgedir. İş sürekliliği planının teknik ayağıdır: iş sürekliliği “işletme kesinti sırasında nasıl çalışmaya devam eder” sorusuna, felaket kurtarma ise “sistemler nasıl geri gelir” sorusuna cevap verir.
Konunun resmî çerçevesi, ABD Ulusal Standartlar ve Teknoloji Enstitüsü’nün SP 800-34 acil durum planlama rehberinde çizilir. Rehber büyük kurumlar için yazılmıştır, ama temel kavramları küçük bir işletmeye de doğrudan uyar.
RPO ve RTO, Planın İki Temel Ölçüsü
RPO (Recovery Point Objective, kurtarma noktası hedefi), bir olayda kaybetmeye razı olduğunuz en fazla veri süresidir. RPO’nuz 24 saat ise son yedeğinizin en fazla bir gün önceye ait olması yeterlidir; RPO’nuz 1 saat ise saatlik bir koruma gerekir. RPO doğrudan yedek sıklığını belirler.
RTO (Recovery Time Objective, kurtarma süresi hedefi), hizmetin kesintiden sonra en geç ne kadar sürede yeniden açılması gerektiğidir. Web sitesi için RTO 4 saat ise yedeğin geri yüklenmesi, gerekiyorsa yeni sunucunun hazırlanması ve alan adının yönlendirilmesi bu sürenin içine sığmalıdır. RTO, yedeğin nerede durduğunu ve geri yüklemenin ne kadar sürdüğünü belirler.
Bilgi
RPO ve RTO’yu teknik ekip değil, işletme sahibi belirler. Soru teknik değil ticaridir: “Bir günlük siparişi kaybetmek bize neye mal olur” ve “sitemiz dört saat kapalı kalırsa ne kaybederiz”. Rakam belli olduktan sonra teknik çözüm ona göre seçilir; daha kısa hedef genelde daha yüksek maliyet demektir.
Küçük İşletme İçin Olası Senaryolar
Her olası felaketi planlamaya gerek yoktur. Küçük bir işletmenin yaşayacağı olayların büyük kısmı dört senaryoda toplanır. Aşağıdaki tablo her senaryo için örnek bir RPO, RTO ve temel önlemi gösteriyor. Rakamlar küçük bir e-ticaret sitesi için örnektir; kendi işletmenize göre değiştirin.
| Senaryo | Örnek RPO | Örnek RTO | Temel önlem |
|---|---|---|---|
| Donanım ya da disk arızası | 24 saat | 4 saat | Sunucu dışında tutulan güncel yedek, yeni sunucuya hızlı kurulum adımları |
| Fidye yazılımı | 24 saat | 8 saat | Çevrimdışı ya da değiştirilemez yedek, temiz sistemden kurulum, parolaların yenilenmesi |
| Yanlış silme veya bozuk güncelleme | Değişiklik öncesi an | 1 saat | Büyük değişiklikten önce manuel yedek, sürüm geçmişi |
| Sağlayıcı ya da hesap kaynaklı kesinti | 24 saat | 24 saat | Sağlayıcıdan bağımsız yerde yedek, alan adı ve DNS yönetimine erişim |
Dikkat
Fidye yazılımı senaryosunda en sık görülen hata, sunucuya bağlı yedek klasörlerinin de şifrelenmesidir. Saldırganın erişebildiği yedek, felaket anında yedek değildir. En az bir kopya bağlantısı kesilmiş bir ortamda ya da belirli süre silinemeyen bir depolamada durmalıdır. Saldırıya uğrayan bir sistemin ilk anlarında yapılacakları site hacklenirse ne yapmalı yazısı sıralıyor.
Sade Bir Felaket Kurtarma Planı Şablonu
Küçük işletme için etkili bir felaket kurtarma planı tek sayfayı geçmez. Önemli olan uzunluk değil, kriz anında kimsenin tahmin yürütmek zorunda kalmamasıdır. Şablon şu başlıklardan oluşur:
Sistem listesi: web sitesi, e-posta, muhasebe yazılımı, müşteri veritabanı gibi kritik sistemler ve her birinin nerede çalıştığı. Hedefler: her sistem için RPO ve RTO. Yedeklerin yeri: hangi yedeğin nerede durduğu, ne sıklıkla yenilendiği. Erişim bilgileri: hosting paneli, alan adı hesabı, DNS, bulut depolama; parolaların kendisi değil, şifre yöneticisindeki yeri. Sorumlular: birinci ve yedek sorumlu, sağlayıcıların destek iletişim bilgileri. Adım sırası: her senaryo için ilk bir saatte yapılacak beş-altı adım.
Planın basılı bir kopyasını da saklayın. Sunucu ya da e-posta çöktüğünde planın yalnızca o sunucuda veya o e-posta kutusunda durması, en sık görülen ve en can sıkıcı hatadır.
Örnek senaryo
Altı çalışanlı bir mimarlık ofisi web sitesini ve proje arşivini bir bulut sunucuda tutuyor. Bir sabah yanlış çalıştırılan bir betik proje klasörünün yarısını siliyor. Ofisin tek sayfalık planında bu senaryo yazılı: sorumlu kişi sunucuya erişimi durduruyor, gece alınan yedeğin uzak depolamadaki kopyasını bularak silinen klasörü ayrı bir dizine geri yüklüyor, doğruladıktan sonra yerine taşıyor. İş iki saatte bitiyor ve kayıp, planda kabul edilen bir günlük RPO’nun içinde kalıyor.
Yedek, Snapshot ve Kurtarma Arasındaki İlişki
Felaket kurtarma planı yedeğin yerine geçmez, yedeği kullanılabilir hâle getirir. Yedek RPO’yu, planın geri kalanı RTO’yu karşılar. Yedek türü de önemlidir. Sunucu diskinin anlık görüntüsünü alan snapshot, bozuk bir güncellemeden dakikalar içinde dönmek için çok kullanışlıdır; ama çoğunlukla aynı altyapıda durduğu için donanım ya da sağlayıcı senaryosunda tek başına yetmez. Farkı snapshot yedek yerine geçer mi yazısı ayrıntılı anlatıyor.
Yedeklerin kaç kopya ve nerede tutulacağı, sağlayıcı seçerken hangi soruların sorulacağı gibi konular hosting yedeklemesi neden önemli yazısında toplanıyor.
Planı Test Etmek Neden Şart
Hiç denenmemiş bir planda RTO rakamı bir tahminden ibarettir. Test sırasında ortaya çıkan sorunlar hemen her zaman aynıdır: yedek arşivinin parolası bilinmiyor, veritabanı dökümü eksik, geri yükleme beklenenden üç kat uzun sürüyor ya da alan adı hesabına giriş yapacak kişi izinde. Bunların hepsini kriz anında değil, sakin bir günde öğrenmek istersiniz.
Küçük işletme için yılda bir tam deneme yeterli bir başlangıçtır. Yedeği ayrı bir test ortamına geri yükleyin, sitenin açıldığını ve verilerin güncel olduğunu kontrol edin, geçen süreyi not edin. Dosya, veritabanı ve e-posta geri yükleme adımları yedekten geri yükleme kartında tek tek anlatılıyor. Ölçülen süre RTO’nuzdan uzunsa ya hedefi ya da yöntemi değiştirin.
Sonuç
Felaket kurtarma planı küçük işletmeye de gerekir, çünkü kayıp ne kadar küçük görünse de telafisi en zor olan işletme odur. RPO ve RTO’yu işletme olarak belirleyin, dört temel senaryoyu tek sayfalık bir plana yazın, yedeklerden en az birini sağlayıcıdan bağımsız tutun ve planı yılda en az bir kez gerçekten deneyin.
Bulut Sunucu Kurtarma Planında Nerede Durur
Donanım ya da sunucu senaryosunda RTO’yu en çok uzatan adım, yedeği geri yükleyeceğiniz yeni sunucunun hazırlanmasıdır. Narhost bulut sunucular sipariş sonrası anında kurulur, NVMe disk ve 50 Gbps port ile gelir ve Equinix veri merkezinde çalışır; ağ katmanında Layer 3 ve Layer 4 DDoS koruması vardır. Bu, yedekten yeni bir ortam açmanız gerektiğinde bekleme süresini kısaltır. Sunucunun içindeki yedek düzeni ve geri yükleme adımları ise planınızın kendisidir. Paketler bulut sunucu paketleri sayfasında.
Kontrol Listesi, Planı Yazmadan Önce
- İşletmenin çalışması için gereken kritik sistemleri tek listede toplayın.
- Her sistem için kabul edilebilir veri kaybını (RPO) ve kesinti süresini (RTO) yazın.
- Yedeklerin nerede durduğunu ve en az birinin sağlayıcıdan bağımsız olduğunu doğrulayın.
- Alan adı, DNS, hosting ve bulut depolama hesaplarına kimin erişebildiğini belirleyin.
- Dört temel senaryo için ilk bir saatte yapılacak adımları sıralayın.
- Planın basılı bir kopyasını sunucudan ve e-postadan bağımsız bir yerde saklayın.
- Yılda en az bir kez yedekten test ortamına geri yükleme yapıp süreyi ölçün.
Sıkça sorulan sorular
Küçük bir işletmenin felaket kurtarma planı ne kadar ayrıntılı olmalı?
Kriz anında tek başına okunup uygulanabilecek kadar. Çoğu küçük işletme için tek sayfa yeterlidir: kritik sistemler, RPO ve RTO hedefleri, yedeklerin yeri, erişim bilgilerinin yeri, sorumlular ve her senaryo için ilk adımlar. Uzun ve kimsenin okumadığı bir belge, kısa ve güncel bir listeden daha az işe yarar.
RPO ile RTO arasındaki fark nedir, hangisi daha önemli?
RPO ne kadar veri kaybedebileceğinizi, RTO ne kadar süre kapalı kalabileceğinizi gösterir. Hangisinin önemli olduğu işletmeye bağlıdır. Sipariş alan bir mağaza için veri kaybı daha acıdır, RPO kısalır; bilgi amaçlı bir kurumsal sitede asıl mesele erişilebilirliktir, RTO öne çıkar.
Hosting firmasının yedeği felaket kurtarma planı yerine geçer mi?
Geçmez. Sağlayıcı yedeği planın bir parçasıdır, planın kendisi değildir. Hesaba erişimin kesildiği ya da sorunun yedek aralığından eski olduğu durumlarda tek başına yetmez. Sağlayıcıdan bağımsız bir kopya, erişim bilgileri ve adım sırası planı tamamlar.
Felaket kurtarma planı ne sıklıkla güncellenmeli?
En az yılda bir kez ve her büyük değişiklikten sonra. Yeni bir sistem eklendiğinde, sağlayıcı değiştiğinde, sorumlu kişi işten ayrıldığında ya da yedek yöntemi değiştiğinde plan eskir. Güncelleme ile test aynı güne konursa ikisi de unutulmaz.
Planı test etmek siteyi kapatmayı gerektirir mi?
Gerektirmez. Test, canlı siteye dokunmadan ayrı bir ortamda yapılır: yedek bir test sunucusuna ya da alt alan adına geri yüklenir, sitenin açıldığı ve verilerin doğru olduğu kontrol edilir. Canlı siteyi kapatarak test yapmak gereksiz bir risktir.
Narhost’ta
Bulut sunucularımız anında kurulur, NVMe disk ve 50 Gbps port ile gelir; yedekten yeni bir ortam açmanız gerektiğinde beklemezsiniz.