Felaket kurtarma planı nasıl hazırlanır? Örnek plan

Felaket kurtarma planı, işi durduran bir olaydan sonra sistemlerin hangi sırayla, kim tarafından ve ne kadar sürede geri getirileceğini yazan belgedir. Büyük şirketlerde yüzlerce sayfa olabilir; 10 ila 50 kişilik bir işletme için iki üç sayfa yeter. Önemli olan, olay anında herkesin ne yapacağını bilmesi ve planın en az bir kez denenmiş olmasıdır.

Önce iki kavram: RPO ve RTO

• RPO (kabul edilebilir veri kaybı): Bir olayda en fazla ne kadarlık veriyi kaybetmeyi göze alırsınız? Gece bir kez yedek alıyorsanız RPO'nuz pratikte 24 saattir: öğleden sonra çöken bir sunucuda o günün kayıtları gider.
• RTO (kabul edilebilir kesinti süresi): Sistem en geç ne kadar sürede yeniden çalışmalı? Muhasebe programı için bir iş günü kabul edilebilir; sipariş alan bir sistem için birkaç saat bile uzun olabilir.

Bu iki rakam yedek düzenini belirler. RPO 4 saatse günde bir yedek yetmez. RTO 4 saatse, 500 GB'lık bir sunucuyu buluttan indirmek bu süreye sığmayabilir; ofiste ikinci bir kopya gerekir. Kopyaların nasıl dağıtılacağını 3-2-1 yedekleme kuralı yazısında anlattık.

Adım 1: Sistemleri listeleyin ve sıralayın

Her sistem için dört bilgi yazın: RPO, RTO, yedeğin nerede durduğu ve sorumlu kişi. Örnek:

• Muhasebe (Logo, SQL Server): RPO 4 saat, RTO 1 iş günü. Yedek: gece ve öğlen yerel, gece bulut. Sorumlu: muhasebe müdürü, teknik destek dış servis.
• E-posta: RTO 2 saat. Posta kutuları e-posta hizmet sağlayıcısının sunucularında duruyor. Sorumlu: BT sorumlusu.
• Ortak dosyalar: RPO 24 saat, RTO 1 iş günü. Yedek: NAS ve bulut. Sorumlu: BT sorumlusu.
• Dizüstü bilgisayarlar: RPO 24 saat, RTO 2 iş günü. Yedek: bulut. Sorumlu: her çalışan, kurulum BT sorumlusu.
• Web sitesi: Hosting firmasında duruyor. Sorumlu: hosting firması, takip pazarlama sorumlusu.

Sıralamada para ve müşteriyle ilgili sistemler öne gelir. Herkes "benim sistemim önemli" der; sırayı olaydan önce yönetim belirlemelidir.

Adım 2: Olası olayları yazın

• Sunucu diski ya da sunucunun kendisi arızalanıyor.
• Fidye yazılımı dosyaları şifreliyor.
• Yangın ya da su baskını yüzünden ofise girilemiyor.
• Bilgisayar ya da sunucu çalınıyor.
• İnternet ya da elektrik uzun süre kesiliyor.
• Parolaları bilen tek kişiye ulaşılamıyor.

Sonuncusu küçük işletmelerde kolayca gözden kaçar. Yönetici parolaları, lisans bilgileri ve yedekleme hesabının bilgileri en az iki kişinin ulaşabildiği bir parola yöneticisinde ya da kilitli bir dolapta durmalıdır. Her olay için hangi sistemlerin etkileneceğini ve hangi kopyadan dönüleceğini yazın.

Adım 3: Kim ne yapacak?

• Olayı ilan eden kişi: Felaket durumuna geçildiğine karar verir. Genellikle şirket sahibi ya da genel müdür.
• Teknik sorumlu ve yedeği: Geri dönüş adımlarını yürütür.
• Dış destek: BT servis firması, yedekleme hizmetinin destek hattı, internet sağlayıcı, hosting firması.
• İletişim sorumlusu: Çalışanlara ve gerekirse müşterilere bilgi verir.

Telefon numaraları planın basılı kopyasında da olmalıdır. Sunucu çalışmıyorsa sunucudaki belgeyi açamazsınız; fidye yazılımı varsa e-posta da çalışmıyor olabilir.

Adım 4: Geri dönüş adımlarını yazın

Her kritik sistem için adım adım bir liste hazırlayın. Muhasebe sunucusunun kullanılamadığı durum için örnek:

1. Olayı ilan edin; kullanıcılara muhasebe programına giriş yapmamalarını bildirin.
2. Yeni bir sunucu ya da geçici bir bilgisayar hazırlayın: Windows, SQL Server ve muhasebe programının kurulum dosyaları ile lisans bilgileri. SQL Server yedeği, aynı ya da daha yeni bir SQL Server sürümüne geri yüklenebilir; daha eski bir sürüme yüklenemez.
3. Buluttaki son veritabanı yedeğini indirip SQL Server'a geri yükleyin.
4. Programı veritabanına bağlayın ve son kaydın tarihini kontrol edin.
5. Kayıp aralığı belirleyin. Bu aralıktaki işlemler kâğıttan, e-postalardan ya da e-Fatura entegratörünün portalından yeniden girilir.
6. Kullanıcılara çalışmaya başlayabileceklerini bildirin ve olay kaydını yazın: ne oldu, ne kadar sürdü, ne kayboldu.

Veritabanı yedeğinin nasıl alındığını SQL Server otomatik yedekleme yazısında, fidye yazılımı durumundaki ek adımları fidye yazılımına karşı yedekleme yazısında anlattık.

Geri dönüş süresini önceden hesaplayın

RTO'yu kâğıt üzerinde tutturmak kolaydır; gerçekte süre üç parçadan oluşur:

1. Hazırlık: Yeni donanımı bulmak, Windows'u, SQL Server'ı ve programları kurmak. Küçük bir sunucu için bile birkaç saat sürebilir.
2. İndirme: Yedeğin buluttan inmesi. 300 GB veri, saniyede 100 megabitlik bir hattan en iyi koşulda yaklaşık 7 saatte iner.
3. Kontrol: Verinin açıldığını, programların veritabanına bağlandığını ve son kayıtların yerinde olduğunu doğrulamak.

Bu üç süreyi toplayıp RTO'nuzla karşılaştırın. Toplam uzun geliyorsa önce en kritik veriyi indirmek, ofiste yerel bir kopya tutmak ya da yedek bir bilgisayarı hazır bekletmek süreyi kısaltır.

Adım 5: Tatbikat yapın

Planın gerçekten işlediğini görmenin tek yolu denemektir. Yılda en az bir kez iki tür tatbikat yapın:

• Masa başı tatbikat: Ekip bir saatliğine toplanır, bir senaryo okunur ("Pazartesi sabahı sunucu açılmıyor") ve herkes ne yapacağını anlatır. Eksik telefon numaraları, kimsenin bilmediği parolalar burada ortaya çıkar.
• Gerçek geri yükleme: Kritik bir sistemin yedeği ayrı bir bilgisayara geri yüklenir ve süre ölçülür. Ölçülen süre RTO'dan uzunsa plan değişir: ofiste yerel bir kopya tutulur, önce en kritik veri indirilir ya da internet hattı hızlandırılır.

Adım 6: Planı güncel tutun

Yeni bir program, yeni bir sunucu, ayrılan ya da yeni gelen bir çalışan planı değiştirir. Belgenin başına son güncelleme tarihini yazın ve her tatbikattan sonra gözden geçirin.

Örnek plan şablonu

Aşağıdaki başlıkları bir belgeye kopyalayıp doldurabilirsiniz:

1. Planın sahibi ve son güncelleme tarihi
2. Olayı ilan etme yetkisi olan kişiler
3. İletişim listesi: şirket içi ve dış destek, telefon numaralarıyla
4. Sistem listesi: sistem, RPO, RTO, yedeğin yeri, sorumlu
5. Olay türleri ve her biri için ilk adımlar
6. Her kritik sistem için geri dönüş adımları
7. Parolaların, lisansların ve kurulum dosyalarının nerede durduğu
8. Son tatbikatın tarihi, ölçülen süreler ve çıkan dersler

Örnek senaryo

Aşağıdaki örnek gerçek bir olay değildir; bir planın nasıl işlediğini göstermek için kurgulandı.

Bir hırdavat toptancısının deposunu cuma gecesi su basıyor; sunucu ve iki masaüstü bilgisayar kullanılamaz hale geliyor. Planda ilk adımlar hazır: şirket sahibi cumartesi sabahı olayı ilan ediyor, BT servis firması aranıyor. Pazartesi sabahı muhasebe programı, bir dizüstü bilgisayara kurulan SQL Server'a buluttaki cuma gecesi yedeği yüklenerek açılıyor. Telefon listesi basılı olduğu için tedarikçilere ve müşterilere aynı gün haber veriliyor. Yedek su baskınından önce alındığı için kayıt kaybı olmuyor; iş pazartesi sabahı birkaç saatlik gecikmeyle başlıyor. Yeni sunucu geldiğinde veritabanı aynı yolla oraya taşınıyor.

Sunucuların buluta yedeklenmesini ve geri yüklenmesini sunucu yedekleme sayfasında anlattık.