Yedek aldınız ama felaket anında neden ayağa kalkamıyorsunuz?

Yedeklerin dosya düzeyinde sağlam olması, uygulama sunucularının, veritabanı bağımlılıklarının ve network konfigürasyonlarının sıfırdan kurulumunu gerektirir. Elazığ’da faaliyet gösteren bir lojistik firmasında, günlük yedek alınmasına rağmen bir ransomware saldırısı sonrası sistemlerin yeniden ayağa kalkması üç iş günü sürdü. Kritik olan, kurtarma senaryosunun işletim sistemi seviyesinden uygulama katmanına kadar adım adım tanımlanmış ve test edilmiş olmasıdır.

Felaket kurtarma ihtiyacınızı konuşalım: Plan ne zaman devreye girer?

Her felaket türü farklı bir tetikleyiciye ve yanıt süresine sahiptir. Örneğin bir deprem senaryosunda fiziksel sunucuların kullanılamaz hale gelmesi 5 dakika içinde planı devreye sokarken, yazılım hatasında önce izleme alarmı sonrasında manuel onay alınır. Bu tetikleyicilerin net tanımlanmaması durumunda planın hangi durumda aktif olduğu belirsizleşir ve kurtarma süresi uzar. Somut adımlar: izleme sistemi, alarm eşik değerleri ve karar ağacı.

RTO ve RPO rakamlarını hangi kriterlere göre belirliyorsunuz?

RTO (kurtarma süresi hedefi) iş süreçlerinin kesintiye dayanma sınırına, RPO (veri kaybı toleransı) ise her dakika kaybedilen gelire göre belirlenir. Örneğin bir e-ticaret sitesinde 1 saatlik kesinti 50 bin TL kayba yol açıyorsa RTO 30 dakika, RPO 5 dakika olarak konulur. Bu rakamları belirlerken yedekleme altyapısının bant genişliği, depolama hızı ve replikasyon aralığı gibi teknik kısıtlar da hesaplanmalıdır. İşletme bütçesi ve risk iştahı arasındaki denge, net RTO/RPO’yu ortaya çıkarır.

Hangi felaket senaryoları masaya yatırılıyor ve öncelik sırası nasıl belirleniyor?

En sık karşılaşılan senaryolar sırasıyla: donanım arızası, insan hatası (yanlışlıkla silme), siber saldırı (ransomware), doğal afet (deprem, sel) ve yazılım hatalarıdır. Her senaryo için ayrı bir kurtarma playbook’u oluşturulur; örneğin Elazığ’daki bir hastane için deprem senaryosu ikinci sırada yer alır. Öncelik sırası, senaryonun gerçekleşme olasılığı ve etki büyüklüğüne göre bir matris kullanılarak belirlenir. Bu matris sayesinde kaynaklar en kritik duruma yönlendirilir.

Felaket kurtarma planınızın çalıştığını nereden biliyorsunuz?

Planın çalıştığı, yalnızca yedekten veri geri getirilerek değil, tüm iş süreçlerinin tam işlevsellikle çalıştığı kapsamlı testlerle doğrulanır. Bu testlerde montaj hattı, ERP erişimi, e-posta sunucusu gibi kritik uygulamalar baştan sona çalıştırılır ve performans metrikleri ölçülür. Örneğin Veeam’in SureBackup özelliği, sanal makinelerin uygulama düzeyinde doğrulamasını otomatik yapar. Testler haftalık yapılmalı ve her test sonucu dokümante edilerek iyileştirme fırsatları belirlenmelidir.

Felaket durumunda kurtarma işlemi hangi sırayla gerçekleştirilir?

Standart bir kurtarma akışı: önce altyapı katmanı (network, sanallaştırma), ardından veritabanı ve uygulama sunucuları, son olarak kullanıcı erişim ve güvenlik politikaları devreye alınır. Bu sıralama bağımlılıkları azaltır; örneğin veritabanı olmadan uygulama ayaklanamaz. Kurtarma işlemi için bir runbook hazırlanır, her adımın tahmini süresi ve sorumlusu belirtilir. Elazığ’daki bir üretim tesisinde, bu sıralama sayesinde sistemler 4 saat içinde tam verimle çalışır hale geldi.

Felaket kurtarma altyapısında hangi teknolojiler ve markalar öne çıkıyor?

Kurumsal düzeyde Veeam Backup & Replication, Zerto, Azure Site Recovery ve VMware SRM sık kullanılan araçlardır. Bu araçlar, sürekli replikasyon, otomatik failover ve uygulama bilinçli kurtarma gibi özellikler sunar. Depolama tarafında Dell EMC PowerProtect, NetApp SnapMirror ve HPE StoreOnce gibi donanımlar tercih edilir. Maliyet ve ölçeklenebilirlik açısından bulut tabanlı çözümler (AWS Disaster Recovery, Azure Backup) esnek bir seçenek sağlar.

Planınızı test ederken hangi sıklıkta ve hangi kapsamda test yapmalısınız?

Kritik sistemler için aylık kapsamlı test, tüm sistemler için üç ayda bir test yeterli bir döngüdür. Test kapsamı; tam failover, parçalı kurtarma, veri bütünlüğü ve performans testlerini içermelidir. Test sırasında canlı veri kullanılacaksa, yedek kopya üzerinde çalışılmalı ve üretime müdahale edilmemelidir. Her test sonrası kurtarma süreleri kaydedilir, sapmalar analiz edilir ve plan güncellenir.

Bu konuda yazdıklarımız: Felaket kurtarma planlaması hakkında nereden faydalanabilirsiniz?

Blog sitemizde felaket kurtarma planı oluşturma adımları, vaka analizleri ve araç karşılaştırmaları yayınlanmaktadır. Örneğin “Elazığ’daki bir KOBİ’nin felaket kurtarma testi sonuçları” başlıklı makalede gerçek verilerle RTO sapmaları incelenmiştir. Ayrıca “RTO hesaplama formülü” rehberi, kendi işletmenize özgü rakamları çıkarmanıza yardımcı olur. Tüm yazılara web sitemizdeki Blog bölümünden ulaşabilirsiniz.

Sıkça Sorulan Sorular

Yedekleme ile felaket kurtarma arasındaki temel fark nedir?
Yedekleme, verinin bir kopyasını depolama işlemidir; felaket kurtarma ise verinin yanı sıra uygulama, sunucu ve ağ altyapısının yeniden çalışır hale getirilmesini kapsar. Örneğin yedekleriniz sağlam olsa bile sunucu yanıt vermiyorsa, iş süreçleriniz durur. Kurtarma planı, tüm bu bileşenlerin koordineli bir şekilde ayağa kalkmasını sağlar.
Felaket kurtarma planını test etmezsem ne olur?
Test edilmemiş bir plan, gerçek felaket durumunda büyük olasılıkla başarısız olur. Bir testte fark edilmeyen bir konfigürasyon hatası, kurtarma süresini saatlerce uzatabilir. Örneğin Azure Site Recovery replikasyonunda boyut sınırını aşan bir disk, failover sırasında hataya yol açar. Bu nedenle periyodik testler, planın güvenilirliğini garanti altına alır.
RTO hedefimi belirlerken hangi maliyet faktörlerini dikkate almalıyım?
RTO ne kadar kısa olursa, altyapı yatırımı o kadar yüksek olur: daha hızlı depolama, daha geniş bant, otomatik failover sistemleri gerekir. Bunun karşılığında kesinti süresi başına kaybettiğiniz gelir ve müşteri güveni kaybı hesaplanmalıdır. Genel olarak RTO 4 saatin altına indikçe maliyet katlanarak artar, bu yüzden işletme büyüklüğünüze uygun bir denge bulmak önemlidir.
Felaket kurtarma planımda hangi senaryoları önceliklendirmeliyim?
Öncelik sırası, işletmenizin karşılaşma olasılığı en yüksek ve en yıkıcı senaryolara göre belirlenir. Örneğin bir üretim şirketi için donanım arızası ve elektrik kesintisi ön plandayken, bir hukuk bürosu için siber saldırı ve veri ihlali daha kritiktir. Risk değerlendirmesi yaparak her senaryonun olasılık ve etki puanını çıkarın, en yüksek puana sahip senaryoları önce ele alın.
Bulutta yedek alıyorum, ayrıca bir felaket kurtarma planına ihtiyacım var mı?
Evet, bulut yedekleme sadece veri kopyasını tutar; bulut hizmet sağlayıcınızdaki bir kesinti veya yanlış yapılandırma sonucu erişim kaybı yaşayabilirsiniz. Ayrıca buluta yedeklenen verinin bozulup bozulmadığını düzenli test etmezseniz, kurtarma anında dosyaların kullanılamadığını görebilirsiniz. Bu nedenle bulut yedeğinizi de kapsayan bir felaket kurtarma planı oluşturmanız gerekir.
Felaket kurtarma maliyeti bütçemi aşar mı, nasıl optimize edilir?
Maliyet, seçtiğiniz RTO/RPO değerlerine ve altyapı modeline bağlıdır. Hibrit yaklaşımla kritik veriler için hot site, diğer veriler için cold cloud depolama kullanarak maliyeti düşürebilirsiniz. Örneğin yılda bir test planı düşük maliyetliyken, ayda bir test yapmak kaynak gerektirir. Ayrıca pay-per-use bulut hizmetleri sayesinde felaket anına kadar sadece depolama ücreti ödersiniz, böylece sabit maliyetler azalır.