Merhaba

Bölüm 1’den Bu Yana: Katmanlar Aynı, Dağılım Farklı

Bölüm 1’de bir yedekleme sistemini beş veri katmanı ve bunları yöneten Control Plane (Yönetim Düzlemi) olarak ele almıştık. Bu bölümde aynı katmanların ortamda nasıl konumlandığını inceliyoruz: yönetim tek merkezde mi toplanıyor, veri hareketi ve depolama lokasyonlara mı dağılıyor, yoksa kapasite ve performans yatay olarak mı büyüyor? Bu üç soru Centralized (Merkezi), Distributed (Dağıtık) ve Scale-out (Yatay Ölçeklenebilir) mimarileri birbirinden ayırır.

Bu mimariler birbirini dışlayan ürün kategorileri değildir. Büyük kurumlarda çoğu zaman birkaçı birlikte kullanılır. Ürün örneklerinde Gartner’ın Mayıs 2026 tarihli Backup and Data Protection Platforms Magic Quadrant (Sihirli Çeyrek) raporunda Leaders (Liderler) çeyreğinde yer alan altı üreticiyi esas alıyoruz: Veeam, Commvault, Cohesity, Rubrik, Druva ve Dell Technologies.

Üç mimarinin karşılaştırması

Centralized Backup Architecture (Merkezi Yedekleme Mimarisi)

Merkezi mimari, kurumsal yedeklemenin klasik modelidir. Bir veya birkaç yedekleme sunucusu, korunacak tüm sunucuların yedekleme görevlerini yönetir. Aşağıdaki şekil modeli göstermektedir.

Centralized backup architecture (Merkezi yedekleme mimarisi)

Çalışma Mekanizması

İş akışı şu sırayla ilerler. Scheduler (Zamanlayıcı) işi başlatır. Kaynak sistem, Bölüm 1’de anlattığımız tutarlılık yöntemine göre dondurulur veya snapshot (anlık görüntü) alınır. Veri, Backup Proxy (Yedekleme Vekil Sunucusu) üzerinden repository’ye aktarılır ve bu sırada sıkıştırma, Deduplication (Tekilleştirme) ve şifreleme uygulanabilir. İş tamamlandığında geri yükleme noktasının metadata (üst veri) bilgisi Catalog (Katalog) içine yazılır.

Bu modelin cazibesi sadeliğidir: kurulum ve yönetim nispeten basittir, retention (saklama süresi), raporlama ve job yönetimi tek merkezden yapılır. Küçük ve orta büyüklükteki veri merkezleri için ekonomik olabilir. Bedeli ise merkezi bileşenlere bağımlılıktır.

Merkezi mimarinin yaygın darboğazları ve önlemleri

Merkezi Modelin Ürün Karşılıkları

Leaders çeyreğindeki üreticilerden dördü klasik merkezi model terimleriyle konuşur: bir yönetim sunucusu ve ondan ayrık veri hareketi bileşenleri.

Distributed Backup Architecture (Dağıtık ve Çok Lokasyonlu Yedekleme)

Büyük kurumlarda tüm verinin tek bir merkezi depoya gönderilmesi, WAN (Wide Area Network, Geniş Alan Ağı) bant genişliği ve kurtarma performansı bakımından verimsiz olabilir. Dağıtık mimaride kontrol merkezi kalabilir, ancak veri aktarımı ve depolama yerel lokasyonlara dağıtılır.

Distributed backup architecture (Dağıtık yedekleme mimarisi)

Teknik Yaklaşım

Her lokasyonda yerel bir Data Mover veya Proxy bulunur. Yedekleme önce yerel Repository’ye yazılır, daha sonra yalnızca yeni veya değişen veri segmentleri uzak merkeze aktarılır. Böylece şubeler yerel olarak hızlı geri dönüş yapabilirken, merkez ofis veya uzak veri merkezi büyük ölçekli bir felakette alternatif kurtarma noktası sağlar. WAN üzerinden taşınan veriyi azaltmak için aşağıdaki teknikler kullanılır.

WAN yükünü azaltma teknikleri

WAN Bant Genişliği Nasıl Hesaplanır?

Bir hattın yedekleme trafiğini taşıyıp taşıyamayacağını görmek için basit bir formül yeterlidir: Gereken hız = (Korunan veri x Günlük değişim oranı / Veri azaltma oranı) x 8 / Kopya penceresi. Aşağıdaki tablo bu formülü üç örnek lokasyon için uygulamaktadır. Değerler örnektir, kendi ortamınızda değişim oranını ölçerek hesaplamalısınız.

WAN (Wide Area Network) bant genişliği örnek hesabı

Pratikte hattın yalnızca yedekleme için ayrılmadığını, protokol yükünü ve dalgalanmayı da hesaba katarak bu değerlere en az %30 pay eklemenizi öneririm. İlk tam yedeğin uzak merkeze taşınması ise ayrı bir problemdir. Örneğin bölgesel veri merkezindeki 20 TB verinin ilk kopyası 2:1 azaltmayla yaklaşık 10 TB olur. 200 Mbit/s ayrılmış bir hatta bu yaklaşık 4,6 gün sürer. Bu nedenle ilk kopya için çoğu zaman diskle fiziksel taşıma (offline seeding) veya geçici hat artırımı planlanır.

Yerel Restore Dağıtık Mimarinin Asıl Gerekçesidir

Dağıtık mimaride WAN yükünü azaltmak kadar önemli bir başka gerekçe restore süresidir. Aşağıdaki tablo, 2 TB’lık bir sunucunun üç farklı yoldan geri yüklenmesi için teorik süreleri karşılaştırmaktadır.

2 TB’lık bir sunucunun teorik restore süreleri

Control Plane Erişilemediğinde Ne Olur?

Dağıtık mimarinin kritik sorusu şudur: merkezdeki Control Plane erişilemediğinde yerel kurtarma devam edebiliyor mu? Cevap ürünün mimarisine bağlıdır ve tasarım veya satın alma aşamasında mutlaka test edilmelidir. Aşağıdaki tablo bu testin sorularını listeler.

Dağıtık mimari için Control Plane erişim testi

Dağıtık Modelin Ürün Karşılıkları

Uzak lokasyondan merkeze kopya mekanizması her üründe farklı adlandırılır. Aşağıdaki tablo, altı üreticinin bu işi hangi terimle yaptığını özetler.

Uzak lokasyon kopyası: üretici terminolojisi

Scale-out Backup Architecture (Yatay Ölçeklenebilir Yedekleme)

Klasik mimarilerde kapasite artışı çoğu zaman mevcut depolama ünitesini büyütmeyi (scale-up) gerektirir. Scale-out mimarisinde ise sisteme yeni node’lar eklenerek kapasite ve bazı tasarımlarda performans artırılır. Şeklin sağ tarafında, bu mimarilerde sıkça karşılaşılan erasure coding (silme kodlaması) mantığı da gösterilmiştir.

Scale-out backup architecture and erasure coding (Yatay ölçeklenebilir yedekleme mimarisi ve silme kodlaması)

İki Uygulama Modeli

Scale-out kavramı iki farklı şekilde hayata geçer. Scale-out Repository (Yatay Ölçeklenebilir Depo) modelinde birden fazla bağımsız depo tek bir mantıksal havuz olarak yönetilir ve veri yerleşimi politika tabanlıdır. Hyperconverged Backup Appliance (Hiper Yakınsak Yedekleme Cihazı) modelinde ise compute, storage, indeksleme ve bazı durumlarda deduplication aynı node yapısında birleşir; cluster içindeki veri dağıtımı, yeniden dengeleme ve hata toleransı ürün tarafından yönetilir. Her scale-out havuzun dağıtık bir dosya sistemi veya otomatik erasure coding içermediğini unutmamak gerekir.

Scale-out uygulama modelleri

Kapasite ve Dayanıklılık: Replication ve Erasure Coding

Dağıtık yedekleme depolarında hata toleransı replikasyon veya erasure coding ile sağlanır. Erasure coding, veriyi k adet veri parçasına böler, m adet parity (eşlik) parçası hesaplar ve toplam k+m parçayı farklı hata alanlarına yazar. m parçaya kadar kayıp tolere edilir. Teorik ham depolama verimliliği şu formülle bulunur: Verimlilik = k / (k + m). Örneğin 8+2 şemasında 8 / 10 = 0,8, yani %80’dir.

Replication ve Erasure Coding şemalarının karşılaştırması

Bu tabloda bir noktayı ayrıca vurgulamak gerekir: şema ancak parçalar bağımsız hata alanlarına dağıtılırsa anlamlıdır. Hata alanı bir disk, bir node, bir rack (kabinet) veya bir veri merkezi olabilir. 8+2 şemasında node düzeyinde tolerans için en az 10 node, rack düzeyinde tolerans için en az 10 rack gerekir. Parçalar 5 rack’e ikişer parça olacak şekilde dağıtılırsa tek rack kaybı tolere edilir, ikinci rack kaybı ise veri kaybına yol açar. Kapasite hesabında ayrıca rebuild (yeniden oluşturma) ve rebalancing için boş alan bırakılmalı, değerler deduplication ve sıkıştırma öncesi ham kapasite olarak okunmalıdır.

Scale-out Tasarımında Sorulacak Sorular

Scale-out tasarım kontrol listesi

Üç Mimariyi Birlikte Kullanmak

Gerçek kurumsal ortamlar çoğunlukla üçünü birleştirir: şubelerde yerel proxy ve küçük depolar (Distributed), merkez veri merkezinde scale-out bir ana depo (Scale-out) ve hepsini yöneten ortak bir Control Plane (Centralized yönetim). Control Plane’in kendisi, Bölüm 1’de anlattığımız gibi production’dan ayrı bir güven sınırında tutulmalıdır.

Senaryoya göre mimari seçimi

Leaders Üreticilerin Mimari Yaklaşımı

Aşağıdaki tablo altı üreticinin baskın mimari yaklaşımını özetler. Üreticilerin ürün aileleri geniştir ve birden fazla modeli destekleyebilir, bu nedenle tablo kaba bir çerçeve sunar.

Leaders çeyreğindeki üreticilerin baskın mimari yaklaşımı

Sonuç ve Sonraki Bölüm

Merkezi, dağıtık ve scale-out mimariler birbirinin alternatifi olmaktan çok, aynı sistemin farklı ölçeklerdeki cevaplarıdır. Merkezi model yönetimi basitleştirir ama bileşenlere bağımlılık yaratır. Dağıtık model WAN yükünü ve restore süresini düşürür ama Control Plane erişilemediğinde davranışın test edilmesini gerektirir. Scale-out model büyümeyi kolaylaştırır ama hata alanı tasarımını zorunlu kılar. Hangisini seçerseniz seçin, kritik soru değişmiyor: felaket anında yedekler bulunabilecek, erişilebilecek ve zamanında geri yüklenebilecek mi?

Serinin 3. bölümünde depolama katmanlarını ele alıyoruz: disk, bant ve bulut. D2D2T (Disk-to-Disk-to-Tape) ve D2D2C (Disk-to-Disk-to-Cloud) modellerini, hızlı restore ile uzun süreli saklama arasındaki dengeyi ve object storage’ın yedekleme depolaması olarak neden önemli hale geldiğini inceleyeceğiz.