3-2-1 Yedek Kuralı: Veri Kaybına Karşı Altın Standart (SVG İnfografik)

Hızlı Cevap

• Klasik kural: 3 kopya veri, 2 farklı medya türü, 1 kopya tesis dışında (off-site) tutulur; tüm modern stratejilerin temelidir.
• Modern 3-2-1-1-0 versiyonu ek olarak 1 değişmez (immutable veya air-gapped) kopya ve 0 hata içeren restore testi şartını getirir.
• Immutable yedek, fidye yazılımının şifreleyemediği WORM veya object-lock korumalı depolama anlamına gelir, ransomware'e karşı kritik katmandır.
• Restore testi yapılmayan yedek geçerli sayılmaz; en az çeyrekte bir tam geri yükleme tatbikatı önerilir.
• 3-2-1 uygulayan kurumlar ransomware sonrası ortalama 24 saatte toparlanırken, uygulamayanlarda iyileşme süresi 2-4 haftaya uzar.

Veri kurtarma laboratuvarına gelen müşterilerin çoğunluğu aynı cümleyi söylüyor: "Yedeğim vardı ama..." O "ama" kelimesinin arkasında genelde aynı hikayeler var. Yedek aynı bilgisayardaydı, fidye yazılımı onu da şifreledi. Yedek harici diskteydi, disk yastığın altında düştü. Yedek NAS'taydı, kullanıcı yanlışlıkla NAS klasörünü silince yedek de gitti. Yedek vardı ama restore yapmayı kimse denememişti, dosyalar bozuk çıktı.

Bu yazıların hepsinin tek bir ortak özelliği var: 3-2-1 yedek kuralını ihlal ediyorlar. Bu yazıda 3-2-1 kuralının orijinal hali, modern 3-2-1-1-0 uzantısı, immutable backup mantığı ve KOBİ ile bireysel kullanıcılar için pratik uygulama yollarını ele alıyoruz. Yazıda ayrıca 600px x 400px boyutunda inline SVG infografik var; ekran kartından çıktıya kadar her ölçekte net kalır.

3-2-1 Yedek Kuralı Nedir

3-2-1 yedek kuralı ilk olarak 2005 civarında ABD'li fotoğrafçı Peter Krogh tarafından dijital varlık yönetimi için formüle edildi, daha sonra CISA (US-CERT) ve Veeam gibi kurumlar tarafından kurumsal veri koruma standardı olarak benimsendi. Kural çok basit üç bileşenden oluşuyor.

3 kopya: Verinin toplam 3 kopyası bulunmalı. Bu, 1 üretim verisi artı 2 yedek demektir. Tek başına yedek almak yetmez; iki bağımsız yedek daha güvenli bir geri dönüş alanı yaratır.

2 farklı medya: Yedekler iki farklı depolama tipinde tutulmalı. Aynı marka ve model iki SSD aynı medya sayılır; üretim hatası ya da firmware bug'ı her ikisini de aynı anda etkileyebilir. Doğru kombinasyon HDD ve SSD, ya da yerel disk ve cloud bucket olabilir. NAS ve teyp de klasik bir karışımdır.

1 offsite kopya: En az bir yedek fiziksel olarak farklı bir konumda tutulmalı. Ofis yangını, su baskını, hırsızlık ve fidye yazılımı senaryolarında offsite kopya hayat kurtarır. Cloud bucket modern karşılığı, banka kasası klasik karşılığıdır.

CISA'nın resmi rehberi (cisa.gov/news-events/news/data-backup-options) bu üç bileşeni bireysel ve kurumsal kullanıcılar için temel yedekleme standardı olarak öneriyor. NIST SP 800-34 Contingency Planning Guide for Federal Information Systems dokümanı da yedek dağıtımını birden fazla coğrafi konuma yaymayı zorunlu kılıyor.

SVG İnfografik: 3-2-1 Kuralı Görsel Anlatım

Aşağıdaki infografik 3-2-1 kuralını tek bakışta anlatıyor. DSET kırmızısı (#FF0027) ana vurgu rengi olarak kullanılmıştır.

İnfografikteki üç kutu sırasıyla "3 kopya, 2 farklı medya, 1 offsite" mesajını veriyor. Alt bölüm 3-2-1-1-0 uzantısını özetliyor.

3-2-1-1-0 Modern Uzantısı: Veeam Yorumu

Klasik 3-2-1 kuralı 2005 yılında doğdu, o zaman fidye yazılımı bugünkü ölçeğinde değildi. Veeam 2020'den itibaren resmi dokümantasyonunda (veeam.com) kuralı 3-2-1-1-0 olarak güncelledi. Eklenen iki rakam günümüz tehdit ortamına yanıt veriyor.

+1 immutable kopya: Yedeklerden en az birinin değiştirilemez (immutable) olması gerekir. Saldırgan domain admin yetkisi alsa bile bu yedeği silemez, şifreleyemez ya da değiştiremez. Pratikte bu, AWS S3 Object Lock, Azure Blob immutable storage, Backblaze B2 Object Lock, ya da teyp kütüphanesi (air-gapped) ile sağlanır.

+0 hata: Yedeklerin restore testinin başarılı geçmiş olması gerekir. Hata kodu = 0, yani yedek dosyaları bütünlük doğrulamasını ve gerçek restore denemesini başarıyla geçmiş demektir. Yedek dosyası diskte duruyor ama açılmıyorsa, yedek diye bir şey yok.

Veeam'in 2024 Data Protection Trends raporundaki saha bulguları (rapor metni kendi sitelerinde yayımlandı) restore başarısız olma vakalarının yedek varlığını anlamsızlaştırdığını gösteriyor. Bizim laboratuvarımıza gelen kurumsal vakaların yaklaşık üçte birinde "yedek var ama restore çalışmıyor" tablosu çıkıyor; sayıyı resmi istatistik gibi vermiyorum, sadece saha gözlemi olarak belirtiyorum.

Senaryo 1: Bireysel Kullanıcı

Fotoğraf arşivi, vergi belgeleri, kişisel video kayıtları. Toplam 500 GB veri.

• Kopya 1 (üretim): Laptop SSD.
• Kopya 2 (yerel yedek): 2 TB harici USB HDD, haftalık otomatik backup (macOS Time Machine ya da Windows File History).
• Kopya 3 (offsite): Backblaze Personal Backup ya da iCloud / Google One / OneDrive cloud yedek.

Yıllık maliyet 700 TL ila 1.500 TL aralığında değişir. Detay maliyet bölümünde aşağıda.

Senaryo 2: KOBİ (5 ila 25 çalışan)

Ofis NAS'ında muhasebe, müşteri veritabanı, proje dosyaları. Toplam 4 TB üretim verisi.

• Kopya 1 (üretim): Synology NAS, SHR yapılandırma ile RAID koruması.
• Kopya 2 (yerel yedek): İkinci NAS ya da rotasyonlu harici disk (haftalık değişim).
• Kopya 3 (offsite immutable): AWS S3 Glacier Deep Archive ya da Backblaze B2 + Object Lock.

KOBİ'lerin en sık yaptığı hata, üretim NAS'ı RAID 5 olduğu için "yedek aldım" sanmak. RAID yedek değil; donanım arızasına karşı bir koruma katmanıdır ve RAID 5 çökmesi gerçek bir senaryodur. RAID yapılandırmasının üzerine 3-2-1 yedek planı eklenmeli.

Senaryo 3: Kurumsal (50+ çalışan)

ERP veritabanı, e-posta sunucusu, dosya sunucuları, sanal makineler. Toplam 50 TB.

• Kopya 1 (üretim): Production storage (SAN ya da hyperconverged).
• Kopya 2 (yerel yedek): Veeam Backup & Replication, dedicated backup repository.
• Kopya 3 (offsite + immutable): Cloud tier (Azure Blob immutable, AWS S3 Object Lock) ya da Veeam Hardened Repository (Linux + immutable flag).

Bu ölçekte 3-2-1-1-0'a ek olarak IR (incident response) playbook ve fidye yazılımı sonrası ilk 24 saat protokolleri de devrede olmalı.

Cloud Yedek Seçenekleri

Modern offsite kopyanın varsayılan adresi cloud bucket. Dört büyük seçenek:

AWS S3: S3 Standard sıcak veri için, S3 Glacier Instant Retrieval orta sıklıkta erişim için, S3 Glacier Deep Archive arşiv için. Object Lock özelliği immutable backup'ı destekler. AWS Backup servisi RDS, EC2, EBS gibi kaynakları otomatik yedekler. Resmi rehber: aws.amazon.com/backup.

Azure Blob Storage + Azure Backup: Microsoft'un resmi dokümantasyonu (learn.microsoft.com/en-us/azure/backup) Azure Backup Vault ile immutable backup, soft delete, multi-user authorization gibi özellikleri açıklıyor. Sıcak / soğuk / arşiv erişim katmanları S3'e benzer.

Google Cloud Storage: Standard, Nearline, Coldline, Archive katmanları. Bucket Lock retention policy ile immutability sağlar.

Backblaze B2: En ekonomik seçeneklerden biri, Object Lock destekler. KOBİ'ler için cazip fiyat noktası.

Hangi sağlayıcı olursa olsun seçimde dikkat edilmesi gereken üç başlık var: egress (veriyi geri çekme) ücreti, retrieval süresi (Glacier Deep Archive 12 saate kadar gecikme verir), ve immutability desteği.

Immutable Backup ve Object Lock

Immutable backup, belirlenen retention süresi dolana kadar dosyanın silinemediği, üzerine yazılamadığı ve değiştirilemediği bir yedek tipidir. Bu özelliği üreten teknolojiler:

• AWS S3 Object Lock: Governance mode (root override mümkün) ve Compliance mode (kimse silemez).
• Azure Blob immutable storage: Time-based retention ve legal hold modları.
• WORM teyp: Write Once Read Many, fiziksel olarak üzerine yazılamayan teyp kartuşları.
• Veeam Hardened Repository: Linux dosya sisteminde immutable attribute (chattr +i) ile korunmuş yedek.

Fidye yazılımı saldırılarında saldırgan ilk hedef olarak yedek sunucusunu seçer. Yedeği şifreleyebilir ya da silebilirse fidye ödenmesi olasılığı dramatik artar. Immutable kopya bu zinciri kırar.

Restore Testi: Yedek Varlığının Tek Kanıtı

Bir yedeğin var sayılabilmesi için tek kriter var: o yedekten son restore testi ne zaman, hangi sonuçla yapıldı. "0 hata" kriterinin pratik karşılığı bu.

Önerilen test sıklığı:

• Bireysel: Yılda en az bir kez, kritik dosyaları örnek olarak farklı bir cihaza geri yükle.
• KOBİ: Üç ayda bir, bir VM ya da bir dosya sunucusu yedeğini test laboratuvarına restore et.
• Kurumsal: Ayda bir tam restore senaryosu (tabletop ya da gerçek), yıllık tam felaket kurtarma tatbikatı.

Restore testi yapmadan yedek aldığını söyleyen müşterilerin yaklaşık yarısının yedeklerinde bütünlük problemleri olduğunu saha gözlemi olarak söyleyebiliriz. Sayıyı kaynak olmadan istatistik haline getirmiyorum; sadece pattern olarak vurguluyorum.

Ransomware Koruması: Air-Gapped ve Offline Yedek

Fidye yazılımı yazarları 2020 sonrası "double extortion" modeline geçti: önce veri çalınıyor, sonra şifreleniyor. Saldırganın hedeflediği ilk üç sistem genelde Active Directory, dosya sunucusu ve yedek sunucusu. Yedek erişilebilirse, yedek de şifrelenir.

Korunma katmanları:

1. Offline yedek: Rotasyonlu harici disk, kasada saklanan, yalnızca yedek alma anında ağa bağlanan.
2. Air-gapped yedek: Tamamen ağdan ayrı sistem; teyp kütüphanesi bunun klasik örneği.
3. Immutable cloud kopya: S3 Object Lock veya Azure immutable blob.
4. Yedek hesap ayrımı: Yedek sistemine sadece yedek servisinin erişebileceği, domain hesabıyla bağlantısı olmayan kimlik bilgisi.

KOBİ siber güvenlik temel paketi yazısında bu katmanların orta ölçekli işletmeler için somut maliyet tablosu var.

1 TB Ofis Verisi İçin Yıllık Maliyet Örneği

Kaba bir hesap (fiyatlar 2026 başı listelerine göre, sağlayıcı bazlı değişebilir):

• Yerel yedek (4 TB NAS, RAID 1): Tek seferlik 8.000 ila 12.000 TL donanım yatırımı. Yıllığa amorti edersek (5 yıl) 1.600 ila 2.400 TL.
• Backblaze B2 cloud (1 TB): Yaklaşık 6 USD/ay civarı, yıllık 2.500 TL bandında.
• AWS S3 Glacier Deep Archive (1 TB): Storage kalemi çok ucuz (yıllık birkaç yüz TL), ama egress ve retrieval maliyetleri eklenince toplam yıllık 1.500 ila 3.000 TL aralığına çıkabilir.
• Backup yazılımı (Veeam Community ya da Synology Active Backup): KOBİ ölçeğinde ücretsiz başlangıç mümkün.

Toplam: 1 TB veri için kurumsal düzeyde 3-2-1-1-0 yedek planı yıllık 5.000 ila 8.000 TL bandında oturuyor. Veri kaybının (tek bir RAID çökmesinden gelebilecek maliyet 10.000 ila 60.000 TL aralığında olabilir) çok altında.

Yaygın 7 Yanlış

1. Yedek üretim sistemiyle aynı makinede. Fidye geldi, hepsi gitti.
2. Yedek harici disk masanın üstünde. Hırsızlık, yangın ve düşme durumunda hem üretim hem yedek aynı kaderi paylaşır.
3. Yedek NAS'a domain admin hesabıyla erişiliyor. Saldırgan domain admin alırsa yedeği şifreleyebilir ya da silebilir.
4. Restore testi hiç yapılmamış. Yedek dosyası bozuk, kimse fark etmiyor.
5. Yedek alındı zannedilen klasör boş. Backup yazılımı sessiz hata veriyor, ama kimse log kontrol etmiyor.
6. Cloud yedek var ama versioning kapalı. Saldırgan dosyayı şifreleyip cloud'a sync ettirdi, eski temiz versiyon yok.
7. Yedek retention çok kısa. Saldırgan sisteme sızdı, 90 gün uyudu, sonra şifreledi. Yedekler 30 günlük, temiz versiyona dönüş imkansız.

KVKK ve Yedek Verisi

Yedek dosyaları kişisel veri içeriyorsa KVKK kapsamında. Kanun yedekleri özel olarak ele almasa da Kişisel Verileri Koruma Kurulu'nun yayımladığı "Veri Güvenliği Rehberi" yedekleme süreçlerinin de teknik ve idari tedbirler kapsamında olduğunu belirtir. Cloud sağlayıcı seçerken yurt dışı veri aktarımı, sözleşmesel garantiler ve şifreleme katmanları KVKK uyum kapsamında değerlendirilmeli.

SSS

Soru 1: RAID yedek midir? Hayır. RAID donanım arızasına karşı koruma sağlar, ama yanlışlıkla silme, fidye yazılımı, kontroller arızası, ofis yangını gibi senaryolarda RAID koruma vermez. RAID'in üzerine 3-2-1 yedek planı eklenmeli.

Soru 2: Snapshot yedek sayılır mı? Tek başına hayır. Snapshot aynı storage üzerinde tutulur, storage gittiğinde snapshot da gider. Yedek başka bir sistemde olmalı.

Soru 3: Bulut sync (Dropbox, OneDrive, Google Drive) yedek midir? Tam değil. Sync bir versiyonlama özelliği değildir; üretim verisi şifrelenirse sync ile cloud kopyası da şifrelenir. Bazı sağlayıcılar 30 ila 365 gün versiyonlama sunar, bu kullanılabilir ama dedicated backup ile aynı değildir.

Soru 4: Yedek ne sıklıkla alınmalı? RPO (recovery point objective) hedefine göre. Saatlik değişen veriler için saatlik incremental + günlük full uygun olur. Az değişen ofis dosyaları için günlük full yeterli.

Soru 5: Cloud yedek ne kadar tutulur (retention)? Kurumsal pratik 90 ila 365 gün arası. Bazı KVKK gerekçeleri ve sektörel düzenlemeler (BDDK, SPK) daha uzun retention zorunluluğu getirebilir.

Soru 6: Şifreli yedek anahtarı kaybolursa ne olur? Yedek erişilemez hale gelir. Kurumsal best practice anahtar yönetimini ayrı bir vault'ta (HashiCorp Vault, AWS KMS, Azure Key Vault) ve çift kontrolle (multi-party approval) tutmaktır.

Soru 7: HDD ile SSD yedeklemede hangisi daha iyi? Soğuk arşiv için HDD hala daha mantıklı; SSD power-off ortamda uzun süre durduğunda bit fade riski taşır. Bu konuyu HDD vs SSD ömür karşılaştırması yazısında detaylandırıyoruz.

Soru 8: Yedeği zaten alıyoruz, DSET'ten ne almamız gerekir? Restore testi, immutable katman tasarımı ve KVKK uyum doğrulaması. Yedek planı kağıt üstünde değil sahada işliyor mu, onu test ediyoruz.

DSET Yedek Stratejisi Danışmanlığı

DSET olarak Hacettepe Teknokent Ankara'daki ISO 5 temiz oda laboratuvarımızdan veri kurtarma hizmeti veriyoruz. Kurtarma sonrası en kritik soru her zaman aynı: bir daha yaşamamak için ne yapmalı? Bu noktada yedek stratejisi danışmanlığı devreye giriyor.

Hizmet kapsamı: mevcut yedek envanteri çıkarma, 3-2-1-1-0 uyum analizi, immutable katman tasarımı, restore test prosedürü kurma, RPO ve RTO hedef tanımları, KVKK uyum kontrolü. KOBİ ve kurumsal ölçekte yerinde değerlendirme yapıyoruz.

İletişim: +90 536 662 38 09. Hacettepe Üniversitesi Teknokent, Ankara.

Veri kurtarma süreciyle ilgili kapsamlı rehber için Türkiye 2026 veri kurtarma ana rehberimize ve fidye yazılımı sonrası ilk müdahale için ilk 24 saat acil protokolüne göz atabilirsiniz.

---

Bu yazı 2026-06-01 tarihinde DSET Veri Kurtarma ekibi tarafından hazırlandı. İçerikteki tüm bağımsız kaynaklar (CISA, Veeam, Microsoft, AWS, NIST, KVKK) orijinal yayıncılarının resmi dokümantasyonlarına bağlanmıştır. Sahada gözlem olarak verilen ifadeler istatistik niyetiyle değil, pattern uyarısı olarak yazılmıştır.