Merhaba
Bölüm 2’den Bu Yana: Veri Nerede Duruyor?
Bölüm 2‘de yedekleme sisteminin yönetimini ve veri hareketini nasıl konumlandırdığımızı (Centralized, Distributed, Scale-out) inceledik. Bu bölümde sorunun ikinci yarısına geliyoruz: yedek kopyalar hangi depolama katmanlarında, hangi ortamda ve hangi sürelerle tutulmalı? Hızlı restore için disk, uzun süreli saklama için bant, coğrafi ayrım ve değiştirilemezlik için bulut object storage (nesne depolama) kullanılır. Bu katmanların doğru kombinasyonu ise 3-2-1 ve onun güncel hali 3-2-1-1-0 kuralıyla ifade edilir.
Ürün örneklerinde yine Gartner’ın Mayıs 2026 tarihli Backup and Data Protection Platforms Magic Quadrant raporunda Leaders (Liderler) çeyreğinde yer alan altı üreticiyi esas alıyoruz: Veeam, Commvault, Cohesity, Rubrik, Druva ve Dell Technologies.
3-2-1 ve 3-2-1-1-0 Kuralı
3-2-1 kuralı, yedekleme dünyasının en sade ve en çok bilinen tasarım ilkesidir: verinin en az 3 kopyası bulunmalı, bu kopyalar en az 2 farklı ortam türünde saklanmalı ve bunlardan en az 1 kopya farklı bir lokasyonda (off-site) tutulmalıdır. Kuralın gücü, tek bir arıza türünün tüm kopyaları birlikte yok etmesini zorlaştırmasıdır: disk arızası, yangın, kullanıcı hatası veya bir üreticiye bağlı yazılım hatası aynı anda her kopyayı etkilemez.
Fidye yazılımı çağında bu kural tek başına yetmez. Saldırganlar yedekleme sistemini de hedef aldığı için kural iki ek koşulla genişletildi ve 3-2-1-1-0 biçimini aldı. Veeam’in best practice kılavuzundaki ifadeyle bu biçimde dördüncü rakam bir kopyanın offline (çevrimdışı), air-gapped (ağdan yalıtılmış) veya immutable (değiştirilemez) olmasını, son rakam ise düzenli recovery verification (geri yükleme doğrulaması) sonucunda sıfır hata bulunmasını ifade eder.
3-2-1-1-0 kuralının bileşenleri
| Rakam | Kural | Neyi önler | Kurumsal karşılığı | Sık yapılan hata |
|---|---|---|---|---|
| 3 | En az 3 kopya (production verisi dahil) | Tek kopya kaybına bağlı veri kaybı | Production, yerel repository, ikinci kopya | Production ve yerel snapshot’ı iki ayrı kopya saymak |
| 2 | En az 2 farklı ortam türü | Aynı donanım veya aynı yazılım hatasının tüm kopyaları etkilemesi | Disk ve object storage, disk ve bant | İki farklı disk dizisini iki farklı ortam saymak |
| 1 | En az 1 off-site kopya | Yangın, sel, tesis kaybı, bölgesel felaket | Uzak veri merkezi, bulut object storage, vault’a taşınan bant | Off-site kopyayı aynı kimlik sistemiyle yönetmek |
| 1 | En az 1 offline, air-gapped veya immutable kopya | Fidye yazılımı ve yetkili hesabın ele geçirilmesi | Object Lock’lı bucket, hardened repository, çıkarılmış bant | Kütüphanede takılı bandı offline sanmak |
| 0 | Doğrulamada sıfır hata | Geri yüklenemeyen yedek | Otomatik restore testi, tutarlılık kontrolü | Yedek işinin başarılı bitmesini geri yüklenebilirlik sanmak |
Pratikte iki rakam çoğu zaman aynı kopyayla karşılanır. Örneğin immutable bir object storage bucket’ı hem off-site hem de değiştirilemez kopya şartını sağlayabilir. Aynı şekilde ejected (çıkarılmış) ve kasada saklanan bir bant hem off-site hem offline şartını sağlar. Bu yüzden kuralı kopya sayısını artırma çabası olarak değil, her kopyanın hangi riski kapattığını gösteren bir eşleme olarak okumak daha doğrudur.
Giriş seviyesinde okuyucular için konuyu sade biçimde anlatan bir kaynak olarak Al Rasheed’in blog yazısı da faydalıdır (Kaynaklar bölümüne bakınız). Bu yazı kuralın mantığını anlatır ancak istatistik veya üretici dokümanı sunmaz. Mimari karar verirken aşağıdaki bölümlerdeki teknik ayrıntıları esas almanız gerekir.
Katmanlar Neden Birbirinin Yerine Geçmez?
Her depolama ortamı farklı bir ihtiyacı karşılar. Bu ihtiyaçlar hız, maliyet, saklama süresi ve saldırı yüzeyi olarak dört eksende ayrışır. Disk hızlıdır ama pahalıdır ve çevrimiçidir. Bant ucuz ve çevrimdışı olabilir ama erişimi yavaştır. Bulut esnek ve coğrafi olarak ayrıktır ama hesap güvenliği ve çıkış maliyeti ayrı bir tasarım konusudur.
Depolama katmanlarının karşılaştırması
| Katman | Erişim hızı | Maliyet yapısı | Güçlü yön | Zayıf yön | Tipik rol |
|---|---|---|---|---|---|
| Primary Disk Repository (Birincil disk deposu) | Çok yüksek | TB başına yüksek | Hızlı restore, Instant Recovery desteği | Çevrimiçi, saldırı yüzeyi geniş | Son günlerin yedekleri |
| Dedup Appliance (Tekilleştirme cihazı) | Yüksek | Veri azaltma ile düşer | Yüksek veri azaltma oranı | Rehydration (veriyi yeniden birleştirme) maliyeti, cihaza bağımlılık | Haftalar ve aylar için depo |
| Object Storage (Nesne depolama) | Orta | TB başına orta, ölçekle düşer | Object Lock ile değiştirilemezlik, yatay ölçek | Küçük nesne yükü, API (Application Programming Interface) bağımlılığı | İkinci kopya, immutable depo |
| Tape (Bant) | Düşük erişim, yüksek akış hızı | TB başına düşük | Uzun ömür, offline kopya imkanı | Erişim gecikmesi, fiziksel operasyon | Uzun süreli arşiv, air-gap |
| Cloud Archive Tier (Bulut arşiv katmanı) | Çok düşük (saatler) | Saklama ucuz, geri çağırma ücretli | Altyapı yönetimi yok, coğrafi ayrım | Geri çağırma süresi ve egress maliyeti | Uzun süreli saklama |
Disk Katmanı: Hızlı Restore’un Dayanağı
Disk, yedekleme mimarisinde ilk durak ve çoğu restore’un kaynağıdır. Bölüm 2‘de gördüğümüz yerel repository burada devreye girer. Disk katmanında iki tasarım seçeneği öne çıkar: standart disk (veya all-flash) üzerinde dosya sistemi tabanlı repository ve tekilleştirme yapan özel appliance’lar.
Dedup appliance’ların avantajı yüksek veri azaltma oranıdır. Dezavantajı, tekilleştirilmiş veriyi okurken yeniden birleştirme yükünün oluşması ve belirli üreticinin cihazına bağlı kalınmasıdır. Dell Technologies tarafında bu rol sıklıkla PowerProtect DD (Data Domain) serisiyle karşılanır. Veeam, Commvault ve Cohesity ortamlarında ise standart disk, object storage veya üreticinin kendi deposu tercih edilebilir.
Disk katmanında dikkat edilecek en önemli nokta, bu katmanın production kimlik sisteminden ayrı korunmasıdır. Bölüm 1‘de anlattığımız güven sınırı burada da geçerlidir. Disk üzerindeki yedekler, saldırganın ele geçirdiği yetkili bir hesapla silinebilir veya şifrelenebilir. Bu nedenle disk katmanı tek başına 3-2-1-1-0 kuralındaki immutable şartını karşılamaz, hardened (sertleştirilmiş) repository veya immutable object storage ile desteklenmelidir.
Tape Katmanı ve D2D2T Mimarisi
D2D2T (Disk-to-Disk-to-Tape), yedeğin önce diske, ardından banda yazıldığı klasik katmanlı modeldir. Disk hızlı restore sağlar, bant ise uzun süreli saklama ve offline kopya sunar. Aşağıdaki şekil bu akışı göstermektedir.
Çalışma Mekanizması
Yedekleme işi tamamlandığında veri önce Disk Repository’ye yazılır. Ardından Media Server (veya üründeki karşılığı) belirli bir politikaya göre bu kopyayı Tape Library içindeki kartuşlara aktarır. Aktarım disk ile bant arasında çalıştığı için production sistemlere yük bindirmez. Disk katmanında günler veya haftalar boyunca saklanan veri, bant katmanında aylar veya yıllar boyunca tutulur.
Bant Kapasitesi ve Süre Hesabı
Bant sisteminin boyutlandırılmasında iki rakam belirleyicidir: kartuş kapasitesi ve sürücü hızı. LTO (Linear Tape-Open) ailesinden LTO-9 kartuşu 18 TB native kapasiteye ve 400 MB/s native aktarım hızına sahiptir. LTO-10 ise 30 TB native kapasite sunar ve yine 400 MB/s native hız verir. Her iki nesil için üretici sıkıştırma oranını 2,5:1 varsayar, ancak yedekleme verisi çoğu zaman zaten sıkıştırılmış veya şifrelenmiş olduğu için bu oran garanti değildir. Aşağıdaki hesap yalnızca native değerleri kullanır.
LTO nesillerinin native kapasite ve süre hesabı
| Nesil (LTO, Linear Tape-Open) | Kartuş kapasitesi (native) | Sürücü hızı (native) | Bir kartuşu yazma süresi | 100 TB için gereken kartuş sayısı |
|---|---|---|---|---|
| LTO-9 | 18 TB | 400 MB/s | 12,5 saat | 6 |
| LTO-10 | 30 TB | 400 MB/s | 20,8 saat | 4 |
Bu rakamlardan sürücü sayısı da çıkarılabilir. Örneğin 100 TB’lık bir veriyi 24 saatte banda yazmak için 2,9 sürücü, yani pratikte en az 3 sürücü gerekir. Aynı veriyi 8 saatlik bir pencerede yazmak için 8,7 sürücü, yani en az 9 sürücü gerekir. Bu hesap kartuş değiştirme süresini, takılıp çıkarma gecikmesini ve sürücünün sürekli akış (streaming) hızında beslenebilmesi için gereken disk hızını hesaba katmaz. Sürücü beslenemezse bant durup yeniden konumlanır (shoe-shining), bu da hem hızı hem de ömrü düşürür.
Restore tarafında da aynı hız geçerlidir. Tek bir sürücüyle 10 TB’lık bir veri kümesini bant üzerinden okumak en az 6,9 saat sürer. Bu nedenle bant, sık ve hızlı restore için değil, uzun süreli saklama ve son çare kopya için konumlandırılmalıdır.
Bulut Katmanı ve D2D2C Mimarisi
D2D2C (Disk-to-Disk-to-Cloud), ikinci kopyanın banda değil bulut object storage’a gönderildiği modeldir. Yerel disk hızlı restore’u sağlar, buluttaki kopya ise off-site ve değiştirilemez katmanı oluşturur. Aşağıdaki şekil bu akışı göstermektedir.
Disk-to-Disk-to-Cloud architecture (Disk-Disk-Bulut mimarisi)
Immutability: S3 Object Lock
Bulut object storage’ın yedekleme açısından en değerli özelliği immutability sağlamasıdır. Amazon S3 Object Lock, nesneleri belirli bir süre veya süresiz olarak silinmeye ve üzerine yazılmaya karşı kilitler. Object Lock, nesne versiyonlama (versioning) gerektirir ve iki saklama modu sunar. Aşağıdaki tablo bu modları karşılaştırmaktadır.
S3 Object Lock saklama modları
| Mod | Kim kaldırabilir | Saklama süresi içinde silme | Tipik kullanım | Dikkat |
|---|---|---|---|---|
| Governance Mode (Yönetişim modu) | Özel izni olan kullanıcılar kilidi atlayabilir | Yetkili kullanıcı için mümkün | Test ve kademeli devreye alma | Yetkili hesap ele geçirilirse koruma düşer |
| Compliance Mode (Uyumluluk modu) | Hiçbir kullanıcı, kök hesap dahil | Mümkün değil | Gerçek ransomware koruması, düzenleyici saklama | Süre dolana kadar geri dönüş yok, yanlış süre maliyetli olur |
| Legal Hold (Hukuki bekletme) | Yetkili kullanıcı kaldırabilir | Kaldırılana kadar silinemez | Dava veya soruşturma saklaması | Saklama süresinden bağımsız çalışır |
Veeam, Scale-out Backup Repository (SOBR) mimarisinde object storage extent içeren her katman için immutability desteği sunar. Cohesity FortKnox, SaaS (Software as a Service) veya kendi yönettiğiniz izole bir bulut ortamında mantıksal air-gap sağlar ve veriyi saklama süresi bitene kadar değiştirilemez tutar. Rubrik Cloud Vault, tamamen yönetilen ve mantıksal olarak air-gapped bir bulut yedek depolaması sunar. Bu terimlerin kapsamı sürüme ve lisansa göre değiştiği için güncel üretici dokümanıyla doğrulanmalıdır.
Bulut Arşiv Katmanları ve Geri Çağırma Süreleri
Bulut sağlayıcıları, nesneleri erişim sıklığına göre farklı fiyatlı katmanlarda sunar. Soğuk katmanlar saklama maliyetini düşürür, ancak veriyi geri çağırma süresi ve minimum saklama süresi gibi kısıtlar getirir. Aşağıdaki tablo Amazon S3 Glacier ailesini özetler.
Amazon S3 Glacier katmanları (geri çağırma ve minimum saklama)
| Katman | Geri çağırma süresi | Minimum saklama | Not |
|---|---|---|---|
| S3 Glacier Instant Retrieval | Milisaniye | 90 gün | En az 128 KB nesne boyutu ücretlendirilir |
| S3 Glacier Flexible Retrieval | Dakikalardan 12 saate (Expedited 1-5 dakika, Standard 3-5 saat, Bulk 5-12 saat) | 90 gün | Geri çağırma seçeneğine göre ücret değişir |
| S3 Glacier Deep Archive | 9 ile 48 saat (Standard en çok 12 saat, Bulk en çok 48 saat) | 180 gün | Nesne başına 40 KB ek yük |
Bu sürelere bir de ağ süresi eklenir. Aşağıdaki tablo, geri çağrılan verinin hat üzerinden indirilmesi için teorik süreyi göstermektedir. Değerler protokol yükü ve paylaşılan hat hesaba katılmadan yalnızca veri boyutu ve hat hızından hesaplanmıştır.
Buluttan geri indirme için teorik ağ süresi
| Veri boyutu | Hat hızı | Teorik süre (saat) | Teorik süre (gün) |
|---|---|---|---|
| 10 TB | 1 Gbit/s | 22,2 saat | 0,9 gün |
| 10 TB | 10 Gbit/s | 2,2 saat | 0,1 gün |
| 50 TB | 1 Gbit/s | 111,1 saat | 4,6 gün |
| 50 TB | 10 Gbit/s | 11,1 saat | 0,5 gün |
| 100 TB | 1 Gbit/s | 222,2 saat | 9,3 gün |
| 100 TB | 10 Gbit/s | 22,2 saat | 0,9 gün |
Bulut Katmanının Riskleri
D2D2C tasarımında bulut riskleri
| Risk | Neden oluşur | Etkisi | Önlem |
|---|---|---|---|
| Account takeover (Hesap ele geçirilmesi) | Bulut hesabının üretim kimlik sistemiyle ortak olması veya zayıf MFA (Multi-Factor Authentication) | Saldırganın yedek kopyayı silmeye çalışması | Ayrı bulut hesabı, MFA, Compliance Mode Object Lock |
| Yanlış yapılandırılmış erişim | Gereğinden geniş IAM (Identity and Access Management) politikaları | Yedeğin silinmesi veya sızması | En az yetki ilkesi, politika denetimi |
| Şifreleme anahtarı kaybı | Anahtarın yalnızca üretim ortamında tutulması | Yedek var ama okunamıyor | Anahtarı ayrı ve erişilebilir yerde saklama, geri yükleme testi |
| Egress maliyeti | Büyük veri geri indirme ücreti | Felaket anında beklenmedik maliyet | Maliyet senaryosu hesaplama, RTO (Recovery Time Objective) ile birlikte planlama |
| Sınırlı bant genişliği | Hat hızının restore ihtiyacını karşılamaması | RTO aşımı | Hesaplama tablosuna göre hat boyutlandırma, kritik veri için yerel kopya |
| Soğuk katman gecikmesi | Arşiv katmanında bekleme süresi | Beklenmeyen gecikme | Kritik veriyi sıcak katmanda tutma, saklama kurallarını gözden geçirme |
Hangi Senaryoda Hangi Model?
D2D2T ve D2D2C birbirinin alternatifi olmak zorunda değildir, birlikte de kullanılabilir. Seçim saklama süresine, restore hızı beklentisine ve regülasyon gerekliliğine bağlıdır. Aşağıdaki tablo kaba bir çerçeve sunar.
Senaryoya göre D2D2T ve D2D2C seçimi
| Senaryo | Önerilen model | Neden | Dikkat |
|---|---|---|---|
| Çok büyük veri, yıllarca saklama | D2D2T | TB başına düşük maliyet, offline kopya | Sürücü ve kartuş operasyonu, kasa süreci |
| Dağınık şubeler, internet bağlantısı iyi | D2D2C | Altyapı yönetimi gerektirmez, coğrafi ayrım | Hat hızı ve egress maliyeti |
| Düzenleyici saklama, yazılabilir kopya yasak | D2D2C (Compliance Mode) veya WORM (Write Once Read Many) bant | Kriptografik veya fiziksel değiştirilemezlik | Saklama süresini yanlış seçmenin geri dönüşü yoktur |
| Hızlı restore öncelikli | Yerel disk katmanı birincil | Restore süresi diske bağlıdır | Uzak kopya felaket anı içindir, günlük restore için değil |
| Her ikisi de gerekli, yüksek güvence | Disk + bulut + bant | Üç farklı arıza alanı | Karmaşıklık ve maliyet artar |
Leaders Üreticilerin Katman Yaklaşımı
Leaders çeyreğindeki üreticilerin katman ve immutability yaklaşımı
| Vendor (Üretici) | Disk ve yerel depo | Bulut ve object storage | Bant | Not |
|---|---|---|---|---|
| Veeam | Hardened Repository, standart repository | SOBR (Scale-out Backup Repository) ile object storage extent, immutability | Bant desteği vardır | Capacity ve Archive Tier katmanlaması SOBR ile yönetilir |
| Commvault | MediaAgent ile disk kütüphanesi | Bulut depolama hedefleri | Bant desteği vardır | Air Gap Protect ayrıntıları için üretici dokümanına bakınız |
| Cohesity | DataProtect cluster, NetBackup disk depoları | FortKnox (izole bulut vault) | NetBackup tarafında bant desteği vardır | FortKnox, SaaS (Software as a Service) veya kendi yönetilen olarak sunulur |
| Rubrik | Cluster’ın yerel depolaması | Cloud Vault (yönetilen, air-gapped bulut depolaması) | Üretici dokümanına bakınız | Cloud Vault mantıksal air-gap sağlar |
| Druva | Yerel depo gerektirmez | Tamamen yönetilen SaaS (Software as a Service), bulut-doğrudan yedekleme | Uygulanmaz | Kopya yönetimi üretici bulutundadır |
| Dell Technologies | PowerProtect DD (Data Domain) cihazları | Bulut katmanlama ve kopya seçenekleri için üretici dokümanına bakınız | Üretici dokümanına bakınız | Cyber Recovery vault ayrıntıları Bölüm 5’te |
Sonuç ve Sonraki Bölüm
Disk, bant ve bulut birbirinin rakibi değil, farklı riskleri kapatan katmanlardır. Disk hızlı restore verir ama çevrimiçidir. Bant ucuz ve çevrimdışı olabilir ama yavaştır. Bulut coğrafi ayrım ve Object Lock sağlar ama hesap güvenliği ve çıkış maliyeti yeni bir tasarım konusudur. 3-2-1-1-0 kuralı bu katmanların hangi riski kapattığını sorgulamak için iyi bir kontrol listesidir. Bir kopyanın gerçekten offline veya immutable olup olmadığını, bir ürün sayfasındaki ifadeye değil, bir saldırgan ele geçirilmiş yetkili hesapla silmeyi denediğinde ne olduğuna bakarak değerlendirmek gerekir.
Serinin 4. bölümünde bu konunun teknik tarafına iniyoruz: snapshot, CDP (Continuous Data Protection, Sürekli Veri Koruma), immutability ve air-gap mekanizmaları. Hangi koruma gerçekten saldırıya dayanır, hangisi yalnızca iyi görünür, bunu tablolarla ele alacağız.