- 013-2-1 yaklaşımı önemli verinin üç kopyasını, iki farklı ortam veya teknolojiyi ve bir ayrı konumu hedefler; modern ransomware riskinde offline veya immutable kopya güçlü bir ek kontroldür.
- 02Snapshot'ın yedek olup olmadığı adıyla değil arıza alanı, hesap ayrımı, silme koruması ve gerçek geri yükleme testleriyle değerlendirilmelidir.
- 03RPO verinin hangi zaman noktasına kadar geri döneceğini, RTO ise sistemin ne kadar sürede geri kazanılması gerektiğini tanımlar; ikisi de iş etkisi analiziyle belirlenmelidir.
- 04Restore testi ve felaket tatbikatı için evrensel aylık veya yıllık tek frekans yoktur; kritikliği, değişiklik hızını ve RPO/RTO hedeflerini temel alan risk temelli takvim kullanılmalıdır.
- 05CISA kritik yedeklerin offline, şifreli ve mümkün olduğunda immutable tutulmasını; kullanılabilirlik ve bütünlüğünün düzenli kurtarma testleriyle doğrulanmasını önerir.
Kısaca
3-2-1 yedekleme, tek bir disk veya bulut hatasına karşı değil, ortak arıza alanlarına karşı tasarlanır: önemli verinin üç kopyası, iki farklı ortam veya teknoloji ve bir kopyanın ayrı konumda tutulması. Fidye yazılımı riskinde bu temele offline veya immutable bir kopya ve düzenli geri dönüş testi ekleyin. Dynamis Teknoloji, Raff platformunu sıfırdan geliştiren ekip olarak yedeklemeyi dosya üretmek değil, ölçülmüş RPO/RTO hedeflerine göre geri dönebilmek olarak ele alır.
3-2-1 kuralı başlangıç noktasıdır
Geleneksel 3-2-1 yaklaşımı üç parçadan oluşur:
- 3 kopya: üretim verisi ve iki ek kopya
- 2 farklı ortam veya teknoloji: aynı tekil depolama arızasının tüm kopyaları etkilemesini önlemek
- 1 ayrı konum: ana ortamın erişilemez olduğu olaylara karşı bağımsız kurtarma noktası
CISA, 3-2-1 yaklaşımını ransomware rehberlerinde hâlâ öneriyor. Ancak modern tehdit modelinde kopya sayısı tek başına yeterli değildir. CISA ayrıca kritik yedeklerin offline tutulmasını, şifrelenmesini, immutable hale getirilmesini ve geri yükleme prosedürlerinin düzenli test edilmesini önerir.
Bu nedenle iyi bir tasarımda şu soruyu sorun: "Bu olay üretimi etkilediğinde hangi yedek aynı olaydan etkilenmeyecek?"
Aynı yönetici hesabıyla erişilen iki farklı depolama sistemi, kimlik bilgisi ele geçirildiğinde ortak arıza alanına dönüşebilir. Aynı bulut hesabındaki iki bucket farklı servisler olsa bile tek bir yetki hatası ikisini de silebiliyorsa gerçek bağımsızlık sınırlıdır.
Snapshot ile yedek aynı şey olmak zorunda değildir
"Snapshot yedek değildir" ifadesi fazla geneldir. Snapshot'ın yedek stratejisindeki değeri, nerede ve nasıl saklandığına bağlıdır.
Üretimle aynı hesapta ve aynı depolama kontrol düzleminde duran, silme koruması olmayan snapshot hızlı geri dönüş için değerlidir ancak felaket kurtarma açısından ortak risk taşır. Buna karşılık ayrı hesap veya konuma kopyalanan, silme koruması veya immutable özelliklerle tutulan snapshot yedek mimarisinin bir parçası olabilir.
Snapshot için şu dört kontrolü yapın:
- Üretim yöneticisi snapshot'ı silebiliyor mu?
- Snapshot farklı hesap veya arıza alanında mı?
- Saklama politikası otomatik mi?
- Snapshot'tan gerçek geri yükleme test edildi mi?
Dynamis'te snapshot'ı "hızlı geri dönüş katmanı", bağımsız yedeği ise "felaket kurtarma katmanı" olarak ayırıyoruz.
Fidye yazılımı için erişilebilirlik kadar değiştirilemezlik önemlidir
Fidye yazılımı yalnızca üretim verisini hedeflemez. CISA, saldırganların erişilebilir yedekleri silmeye veya şifrelemeye çalışabildiğini özellikle vurgular.
Bu nedenle en az bir kritik kopyayı aşağıdaki modellerden biriyle koruyun:
- Offline veya ağdan ayrılmış yedek
- Belirli süre değiştirilemeyen immutable/object-lock kopya
- Üretim kimliklerinden ayrı yetkilere sahip yedek hesabı
- Yedek silme işlemleri için ek onay veya ayrı yönetim hesabı
Immutable depolama da otomatik güvenlik sağlamaz. Yanlış saklama süresi maliyet yaratabilir, yanlış yetkilendirme ise korumayı zayıflatabilir. CISA da immutable bulut depolamasının dikkatli yapılandırılması gerektiğini belirtir.
RPO ve RTO yedekleme ürününden önce belirlenir
RPO ve RTO iki farklı soruyu yanıtlar.
RPO (Recovery Point Objective), kesinti sonrasında verinin hangi zaman noktasına kadar geri döndürülmesi gerektiğini tanımlar. Bir saatlik RPO, olay anından önceki en fazla yaklaşık bir saatlik değişikliğin kaybının iş açısından kabul edildiği anlamına gelir.
RTO (Recovery Time Objective) ise sistemin kurtarma sürecinde ne kadar süre kalabileceğini belirler. NIST, bu süreyi sistem bileşenlerinin kurtarma aşamasında kalmasının iş veya görev süreçlerini olumsuz etkilemeye başlayacağı sınır olarak tanımlar.
Hedefleri teknik ekip tek başına belirlememelidir. İş birimi, finans, operasyon ve teknik ekip birlikte iş etkisini değerlendirmelidir.
| Sistem | Örnek iş sorusu | RPO'yu etkileyen konu | RTO'yu etkileyen konu |
|---|---|---|---|
| Sipariş sistemi | Kaç dakikalık sipariş kaybı kabul edilebilir? | Replikasyon/yedek sıklığı | Hazır kurtarma ortamı |
| Dosya sunucusu | Son çalışma gününün dosyaları kaybolabilir mi? | Yedek sıklığı | Geri yükleme kapasitesi |
| Kimlik sistemi | Kullanıcılar ne kadar süre giriş yapamayabilir? | Yapılandırma/yedek | Kurtarma önceliği |
| İç wiki | Bir günlük değişiklik kaybı kabul edilir mi? | Günlük yedek | Daha uzun yeniden kurulum |
Düşük RPO ve düşük RTO farklı maliyet üretir. Düşük RPO daha sık veri kopyalama veya replikasyon ister. Düşük RTO ise hazır işlem kapasitesi, otomasyon ve önceden doğrulanmış kurtarma ortamı gerektirebilir.
Geri dönüş testi yedek dosyasını değil sistemi doğrular
Başarılı yedek işi, dosyanın oluşmasıyla bitmez. CISA kritik yedeklerin kullanılabilirliğinin ve bütünlüğünün felaket kurtarma senaryosunda düzenli test edilmesini önerir. NIST'in Haziran 2026 tarihli OT Backup Quick Start Guide'ı da yedeklerin düzenli oluşturulmasını, test edilmesini ve kurtarma tatbikatlarında gözden geçirilmesini temel pratikler arasında sayar.
Gerçek bir geri dönüş testinde en az şu adımları ölçün:
- Doğru yedek noktası seçilebiliyor mu?
- Veri ayrı bir kurtarma ortamına geri yüklenebiliyor mu?
- Uygulama veya servis geri yüklenen veriyle çalışıyor mu?
- Yetki, şifreleme anahtarı ve sertifika bağımlılıkları mevcut mu?
- Ölçülen geri dönüş süresi RTO hedefinin içinde mi?
- Kurtarılan veri RPO hedefini karşılıyor mu?
Checksum veya "backup job successful" mesajı yararlıdır ama gerçek geri yükleme testinin yerine geçmez.
Test sıklığını risk ve değişiklik hızı belirler
Tüm kuruluşlar için "ayda bir restore" veya "yılda bir felaket tatbikatı" şeklinde tek bir evrensel sıklık yoktur. NIST ve CISA düzenli test ve tatbikat ister; takvim organizasyonun iş etkisi, değişiklik sıklığı ve riskine göre belirlenir.
Pratik bir sınıflandırma şöyle kurulabilir:
| Sistem sınıfı | Test yaklaşımı |
|---|---|
| Gelir veya kritik müşteri hizmeti | Daha sık otomatik/manuel restore testi ve düzenli tam senaryo tatbikatı |
| Kritik iç operasyon | Planlı restore testi ve bağımlılık doğrulaması |
| Düşük etkili iç sistem | Daha seyrek ancak gerçek geri yükleme içeren test |
| Büyük değişiklik geçiren sistem | Takvim beklenmeden değişiklik sonrası test |
Önemli olan frekansın belgelenmesi ve nedeninin bilinmesidir. Kritik sistem üç ayda bir test ediliyorsa bunun RPO/RTO ve risk analiziyle uyumlu olduğunu gösterebilmelisiniz.
Felaket kurtarma planı sistem bağımlılıklarını içerir
Yalnızca "veritabanını geri yükle" yazan belge felaket kurtarma planı değildir. NIST contingency planning yaklaşımı iş etkisi analizi, kurtarma stratejisi, test, eğitim ve plan bakımını tek süreç olarak ele alır.
Planın en az şu alanları içermesi gerekir:
- Kritik sistem ve servis önceliği
- Sistem bağımlılıkları
- RPO ve RTO hedefleri
- Yedek ve kurtarma konumları
- Erişim ve şifreleme anahtarı prosedürü
- Kurtarma sorumluları
- İletişim ve eskalasyon
- Geri dönüş sonrası uygulama ve veri doğrulaması
- Normal ortama dönüş veya failback prosedürü
Kimlik sistemi, DNS veya ağ katmanı çalışmadan uygulama sunucusunu geri yüklemek işe yaramayabilir. Kurtarma sırası uygulama isimlerine değil bağımlılık grafiğine göre kurulmalıdır.
Sıcak, ılık veya soğuk kurtarma modeli RTO'ya göre seçilir
Ayrı bir felaket kurtarma ortamı her sistem için gerekli değildir. NIST, kurtarma yönteminin olay türüne, sistem etkisine ve operasyonel gereksinimlere göre seçilmesini önerir.
Sıcak ortam: işlem kapasitesi ve veri replikasyonu hazırdır. Düşük RTO gereken sistemlerde değerlendirilir.
Ilık ortam: temel altyapı hazırdır ancak bazı servis veya veriler kurtarma anında devreye alınır.
Soğuk ortam: yedek ve yeniden kurulum planı vardır; altyapı olay sonrasında hazırlanır. Daha uzun RTO kabul eden sistemler için daha düşük maliyetli olabilir.
Seçimi tek bir "RTO bir saatin altındaysa sıcak site gerekir" kuralına bağlamayın. Uygulama otomasyonu, veri hacmi, replikasyon yöntemi ve hedef kapasite sonucu değiştirebilir.
KVKK kapsamındaki yedeklerde saklama ve imha ayrı planlanır
Kişisel veri içeren yedekler de veri envanterinin parçasıdır. Ancak "yedek en fazla altı ay tutulabilir" şeklinde genel bir KVKK kuralı yoktur.
Saklama süresi işleme amacı ve hukuki gerekliliklere göre belirlenir. İşleme şartı ortadan kalktığında veri silme, yok etme veya anonim hale getirme sürecine girer. Periyodik imha aralığının azami altı ay olması, her yedeğin altı ay sonra zorunlu olarak silineceği anlamına gelmez.
Eski yedeği geri yüklediğinizde daha önce imha edilmiş kişisel verinin yeniden aktif sisteme dönme ihtimalini de prosedüre ekleyin. Ayrıntılı çerçeve için KVKK uyumlu bulut altyapısı rehberini kullanın.
Yedekleme planını operasyon modeline bağlayın
Yedekleme ve felaket kurtarma kararları üretim işletim modelinden ayrı tutulmamalıdır. Uygulama sahibi, altyapı ekibi ve iş birimi; RPO/RTO, kopya bağımsızlığı, saklama, restore testi ve runbook sorumluluğunu aynı planda tanımlamalıdır.
Operasyon planında en az şu soruların yanıtı bulunmalıdır:
- Hangi sistem hangi RPO ve RTO sınıfında?
- Kritik kopya üretim hesabından gerçekten bağımsız mı?
- Saklama ve imha politikası kim tarafından yönetiliyor?
- Restore testini kim, hangi sıklıkta ve hangi kabul kriterleriyle çalıştırıyor?
- Kurtarma runbook'unun sahibi kim?
- Tatbikat sonrası aksiyonlar nasıl takip ediliyor?
Raff üzerindeki snapshot veya yedek özelliklerini kullanırken de aynı ayrımı uygulayın: platform özelliğinin adı değil, hangi arıza alanından bağımsız olduğu ve gerçekten geri dönüp dönemediği önemlidir.
Bu sorumlulukları içeride sürekli işletmek istemiyorsanız yönetilen cloud operasyonu ve kurtarma planını ayrı bir operasyon modeli olarak değerlendirin.
Sık yapılan hatalar
Aynı hesapta üç kopya tutup 3-2-1 uyguladığını sanmak: Kopya sayısı yüksek olabilir ama aynı yetki hatası hepsini silebilir.
Snapshot'ı otomatik olarak yedek veya yedek dışı saymak: Snapshot'ın nerede, hangi yetkiyle ve hangi silme korumasıyla tutulduğu belirleyicidir.
Backup job başarı mesajını restore testi sanmak: İşin tamamlandığı değil, uygulamanın geri dönebildiği test edilmelidir.
RPO ile RTO'yu karıştırmak: RPO veri kaybı zaman noktasını, RTO hizmetin geri kazanım süresini yönetir.
Tatbikat frekansını kopyalamak: Başka şirketin aylık veya yıllık takvimi sizin riskinizi tanımlamaz. Kendi iş etkisi ve değişiklik hızınıza göre yazın.
Yedek yönetimini üretim kimliğiyle yapmak: Fidye yazılımı veya hesap ele geçirilmesi durumunda yedekler de aynı yetki alanında kalır.
Sırada ne var
- Broadcom sonrası VMware: lisanslama ve çıkış planı: VMware migration öncesinde geri dönüş yolunu ve bağımsız yedek stratejisini planlayın.
- Özel bulut mu, genel bulut mu? KVKK açısından karar: yedek ve felaket kurtarma kopyalarının hangi cloud modelinde tutulacağını KVKK açısından değerlendirin.
- KVKK uyumlu yedekleme: saklama süresi ve imha: backup retention ile kişisel veri saklama/imha sürelerini aynı politikada eşleştirin.
- Disaster Recovery nedir? Şirketler için felaket kurtarma planı: 3-2-1 yedekleme katmanını iş etkisi, RPO/RTO, recovery tier ve failback planına bağlayın.
- Bulut yedekleme fiyatları: maliyet nasıl hesaplanır?: kopya sayısı, saklama süresi ve geri yükleme hedefinin toplam maliyeti nasıl değiştirdiğini hesaplayın.
- Yedek geri yükleme testi: aylık restore planı: 3-2-1 mimarisini gerçek RPO/RTO ölçümü ve uygulama doğrulamasıyla test edin.
- KVKK uyumlu bulut altyapısı: kişisel veri içeren yedeklerde saklama, aktarım ve imha kurallarını planlayın.
- AWS'den çıkış: maliyeti düşüren bulut göçü: migration sırasında geri dönüş yolunu ve eski ortamı nasıl koruyacağınızı görün.
- Kendi DevOps ekibini kurmak mı, yönetilen hizmet mi: yedek ve kurtarma operasyonunun kimde kalacağını belirleyin.
- Yönetilen cloud operasyonu ve kurtarma planı: yedekleme, restore testi ve sorumluluk modelini birlikte değerlendirin.
Kaynaklar
Kaynaklar
- 1.CISA #StopRansomware GuideCybersecurity and Infrastructure Security Agency · 2026-09-19
- 2.Understanding Ransomware Threat Actors: LockBitCybersecurity and Infrastructure Security Agency · 2026-09-19
- 3.NIST SP 1339 OT Backup Quick Start GuideNational Institute of Standards and Technology · 2026-09-19
- 4.NIST SP 800-34 Rev. 1 Contingency Planning GuideNational Institute of Standards and Technology · 2026-09-19
- 5.Recovery Point ObjectiveNIST CSRC · 2026-09-19
- 6.Recovery Time ObjectiveNIST CSRC · 2026-09-19
Sık sorulan sorular
Yedeğim var, yine de risk altında mıyım?
Evet. Yedeğin geri yüklenebildiği doğrulanmamışsa, üretimle aynı kimlik veya arıza alanına bağlıysa ya da fidye yazılımının erişebildiği şekilde çevrimiçiyse kurtarma riski devam eder. Test sıklığını sistemin kritikliği ve RPO/RTO hedeflerine göre belirleyin.
RPO ve RTO nedir?
RPO, kesinti sonrasında verinin hangi zaman noktasına kadar geri döndürülmesi gerektiğini ifade eder. RTO ise sistemin iş süreçlerini olumsuz etkilemeden ne kadar sürede geri kazanılması gerektiğini tanımlar. Hedefler iş etkisi analiziyle belirlenmelidir.
3-2-1 yedekleme kuralı nedir?
Geleneksel 3-2-1 yaklaşımı önemli verinin üç kopyasını tutmayı, kopyaları iki farklı ortam veya teknoloji üzerinde saklamayı ve bir kopyayı ayrı bir konumda bulundurmayı önerir. Fidye yazılımına karşı en az bir kopyanın offline veya immutable olması da güçlü bir ek kontroldür.
Geri dönüş testi ne sıklıkla yapılmalı?
Tek bir evrensel sıklık yoktur. Kritik sistemlerde daha sık, düşük etkili sistemlerde daha seyrek test yapılabilir. Takvim; RPO/RTO, değişiklik sıklığı, iş etkisi ve risk değerlendirmesine göre belirlenmeli; test gerçek geri yükleme ve uygulama doğrulamasını içermelidir.
Snapshot yedek yerine geçer mi?
Tek başına her zaman geçmez. Üretimle aynı hesap, depolama veya arıza alanındaki snapshot hızlı geri dönüş sağlar ancak aynı olaydan etkilenebilir. Ayrı hesap veya konumda, silme koruması ve uygun saklama politikasıyla korunan snapshot ise yedek stratejisinin bir parçası olabilir.
Hangi durumda felaket kurtarma ortamı gerekir?
RTO ve RPO hedefleri yalnızca yedekten yeniden kurulumla karşılanamıyorsa ayrı bir kurtarma ortamı değerlendirilmelidir. Sıcak, ılık veya soğuk kurtarma modeli; iş etkisi, bağımlılıklar, veri replikasyonu ve kabul edilebilir maliyete göre seçilir.