Yedekleme, felaket kurtarma ve iş sürekliliği nasıl birlikte yönetilir?

Yedek, sistem ve iş hizmeti farklı kurtarma katmanlarıdır

Bir dosyanın yedeği olması uygulamanın çalışacağı, uygulamanın ayağa kalkması da müşteriye hizmet verileceği anlamına gelmez. NIST SP 800-34, bilgi sistemi contingency planning’i veri, sistem ve operasyonların kesinti sonrası toparlanmasını sağlayan koordineli strateji olarak ele alır. İş sürekliliği daha geniştir; insan, tesis, tedarikçi, iletişim ve manuel alternatifleri de kapsar.

İş etki analizi teknoloji listesinden önce gelmelidir

BIA, hangi iş sürecinin ne kadar kesintiye dayanabildiğini, bağımlılıklarını ve kesintinin finansal, hukuki, operasyonel ve itibari etkisini belirler. Aynı uygulama bir ekip için düşük, başka bir kritik süreç için yüksek öncelikli olabilir. Süreç sahibi, teknoloji sahibi ve risk ekipleri ortak değerlendirme yapmalıdır.

• Kritik ürün ve hizmetler
• Müşteri ve zorunlu bildirim etkileri
• İnsan, tesis ve tedarikçi bağımlılıkları
• Uygulama, veri ve entegrasyon zinciri
• Günün veya dönemin kritik zamanları
• Manuel çalışmanın mümkün olduğu süre
• İzin verilen veri kaybı ve işlem tekrar yükü
• Kesinti büyüdükçe değişen etki eşikleri

BIA yılda bir doldurulan tablo olarak kalmamalı; yeni ürün, birleşme, tedarikçi ve mimari değişikliklerinde güncellenmelidir.

RTO ve RPO teknik ekip tarafından tek başına seçilemez

RTO, kesinti sonrası hizmetin kabul edilebilir düzeyde ne kadar sürede geri dönmesi gerektiğini; RPO, kabul edilebilecek veri kaybı penceresini ifade eder. MTPD veya maksimum tolere edilebilir kesinti süresi, iş etkisinin kabul edilemez hâle geldiği üst sınırı gösterir. Bu hedefler maliyetlidir; “sıfır veri kaybı ve sıfır kesinti” varsayımı gerçekçi olmayabilir.

Yedekleme kopya sayısından çok bağımsızlık ve geri yüklenebilirlik meselesidir

Yedek stratejisi veri türü, değişim hızı, RPO, saklama, mevzuat ve saldırı modeline göre tasarlanır. Aynı kimlik sistemiyle erişilen çevrim içi kopyalar fidye yazılımı veya yönetici hesabı ele geçirildiğinde birlikte silinebilir. Değiştirilemez, çevrim dışı veya ayrı güven alanındaki kopyalar ve yedek yönetim hesaplarının ayrılması önemlidir.

1. Yedeklenecek veri, sistem durumu, yapılandırma ve anahtarları envanterleyin.
2. RPO’ya göre tam, artımlı, sürekli veya snapshot modelini seçin.
3. Üretim kimliklerinden ayrılmış yedek erişimi kurun.
4. Değiştirilemez veya çevrim dışı kopya sağlayın.
5. Şifreleme anahtarlarının kurtarılabilirliğini test edin.
6. Geri yükleme işlemini farklı örneklerle düzenli deneyin.
7. Yedek başarısını dosya varlığıyla değil kullanılabilir geri yüklemeyle ölçün.

NIST’in 2026 OT Backup Quick Start Guide’ı da yedeklerin düzenli oluşturulması, değişiklik yönetimine bağlanması, test edilmesi ve kurtarma tatbikatlarında gözden geçirilmesini vurgular.

Felaket kurtarma planı bağımlılık sırasını ve karar adımlarını göstermelidir

DR planı yalnız sunucu açma komutları değildir. Kimlik, DNS, ağ, anahtar, veritabanı, mesajlaşma, entegrasyon, uygulama ve izleme bağımlılıklarının doğru sırada kurtarılması gerekir. Runbook; tetikleme ölçütü, sorumlu, ön koşul, adım, doğrulama, geri dönüş ve eskalasyon bilgilerini içermelidir.

DR mimarisi, test edilmeyen standby sistem veya yalnız sağlayıcı SLA’sına dayanıyorsa kanıtlı sayılmaz.

İş sürekliliği teknoloji dönmeden önce asgari hizmeti sürdürür

İş sürekliliği planı; kritik rol yedekleri, alternatif iletişim, manuel işlem, geçici müşteri hizmeti, tesis erişimi, tedarikçi alternatifleri ve karar yetkilerini kapsar. Bazı süreçler kısmi hizmetle sürdürülebilir; bazıları güvenlik veya veri bütünlüğü nedeniyle durdurulmalıdır. “Her koşulda çalışmaya devam” hedefi doğru değildir.

• Asgari kabul edilebilir hizmet seviyesi
• Alternatif çalışma yeri ve iletişim kanalı
• Kritik personel ve vekâlet planı
• Manuel kayıt ve sonradan mutabakat süreci
• Müşteri, çalışan, düzenleyici ve tedarikçi mesajları
• Nakit, ödeme ve yetki sürekliliği
• Geçici işlemlerin güvenlik ve veri koruma sınırları
• Normal operasyona dönüş ve birikmiş iş yönetimi

Planlar masa başı, teknik geri yükleme ve tam tatbikatla ayrı ayrı sınanmalıdır

Belge incelemesi planın güncel olup olmadığını; masa başı tatbikat karar ve iletişim boşluklarını; teknik test yedek ve runbook işlevini; kapsamlı tatbikat ise insan, teknoloji ve tedarikçilerin birlikte çalışmasını gösterir. Her testin amacı, başarı ölçütü, kapsam dışı alanı ve düzeltme sahibi bulunmalıdır.

Senaryo: fidye yazılımı üretim ve yedek yönetimini etkiliyor

Üretim kimlikleriyle yönetilen çevrim içi yedekler de şifrelenmişse yalnız “yedek alıyoruz” kontrolü başarısız olur. Olay ekibi etkilenen kimlikleri izole eder; değiştirilemez kopyanın bütünlüğünü doğrular; temiz kurtarma ortamını kurar; kritik hizmetleri BIA sırasına göre döndürür. İş sürekliliği ekibi müşteriye geçici kanal ve manuel işlem sunar. Geri yüklenen sistemler açılmadan önce kök neden, güvenlik düzeltmesi ve kimlik yenilemesi tamamlanır.

1. Olayı sınırlayın ve yedek ortamını koruyun.
2. Temiz kimlik ve yönetim düzlemi oluşturun.
3. Kritik veri setinin bütünlüğünü doğrulayın.
4. Minimum hizmeti alternatif süreçle sürdürün.
5. Sistemleri bağımlılık sırasıyla kurtarın.
6. Mutabakat ve veri kaybı penceresini yönetime raporlayın.
7. Normalleşme sonrası test ve kök neden aksiyonlarını kapatın.

Yönetim, yedek başarı oranından daha fazlasını görmelidir

• RTO/RPO hedefi onaylı kritik süreç oranı
• Başarılı ve süre içinde tamamlanan geri yükleme oranı
• Değiştirilemez/ayrı güven alanındaki yedek kapsamı
• Son tatbikatta ölçülen gerçek kurtarma süresi
• Runbook ve iletişim bilgilerinin güncelliği
• Kritik tedarikçilerin kanıtlı süreklilik kapasitesi
• Açık tatbikat bulgularının yaşı
• Manuel alternatifin kapasitesi ve güvenlik sınırları

Bir planın varlığı değil, hedef süre içinde güvenli ve doğrulanmış hizmet sunma kapasitesi ölçülmelidir.