Dijital operasyonların kesintisiz devam etmesi, artık yalnızca büyük kurumların değil her ölçekte işletmenin temel gereksinimlerinden biri. Tek bir sunucu arızası, yanlışlıkla silinen veri, fidye yazılımı saldırısı ya da bölgesel bir kesinti; satıştan muhasebeye, üretimden müşteri hizmetlerine kadar tüm süreçleri durdurabilir. Bu nedenle bulut yedekleme felaket kurtarma yaklaşımı, sadece BT ekiplerinin değil, iş sürekliliği planlaması yapan tüm şirketlerin gündeminde olmalıdır.
İyi hazırlanmış bir planın amacı yalnızca veriyi kopyalamak değildir. Asıl hedef; kritik sistemleri kabul edilebilir süre içinde yeniden ayağa kaldırmak, veri kaybını sınırlamak, yasal yükümlülüklere uyum sağlamak ve operasyonel riski kontrol altında tutmaktır. Bu yazıda, bulutta yedekleme ve felaket kurtarma planının nasıl oluşturulacağını; teknik terimlerden uygulama adımlarına, test süreçlerinden sık yapılan hatalara kadar somut bir çerçevede ele alıyoruz.
Bulut yedekleme ve felaket kurtarma ne anlama gelir?
Yedekleme ile felaket kurtarma çoğu zaman birlikte anılsa da aynı şey değildir. Bulut yedekleme, verilerin belirli aralıklarla bulut altyapısına kopyalanmasıdır. Amaç, veri kaybı yaşandığında geri dönüş yapabilmektir. Felaket kurtarma ise yalnızca veriyi değil; uygulamaları, sunucuları, ağ yapılarını ve iş süreçlerini tekrar çalışır hale getirmeyi kapsar.
Örneğin bir ERP veritabanının gece yedeğini almak, yedekleme stratejisidir. Ancak ana sistem devre dışı kaldığında ERP'yi alternatif ortamda ne kadar sürede ayağa kaldıracağınız, kullanıcıların hangi sırayla erişeceği, entegrasyonların nasıl toparlanacağı gibi konular felaket kurtarma planının parçasıdır.
Planlamaya başlamadan önce: kritik kavramlar
RPO ve RTO
Felaket kurtarma planının temelinde iki ölçüt yer alır:
- RPO (Recovery Point Objective): Kabul edilebilir veri kaybı süresidir. Örneğin RPO 15 dakika ise, en fazla son 15 dakikalık veri kaybı tolere edilir.
- RTO (Recovery Time Objective): Sistemin yeniden çalışır hale gelmesi için kabul edilebilir maksimum süredir. Örneğin RTO 2 saat ise, ilgili hizmetin iki saat içinde geri dönmesi gerekir.
Bu değerler teknik ekip tarafından tek başına belirlenmemelidir. Her uygulamanın iş üzerindeki etkisi farklıdır. E-ticaret altyapısı için 30 dakikalık kesinti kritik olabilirken, arşiv sistemleri için daha uzun süreler kabul edilebilir.
İş etki analizi
Sağlam bir plan, iş etki analizi ile başlar. Hangi sistem durursa hangi operasyon etkilenir, finansal veya operasyonel kaybın boyutu nedir, hangi servisler birbirine bağımlıdır; bunlar netleşmeden doğru yedekleme mimarisi kurulamaz.
Bulut yedekleme felaket kurtarma planı nasıl oluşturulur?
1. Kritik varlıkları envanterleyin
İlk adım, korunacak tüm dijital varlıkları listelemektir. Buna sadece veritabanları değil; uygulama sunucuları, dosya depoları, sanal makineler, konteyner ortamları, API entegrasyonları, kimlik doğrulama sistemleri ve ağ bileşenleri de dahildir.
Bu envanteri oluştururken şu sorulara yanıt verin:
- Hangi sistemler gelir üretimini doğrudan etkiliyor?
- Hangi veriler yasal olarak saklanmak zorunda?
- Hangi uygulamalar başka sistemlere bağımlı?
- Kesinti halinde manuel geçiş mümkün mü?
2. Sistemleri önceliklendirin
Tüm sistemler için aynı koruma düzeyi ekonomik veya gerekli değildir. Bu nedenle uygulamaları en az üç gruba ayırmak faydalıdır:
- Kritik: ERP, ödeme sistemleri, üretim planlama, müşteri portalı
- Önemli: raporlama, iç iletişim, destek araçları
- İkincil: arşiv, test ortamları, düşük öncelikli içerik sistemleri
Bu sınıflandırma, hangi sistemin ne sıklıkla yedekleneceğini ve hangi servis için sıcak, ılık veya soğuk kurtarma modeli kullanılacağını belirler.
3. Uygun yedekleme stratejisini seçin
Bulutta yedekleme stratejisi tasarlanırken veri türüne ve değişim sıklığına göre farklı yöntemler kullanılabilir:
- Tam yedek: Tüm verinin kopyalanması
- Artımlı yedek: Son yedekten sonra değişen verilerin alınması
- Diferansiyel yedek: Son tam yedekten beri değişen verilerin alınması
- Anlık görüntü (snapshot): Sunucu, disk veya veritabanı durumunun hızlı kopyası
- Replikasyon: Verinin ikinci bir bölgeye veya ortama yakın gerçek zamanlı aktarılması
Birçok işletme için tek yöntem yeterli olmaz. Örneğin veritabanı için sık snapshot ve replikasyon, belge arşivi için günlük artımlı yedek, uygulama konfigürasyonları için ise sürüm kontrollü altyapı yaklaşımı birlikte kullanılabilir.
4. 3-2-1 mantığını bulut ortamına uyarlayın
Yedeklemede yaygın kabul gören yaklaşım, verinin en az üç kopyasının bulunması; iki farklı ortamda saklanması ve en az bir kopyanın ana sistemden ayrı tutulmasıdır. Bulut senaryosunda bu prensip şöyle uygulanabilir:
- Üretim verisi ana ortamda
- Bulut yedekleme deposunda ikinci kopya
- Farklı bölge, farklı hesap veya değiştirilemez depolamada üçüncü kopya
Özellikle fidye yazılımı riskine karşı immutable backup yani silinemez/değiştirilemez yedekleme önemli bir katmandır.
5. Felaket kurtarma mimarisini belirleyin
Her iş yükü için aynı kurtarma modeli kullanılmaz. Yaygın seçenekler şunlardır:
- Cold standby: Gerektiğinde devreye alınan düşük maliyetli bekleme ortamı
- Warm standby: Kısmen hazır durumda tutulan, daha hızlı geri dönüş sağlayan ortam
- Hot standby: Neredeyse gerçek zamanlı eşlenmiş, yüksek erişilebilir yapı
Seçim yapılırken maliyet ile hedeflenen RTO/RPO dengelenmelidir. Her sistem için en pahalı mimariyi kurmak yerine, kritik hizmetlerde hızlı kurtarma; daha az kritik sistemlerde daha ekonomik modeller tercih edilmelidir.
6. Güvenlik ve erişim kontrolünü tasarlayın
Yedeklerin var olması tek başına yeterli değildir; güvenli olmaları da gerekir. Aksi halde yedekler de saldırı yüzeyi haline gelir. Bu nedenle:
- Veriler aktarım sırasında ve depoda şifrelenmelidir.
- Yedekleme yönetimi için çok faktörlü kimlik doğrulama kullanılmalıdır.
- Erişim yetkileri en az ayrıcalık prensibine göre sınırlandırılmalıdır.
- Yedekleme hesapları üretim hesaplarından ayrıştırılmalıdır.
- Günlükler izlenmeli, olağandışı silme veya erişim hareketleri uyarı üretmelidir.
Uyumluluk gereksinimleri olan sektörlerde, verinin hangi ülkede veya bölgede tutulduğu da ayrıca değerlendirilmelidir.
7. Kurtarma adımlarını dokümante edin
Bir kriz anında sözlü bilgiye güvenmek ciddi risk yaratır. Plan; rol ve sorumlulukları, iletişim zincirini, teknik kurtarma sırasını ve onay mekanizmalarını yazılı hale getirmelidir. Dokümantasyonda şu başlıklar yer almalıdır:
- Olay ilan kriterleri
- Sorumlu ekipler ve iletişim kişileri
- Sistem bazında geri yükleme sırası
- DNS, ağ, erişim ve entegrasyon adımları
- İş birimlerine bilgilendirme prosedürü
- Kurtarma sonrası doğrulama kontrol listesi
8. Planı düzenli olarak test edin
Test edilmeyen felaket kurtarma planı, gerçek bir kriz anında güvenilir kabul edilmemelidir. Testler sadece yedeğin alınabildiğini değil, gerçekten geri dönülebildiğini göstermelidir. Uygulanabilecek test türleri:
- Masa başı tatbikat: Senaryo üzerinden ekiplerin adımları gözden geçirmesi
- Teknik geri yükleme testi: Belirli veri setlerinin veya makinelerin restore edilmesi
- Failover testi: Alternatif ortama geçişin doğrulanması
- Tam kapsamlı tatbikat: Kritik süreçlerin uçtan uca denenmesi
Test sonuçları kayıt altına alınmalı; gerçekleşen RPO ve RTO süreleri hedeflerle karşılaştırılmalıdır.
Sık yapılan hatalar
Bulutta yedekleme ve felaket kurtarma projelerinde bazı hatalar tekrar eder:
- Yedek alınıyor diye kurtarmanın da sorunsuz olacağını varsaymak
- Tüm sistemleri aynı öncelikte değerlendirmek
- Sadece veriyi yedekleyip uygulama bağımlılıklarını göz ardı etmek
- Yedek hesaplarını üretim ortamıyla aynı erişim modeliyle yönetmek
- Maliyet optimizasyonu adına test süreçlerini ihmal etmek
- Dokümantasyonu güncel tutmamak
Özellikle modern yapılarda, konteyner orkestrasyonu, altyapı kodu, üçüncü taraf API'ler ve kimlik servisleri de kurtarma planına dahil edilmelidir. Aksi halde veri geri gelse bile uygulama yeniden çalışmayabilir.
Maliyet, performans ve risk dengesi nasıl kurulur?
İyi bir planın pahalı olması gerekmez; ancak risk profiline uygun olması gerekir. Maliyet optimizasyonu için yaşam döngüsü politikaları, arşiv depolama sınıfları, uygulama bazlı yedekleme sıklığı ve otomasyon birlikte düşünülmelidir. Öte yandan kritik sistemlerde yalnızca depolama maliyetine bakmak eksik bir değerlendirme olur. Kesintinin operasyonel bedeli çoğu zaman altyapı maliyetinden daha yüksektir.
Bu nedenle karar verirken şu denge kurulmalıdır: Hangi sistem için ne kadar veri kaybı kabul edilebilir, ne kadar sürede geri dönülmeli ve bunu sağlamak için minimum sürdürülebilir mimari nedir? Teknik olarak doğru çözüm, iş etkisiyle uyumlu çözümdür.
Sonuç
Bulut yedekleme felaket kurtarma planı, yalnızca BT altyapısının değil, iş sürekliliğinin sigortasıdır. Etkili bir yaklaşım; kritik sistemleri belirlemeyi, RPO ve RTO hedeflerini netleştirmeyi, güvenli yedekleme yöntemleri seçmeyi, gerçekçi kurtarma mimarisi kurmayı ve tüm planı düzenli test etmeyi gerektirir. İşletmeler için asıl soru, felaket yaşanıp yaşanmayacağı değil; yaşandığında ne kadar hazırlıklı olunacağıdır. Doğru tasarlanmış bir plan, kesinti süresini azaltır, veri kaybını sınırlar ve operasyonların kontrollü şekilde devam etmesini sağlar.
