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 rule mapped to an enterprise architecture (3-2-1-1-0 kuralının kurumsal mimariyle eşlenmesi)

3-2-1-1-0 kuralının bileşenleri

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ı

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.

Disk-to-Disk-to-Tape architecture (Disk-Disk-Bant mimarisi)

Ç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ı

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ı

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)

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

Bulut Katmanının Riskleri

D2D2C tasarımında bulut riskleri

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

Leaders Üreticilerin Katman Yaklaşımı

Leaders çeyreğindeki üreticilerin katman ve immutability yaklaşımı

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.