“Yedeğimiz var, felaket kurtarma planına ne gerek var?” Bu soru çoğu zaman bir arızadan sonra cevap bulur. Yedek oradadır, ama sunucunun diski yoktur, yeni donanım iki gün sonra gelecektir ve geri yükleme için gereken adımları kimse bilmemektedir. Yedekleme ile felaket kurtarma birbirine sıkı bağlı iki kavramdır, ama aynı soruyu cevaplamaz. Yedekleme “verim güvende mi?” sorusuna, felaket kurtarma ise “işim ne zaman yeniden çalışır?” sorusuna cevap verir. Bu yazıda iki kavramın farkını, nerede kesiştiklerini ve hangi sistem için hangisine ihtiyaç duyduğunuzu anlatıyoruz. Konuya iki yönden bakmak için yedekleme ve felaket kurtarma sayfalarımıza göz atabilirsiniz.
Yedekleme nedir?
ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), acil durum planlama rehberi SP 800-34’te yedeği kısaca şöyle tanımlar: gerektiğinde kurtarmayı kolaylaştırmak için alınmış dosya ve program kopyası. Tanımın odağı veridir. Yedek; bir dosyanın dünkü hâlini, bir veritabanının geçen haftaki durumunu ya da bir sunucunun tam imajını saklar.
İyi bir yedek geçmişe dönebilmenizi sağlar. Yanlışlıkla silinen bir klasör, bozulan bir Excel dosyası ya da fidye yazılımıyla şifrelenen bir paylaşım, yedekten geri getirilir. Yedekler genellikle gün içinde bir ya da birkaç kez alınır ve haftalar, aylar boyunca saklanır.
Felaket kurtarma nedir?
Aynı NIST rehberi felaket kurtarma planını, büyük bir donanım ya da yazılım arızasına veya tesislerin zarar görmesine karşı, bir ya da daha fazla bilgi sistemini alternatif bir tesiste kurtarmak için yazılmış plan olarak tanımlar. Buradaki odak sistemdir ve süredir. Felaket kurtarma; sunucunun nerede, hangi donanımda, hangi ağda, kimin tarafından ve ne kadar sürede yeniden çalıştırılacağını belirler.
Felaket kurtarma bir ürün değil, bir yetenektir. İçinde teknik altyapı (replikasyon, yedek lokasyon, ağ yönlendirmesi), yazılı bir plan (kim neyi hangi sırayla yapar) ve düzenli testler bulunur.
Yan yana karşılaştırma
| Yedekleme | Felaket kurtarma | |
|---|---|---|
| Cevapladığı soru | Veriyi geri getirebilir miyim? | İşim ne kadar sürede yeniden çalışır? |
| Odak | Veri ve geçmiş sürümler | Sistemler, altyapı ve süreç |
| İlgili hedef | Daha çok RPO: ne kadar veri kaybı | Daha çok RTO: ne kadar kesinti |
| Tipik yöntem | Zamanlanmış yedek, uzak kopya, değiştirilemez kopya | Replikasyon, yedek lokasyon, buluta yük devretme, yazılı plan |
| Kapsadığı olay | Silme, bozulma, fidye yazılımı, tek sunucu arızası | Lokasyon kaybı, uzun süreli kesinti, büyük çaplı arıza |
| Saklama | Haftalar, aylar, yıllar | Genellikle yalnızca son durum ve kısa geçmiş |
| Kanıtı | Geri yükleme testi | Yük devretme testi ve tatbikat |
RTO ve RPO kavramlarını ayrıntılı olarak RTO ve RPO nedir? yazımızda anlattık.
Birbirinin yerini tutmazlar
Yedek, hızlı geri dönüş sağlamaz
Onlarca terabaytlık bir sunucuyu yedekten geri yüklemek saatler sürer. Donanım yoksa, önce donanımın temin edilmesi gerekir. Yedek buluttaysa, geri yükleme internet hattınızın hızıyla sınırlıdır. Üretim hattını yöneten bir uygulama için bu süre kabul edilemez olabilir.
Replikasyon, yedek değildir
Felaket kurtarmanın temel yöntemi olan replikasyon, kaynaktaki her değişikliği hedefe kopyalar. Yanlışlıkla silinen bir tablo ya da fidye yazılımıyla şifrelenen dosyalar da anında kopyalanır. Replika, sistemin güncel bir kopyasıdır; geçmişe dönmenizi sağlamaz. Bu yüzden replikasyon kurulan sistemlerde de geçmişe dönük yedekler ayrıca saklanır.
İkisi aynı temeli paylaşır
Felaket kurtarma çoğu zaman yedeklemenin üzerine kurulur. Yedekten doğrudan sanal makine başlatma, yedeğin bir kopyasını ikinci bir lokasyonda hazır tutma ya da yedekleri buluta göndererek orada çalıştırma, iki kavramın kesiştiği yöntemlerdir.
Aynı olay, iki farklı sonuç
Farkı somut görmek için bir senaryo düşünelim. Cuma gecesi sistem odasındaki klima arızalanır, depolama ünitesi aşırı ısınır ve disklerin bir kısmı bozulur. ERP, dosya sunucusu ve etki alanı denetleyicisi aynı depolama üzerinde çalışmaktadır.
Yalnızca yedeği olan firma
Yedekler sağlamdır ve bir kopyası şehir dışındadır. Ama yeni depolama ünitesinin gelmesi birkaç gün sürer. Geçici bir sunucu bulunur, sanallaştırma yeniden kurulur, yedekler tek tek geri yüklenir. Kimin hangi adımı yapacağı o gece belirlenir. ERP, pazartesi öğleden sonra yeniden çalışır. Veri kaybı yoktur, ama iki iş günü kaybedilmiştir.
Felaket kurtarma planı olan firma
ERP ve etki alanı denetleyicisi, bir veri merkezindeki hedef sunucuya sürekli kopyalanmaktadır. Nöbetçi mühendis yazılı planı açar, yük devretmeyi başlatır; DNS kayıtları güncellenir. ERP, birkaç saat içinde yedek lokasyonda çalışır. Dosya sunucusu ise daha az kritik olduğu için pazartesi yedekten geri yüklenir. İki firma da aynı olayı yaşamıştır; fark, hazırlıktadır.
Hangi sisteme hangisi gerekir?
Her sistem için felaket kurtarma gerekmez. Soru, sistemin durmasının işe ne kadar sürede zarar verdiğidir. Orta ölçekli bir üretim firması için örnek bir dağılım:
- ERP ve üretim hattı yazılımı: Birkaç saatlik kesinti bile sevkiyatı durdurur. Yedeğin yanında, ikinci bir lokasyona replikasyon ve yazılı bir yük devretme planı gerekir.
- E-posta ve dosya sunucusu: Yarım günlük kesinti can sıkıcıdır ama yönetilebilir. İyi bir yedek ve yedekten hızlı başlatma çoğu zaman yeterlidir.
- Arşiv sunucusu ve test ortamları: Günlük yedek yeterlidir.
Bu ayrımı iş birimleriyle birlikte yapmak gerekir. Teknik hedeflerin iş tarafındaki karşılığını iş sürekliliği planı yazımızda anlattık.
Felaket kurtarma için seçenekler
- Yedekten hızlı başlatma: Yedek dosyası doğrudan sanal makine olarak açılır. StorageCraft ShadowProtect ve Veeam bu yöntemi sunar.
- İkinci lokasyona replikasyon: Kritik sunucular sürekli olarak ikinci bir hedefe kopyalanır. Gerçek zamanlı replikasyon için OpenText Availability (Carbonite) ile çalışıyoruz; hedef sunucu bir veri merkezinde durabilir.
- Buluta yük devretme: İkinci bir veri merkezi kurmak yerine sistemlerin bulutta ayağa kaldırılması. Kavramı DRaaS nedir? yazımızda anlattık.
Hangi yöntemi seçerseniz seçin, işe yarayıp yaramadığını yalnızca test gösterir. Nasıl yapılacağını felaket kurtarma testi yazımızda adım adım anlattık.
Nereden başlamalı?
İlk adım, en kritik üç sisteminizi seçip her biri için şu iki soruyu sormaktır: Bu sistemin yedeği var mı ve geri yüklendiği hiç denendi mi? Bu sistem yarın tamamen kaybolsa, kaç saat içinde, nerede ve kimin tarafından yeniden çalıştırılır? Birinci sorunun cevabı yedeklemenizi, ikincisininki felaket kurtarma hazırlığınızı gösterir.
- Önce dinleriz. Sistemlerinizi iş etkisine göre sıralar, mevcut yedekleme ve geri dönüş imkânlarınızı çıkarırız.
- Birlikte planlarız. Hangi sistemin yedekle, hangisinin replikasyonla korunacağını, maliyeti hedeflerle dengeleyerek belirleriz.
- Kurar ve yazılı hâle getiririz. Teknik altyapıyı kurar, felaket anında kimin neyi hangi sırayla yapacağını anlatan planı hazırlarız.
- Yanınızda kalırız. Geri yükleme ve yük devretme testlerini düzenli aralıklarla tekrarlar, sonuçları sizinle paylaşırız.
Kendi yapınızı birlikte değerlendirmek isterseniz bize ulaşabilirsiniz.
