Felaket kurtarma planı neden gerekli?

Yedeğiniz olması, işin kaldığı yerden devam edeceği anlamına gelmez. Felaket kurtarma, kesinti olduğunda hangi sistemin kim tarafından ve ne sürede ayağa kalkacağını önceden yazmaktır.

Yedek başka, plan başka

Yedek, verinin bir kopyasıdır. Yedekleme yazımızda anlattığımız 3-2-1 düzeni bu kopyaların nasıl duracağını anlatır. Felaket kurtarma ise o kopyalarla işin nasıl süreceğini anlatır: hangi sistem önce açılır, kararı kim verir, müşteriye kim haber verir, hedef süre nedir.

Kopya sağlam olsa bile sıra, yetki ve iletişim yazılmamışsa geri dönüş uzar. Küçük ekiplerde çoğu zaman sunucuyu bilen tek kişi izindedir. Plan, o kişinin cebindeki bilgiyi şirketin bilgisi haline getirir.

Neden KOBİ de yazmalı?

Kesinti yalnızca büyük veri merkezlerinin konusu değildir. Fidye yazılımı dosyaları kilitler. Yangın ya da su basması odayı kullanılamaz hale getirir. Uzun süren elektrik veya internet kesintisi, tek bir sunucu arızası da aynı sonucu doğurur: muhasebe, e-posta veya ortak dosyalar açılmaz.

Bu senaryoların olasılığını sayıyla tahmin etmeniz gerekmez. Soru daha sadedir. Yarın sabah bu sistemler kapalı olsa, öğlene kadar ne yapardınız ve bunu kim bilirdi?

RTO ve RPO

İki hedef yeter. İkisini de saat veya gün olarak yazarsınız.

Kurtarma noktası hedefi (RPO), ne kadar veri kaybını kabul ettiğinizdir. Son sağlam kopyadan bu yana geçen süredir.

Kurtarma süresi hedefi (RTO), sistemin yeniden kullanılabilir olması için kabul ettiğiniz süredir. "Bir an önce" yazmak hedef değildir.

Aynı şirkette bu iki sayı sistemden sisteme değişir. Ön muhasebede dünkü fişlerin kaybolması ay kapanışını bozar; burada RPO'yu bir iş gününden kısa tutmak gerekir. Programın kendisi ertesi sabah açılsa da kasa bir gün idare edebilir; RTO bir iş günü olabilir. Kurumsal e-postada birkaç saatlik ileti kaybı çoğu zaman tolere edilir, yani RPO daha gevşektir. Buna karşılık müşteri siparişinin düştüğü ekran için RTO saatlerle ölçülür. Listeyi sistem sistem yazın. Herkese aynı süreyi vermeyin.

Asgari planda beş madde

Kalın bir klasör şart değil. İlk sürüm şunlardan oluşur:

1. Kritik sistemler: muhasebe, e-posta, dosya alanı ve varsa üretim veya sipariş yazılımı.
2. Sahipler: her sistem için bir isim ve o kişi yokken bakacak ikinci isim.
3. Geri dönüş sırası: önce kimlik doğrulama ve ağ, sonra işin durduğu uygulama, en son arşiv.
4. İletişim: çalışanlara, müşterilere ve varsa tedarikçiye kim, hangi kanaldan, ne söyleyecek.
5. Yılda bir masa başı tatbikatı: ekip bir senaryoyu, örneğin fidye yazılımını veya sunucu odasının kullanılamamasını, adım adım konuşur. Eksik kalan karar ve kişi orada ortaya çıkar.

Tatbikat, kopyanın gerçekten açıldığını gösteren geri yükleme denemesinin yerine geçmez. İkisi ayrı iştir. Biri kopyanın sağlam olduğunu, diğeri planın işlediğini gösterir.

Test edilmemiş plan, plan değildir.

Tatbikatta takıldığınız yer, gerçek günde de takılacağınız yerdir. Notu düzeltip bir sonraki tarihi takvime yazmak, planı rafta bırakmaktan iyidir.

Doğa Network nasıl yardımcı olabilir?

Felaket kurtarma planının yazılması, RTO ve RPO hedeflerinin sistem bazında belirlenmesi ve masa başı tatbikatı konusunda ekibimiz destek verebilir. Bize 0850 888 3642 numaralı telefondan veya hi@doga.network adresinden ulaşabilirsiniz.