Merhaba
Kurumsal yedekleme denince çoğumuzun aklına ilk olarak bir yedekleme yazılımı, bir depolama cihazı ve her gece çalışan job’lar (iş tanımları) gelir. Oysa büyük ölçekli bir ortamda yedekleme, birbirine bağlı beş teknik katmandan ve bu katmanları yöneten ayrı bir yönetim düzleminden oluşan bir sistemdir. Bu seride dünyada kullanılan kurumsal yedekleme mimarilerini mühendislik bakışıyla, bölüm bölüm ele alıyoruz.
Serinin ilk bölümünde temeli atıyoruz: bir yedekleme sisteminin anatomisini, Control Plane (yönetim düzlemi) ile Data Plane (veri düzlemi) ayrımını ve bu ayrımın siber güvenlik açısından neden kritik olduğunu inceliyoruz. Sonraki bölümlerdeki tüm mimari kararlar bu temel üzerine oturduğu için bu bölümü atlamamanızı öneririm.
Seri planı
| Bölüm | Konu | Cevaplanan ana soru |
|---|---|---|
| 1 | Yedekleme sisteminin anatomisi, Control Plane ve Data Plane | Bir yedekleme sistemi hangi katmanlardan oluşur ve nerede kırılır? |
| 2 | Merkezi, dağıtık ve scale-out mimariler | Ortam büyüdükçe mimari nasıl değişir? |
| 3 | Disk, bant ve bulut katmanları | Hızlı restore ile uzun süreli saklama nasıl dengelenir? |
| 4 | Snapshot, CDP (Continuous Data Protection), immutability ve air-gap | Hangi koruma neyi gerçekten engeller? |
| 5 | Cyber Recovery Vault ve DR (Disaster Recovery) modelleri | Production tamamen güvenilmez olursa nasıl kurtarılır? |
| 6 | Veritabanı, Kubernetes ve SaaS (Software as a Service) yedekleme | Uygulama tutarlılığı nasıl sağlanır? |
| 7 | RPO (Recovery Point Objective), RTO (Recovery Time Objective), kapasite hesapları ve test metodolojisi | Hedefler sayılarla nasıl doğrulanır? |
| 8 | Referans mimariler, ürün yaklaşımları ve seçim rehberi | Hangi kurum için hangi mimari doğru? |
Yedekleme Başarısı ile Kurtarma Başarısı Aynı Şey Değildir
Bir yedekleme sisteminin her sabah yeşil ışık göstermesi, kurumun bir felaketten kurtulabileceği anlamına gelmez. Birincisi veri kopyalama problemidir. İkincisi ise veri tutarlılığı, kimlik güvenliği, bağımlılık sırası ve süre problemidir. Kurtarma tarafında iki hedef belirleyicidir: RPO (Recovery Point Objective, kabul edilebilir azami veri kaybı süresi) ve RTO (Recovery Time Objective, hizmetin geri gelmesi için hedeflenen azami süre). Mimari seçimlerinin neredeyse tamamı bu iki hedeften türetilir.
Modern yaklaşım altı prensip etrafında şekilleniyor. Aşağıdaki tabloda her prensibin hangi riske karşılık geldiğini ve hangi katmanda somut bir kontrole dönüştüğünü görebilirsiniz.
Modern yedekleme mimarisinin altı prensibi
| Prensip | Karşıladığı risk | Uygulandığı katman |
|---|---|---|
| Data Protection | Silinme, bozulma, donanım arızası, insan hatası | Production, Data Movement, Repository |
| Cyber Resilience | Fidye yazılımı, yönetici hesabının ele geçirilmesi | Repository, Vault, Control Plane |
| Disaster Recovery | Veri merkezi veya bölge kaybı | Off-site, alternatif altyapı |
| Isolation and Immutability | Yedeğin production kimliğiyle silinebilmesi veya değiştirilebilmesi | Vault, Off-site |
| Application Consistency | Veritabanının bozuk veya yarım işlemle geri dönmesi | Production, Data Movement |
| Recovery Orchestration | Yanlış sırayla restore, test edilmemiş kurtarma süreci | Control Plane |
Beş Katmanlı Referans Mimari
Kurumsal bir yedekleme sistemini beş veri katmanı ve bunların üzerinde duran tek bir yönetim düzlemi olarak düşünebiliriz. Aşağıdaki diyagram kavramsaldır. Gerçek ürünlerde bazı katmanlar aynı bileşende birleşebilir, veri ve yönetim trafiği ayrı ağlardan geçebilir.
Enterprise Backup System: Five-Layer Reference Architecture (Kurumsal yedekleme sisteminin beş katmanlı referans mimarisi)
Beş katmanın görevleri, tipik bileşenleri ve birincil riskleri
| Katman | Görevi | Tipik bileşenler | Birincil risk |
|---|---|---|---|
| 1. Production (İş Yükü Katmanı) | Korunacak iş yüklerinin bulunduğu alan | Virtual Machine (Sanal makine), Physical Server (Fiziksel sunucu), SQL Server, SAP HANA, NAS (Network Attached Storage), Kubernetes, SaaS (Software as a Service) | Tutarsız yedek alınması |
| 2. Data Movement (Veri Hareketi Katmanı) | Veriyi kaynaktan okuyup depoya taşımak; Deduplication (Tekilleştirme), Compression (Sıkıştırma) ve Encryption (Şifreleme) uygulamak | Backup Proxy (Yedekleme vekil sunucusu), Media Agent, Gateway (Ağ geçidi) | Darboğaz, yanlış transport modu |
| 3. Repository (Yedek Deposu Katmanı) | Yedek verisinin birincil saklandığı yer | Disk, File Share (Dosya paylaşımı), Deduplication Appliance (Tekilleştirme cihazı), Object Storage (Nesne depolama) | Deponun dolması, production kimliğiyle silinebilmesi |
| 4. Isolated Vault (İzole Kasa) | Production’dan ayrı bir güven sınırında koruma | WORM (Write Once Read Many), Air-gap (Hava boşluğu), Separate Identity System (Ayrı kimlik sistemi) | Yanlış yapılandırılmış izolasyon |
| 5. Off-site / Cloud (Coğrafi Dayanıklılık) | Coğrafi dayanıklılık | Object Lock (Nesne kilidi), Cross-region Copy (Bölgeler arası kopya), Tape (Manyetik bant) | Bulut hesabının ele geçirilmesi, uzun restore süresi |
Production Layer ve Veri Tutarlılığı Seviyeleri
Production layer, korunacak iş yüklerinin bulunduğu alandır: fiziksel sunucular, hypervisor’lar, veritabanları, dosya sunucuları, Kubernetes kaynakları ve SaaS (Software as a Service) verileri. Burada kritik nokta şudur: her iş yükünün tutarlı yedek alma yöntemi farklıdır. Bir sanal makinenin disk görüntüsünü almak ile SQL Server’ın aktif transaction log zincirini korumak veya SAP HANA’nın tutarlı bir data backup’ını almak teknik olarak aynı işlem değildir.
Veri tutarlılığı seviyeleri
| Seviye | Anlamı | Nasıl sağlanır | Dikkat edilecek risk |
|---|---|---|---|
| Crash-consistent | Elektrik kesintisi anındaki disk durumuna benzer | Storage veya hypervisor snapshot’ı, uygulamaya haber verilmeden | Veritabanı açılışta kendi recovery işlemini yapar; bazı uygulamalarda bütünlük sorunu çıkabilir |
| File-system-consistent | Dosya sistemi metadata tutarlılığı gözetilir | Misafir işletim sisteminde quiesce (işlemleri kısa süre duraklatma); Windows’ta VSS (Volume Shadow Copy Service) | Uygulamanın bellekteki yarım işlemleri kapsanmayabilir |
| Application-consistent | Uygulama veya veritabanı seviyesinde koordinasyon yapılır | VSS writer’lar, pre/post-freeze script’leri, uygulamanın native backup arayüzü | Yapılandırma veya izin hatasında bazı ürünler sessizce crash-consistent moda düşebilir |
Data Movement Layer
Bu katmanda proxy, Media Agent veya agent bileşenleri veriyi kaynak sistemden okuyup depoya aktarır. Hangi yöntemin kullanılacağı iş yüküne, depolama altyapısına ve hedeflenen RPO değerine göre belirlenir.
Veri okuma yöntemleri
| Yöntem | Çalışma şekli | Güçlü yönü | Dikkat edilecek nokta | Tipik kullanım |
|---|---|---|---|---|
| Agent-based | Korunan sunucuya kurulan servis veriyi okur | Dosya ve uygulama seviyesinde esneklik, fiziksel sunucu desteği | Agent yönetimi, sürüm ve yama yükü | Fiziksel sunucular, veritabanları |
| Agentless | Hypervisor’ın API’si (Application Programming Interface) üzerinden VM (Virtual Machine, sanal makine) diskleri okunur | Sunucuya yazılım kurmak gerekmez | Uygulama tutarlılığı için misafir işletim sistemi erişimi gerekebilir | Sanal makineler |
| Storage snapshot | Depolama sisteminin kendi snapshot motoru kullanılır | Çok hızlı, kaynak üzerinde düşük yük | Aynı cihazda kalan snapshot yedek sayılmaz; ürün uyumluluğu gerekir | SAN (Storage Area Network) veya NAS (Network Attached Storage) üzerindeki kritik veri |
| Change tracking | Değişen blokları işaretler: VMware’de CBT (Changed Block Tracking), Hyper-V’de RCT (Resilient Change Tracking) | Incremental yedek süresini ciddi biçimde kısaltır | Takip bozulursa sistem tam okumaya düşebilir | Incremental VM yedekleri |
| Log-based | Transaction veya redo log toplanır | Düşük RPO (Recovery Point Objective) ve PITR (Point-in-Time Recovery) | Log zinciri kopmamalıdır | Veritabanları |
| API-native | Servisin kendi yedekleme arayüzü kullanılır | Servis tarafından desteklenen tutarlılık | API limitleri ve kapsam farkları | SaaS (Software as a Service) ve bulut hizmetleri |
VMware ortamlarında agentless yedeklemenin performansı büyük ölçüde transport modu seçimine bağlıdır. Aynı proxy bile yanlış modda çalıştığında üretim ağını yorabilir veya yedek penceresini aşabilir.
VMware transport modları
| Mod | Veri yolu | Avantaj | Dezavantaj |
|---|---|---|---|
| SAN (Storage Area Network) | Proxy, datastore LUN’una (Logical Unit Number) FC (Fibre Channel) veya iSCSI (Internet Small Computer System Interface) ile doğrudan erişir | ESXi sunucusunu ve yönetim ağını yormaz, yüksek hız | Fiziksel proxy ve zoning/masking gerektirir, her ortama uymaz |
| HotAdd | Proxy bir sanal makinedir; yedeklenen makinenin diskleri geçici olarak proxy’ye bağlanır | Ağa yük bindirmeden yüksek hız | Proxy’nin ilgili datastore’a erişebilen host veya cluster üzerinde çalışması gerekir |
| NBD (Network Block Device) | Veri ESXi yönetim ağı üzerinden aktarılır | Kurulumu en basit moddur | En yavaş moddur, ESXi sunucusunun işlemcisini ve yönetim ağını yükler |
Bu katmanda veri azaltma ve şifreleme sırası da önemlidir. Veri önce chunk’lara bölünür, parmak izi (hash) çıkarılır, tekrar eden parçalar için yalnızca referans tutulur, yeni parçalar sıkıştırılır ve en son şifrelenir. Şifrelemeyi deduplication’dan önce yapmak, aynı veriyi her seferinde farklı görünür hale getirdiği için veri azaltma oranını ciddi biçimde düşürür.
Repository Layer
Repository, yedek verisinin birincil olarak saklandığı katmandır. Her depo türünün güçlü ve zayıf yönleri farklıdır; serinin sonraki bölümlerinde bunları ayrı ayrı inceleyeceğiz. Şimdilik hangi türün nerede öne çıktığını görmek yeterli.
Repository türleri
| Depo türü | Güçlü yön | Zayıf yön | Ayrıntı |
|---|---|---|---|
| Doğrudan bağlı disk veya SAN (Storage Area Network) LUN (Logical Unit Number) | Yüksek performans, basit yapı | Kapasite büyütmesi zor, sunucu kaybında erişim sorunu | Bölüm 2 |
| NAS (Network Attached Storage) üzerinde SMB (Server Message Block) veya NFS (Network File System) paylaşımı | Ucuz ve esnek | Production kimlik bilgisiyle erişilirse silinebilir | Bölüm 2 ve 4 |
| Deduplication appliance | Yüksek veri azaltma oranı | Restore sırasında rastgele I/O (Input/Output) yükü, lisans maliyeti | Bölüm 2 ve 7 |
| Object storage (S3 uyumlu) | Object Lock ile WORM (Write Once Read Many) koruması, yatay ölçek | Veri çıkış maliyeti, gecikme, bulut hesabı riski | Bölüm 3 ve 4 |
| Tape | Düşük maliyetli uzun süreli kapasite, gerçek offline saklama | Yavaş rastgele erişim, uzun restore süresi | Bölüm 3 |
Control Plane: Yedekleme Sisteminin Beyni
Control Plane, yedeklerin ne zaman alınacağını, nerede tutulacağını, kimlerin silebileceğini, retention politikalarını ve kurtarma operasyonlarını yönetir. Veri bloklarının kendisi bu katmandan geçmez; ancak hangi verinin nerede olduğunu, kimin neye yetkili olduğunu ve hangi hesapların kaynak sistemlere erişebildiğini burası bilir. Bu yüzden saldırganın gözünde en değerli hedeflerden biridir.
Control Plane bileşenleri ve ele geçirilmeleri durumunda oluşan etki
| Bileşen | Görevi | Ele geçirilirse ne olur |
|---|---|---|
| Scheduler (Zamanlayıcı) | Yedekleme işlerini zamanlar ve başlatır | Job’lar durdurulur, yeni recovery point oluşmaz ve RPO (Recovery Point Objective) fark edilmeden büyür |
| Catalog and Index (Katalog ve dizin) | Hangi verinin hangi recovery point’te ve hangi depoda olduğunu tutar | Yedekler durur ama bulunamaz, restore süresi uzar |
| Policy Engine (Politika motoru) | Retention, kopyalama ve saklama kurallarını uygular | Retention kısaltılır, eski recovery point’ler silinir |
| RBAC (Role-Based Access Control, Rol Tabanlı Erişim Kontrolü) ve Identity Integration (Kimlik entegrasyonu) | Kimin neyi yapabileceğini belirler | Yetki zinciri çöker, saldırgan yönetici olur |
| Credential Store (Kimlik bilgisi deposu) | Hypervisor, veritabanı ve agent hesaplarını saklar | Production hesapları çalınır, saldırı yedekleme üzerinden production’a taşınır |
| Monitoring and Reporting (İzleme ve raporlama) | Başarı durumu, alarm ve rapor üretir | Saldırı gizlenir, sahte başarılı raporlar görülür |
| Recovery Orchestrator (Kurtarma orkestratörü) | Restore sırasını ve runbook adımlarını yönetir | Kurtarma süreci sabote edilir |
Control Plane ile Data Plane Ayrımı
Data Plane, gerçek veri bloklarının kaynaktan depoya taşındığı ve depoda saklandığı katmandır. İki düzlemin trafiği, yetkisi ve saldırı yüzeyi birbirinden çok farklıdır. Güvenli bir tasarım bu farkı bilinçli olarak yönetir.
Control Plane ve Data Plane karşılaştırması
| Özellik | Control Plane | Data Plane |
|---|---|---|
| Yönettiği şey | Politika, zamanlama, katalog, yetki | Gerçek veri blokları |
| Trafik yapısı | Düşük hacimli yönetim ve API (Application Programming Interface) çağrıları | Yüksek hacimli veri aktarımı |
| Tipik bileşenler | Backup server, katalog veritabanı, yönetim konsolu | Proxy, Media Agent, repository |
| Saldırganın hedefi | Silme yetkisi, retention değişikliği, credential çalma | Yedek dosyalarını doğrudan silme veya şifreleme |
| Ağ ve erişim | Ayrı yönetim ağı, sınırlı yönetici erişimi, MFA (Multi-Factor Authentication) | Veri ağı, servis hesapları |
| Temel koruma | MUA (Multi-User Authorization), ayrı kimlik, audit log | Immutability, şifreleme, ağ segmentasyonu |
Üretici Terminolojisi: Aynı Rol, Farklı İsimler
Her üretici aynı mimari rolleri farklı isimlerle adlandırır. Bu seride kavramsal isimleri kullanacağız. Ürün örneklerinde ise 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. Aşağıdaki tablo, farklı ürünlerle çalışırken terimleri eşleştirmenize yardımcı olur.
Üretici terminolojisi eşleştirmesi (Leaders çeyreği)
| Vendor (Üretici) | Control Plane (Yönetim düzlemi) | Data Mover (Veri taşıyıcı) | Repository (Yedek deposu) |
|---|---|---|---|
| Veeam | Backup Server | Backup Proxy, Gateway Server | Backup Repository (Hardened Repository, Scale-out Backup Repository) |
| Commvault | CommServe | MediaAgent | Disk Library, Cloud Library |
| Cohesity (NetBackup) | Primary Server | Media Server | Disk Pool, MSDP (Media Server Deduplication Pool) |
| Cohesity (DataProtect) | Helios (merkezi yönetim) | Cohesity Cluster node’ları | Cohesity Cluster (scale-out depo) |
| Rubrik | Rubrik Security Cloud (merkezi yönetim) | Rubrik Cluster node’ları | Rubrik Cluster, Rubrik Cloud Vault |
| Druva | Druva Data Resiliency Cloud, SaaS (Software as a Service) yönetim katmanı | Agent ve connector bileşenleri (örneğin Phoenix) | Druva bulut depolaması (üretici tarafından yönetilir) |
| Dell Technologies | PowerProtect Data Manager | Data Manager proxy ve agent bileşenleri | PowerProtect DD (Data Domain) serisi |
Tehdit Modeli: Saldırgan Control Plane’e Ulaşırsa
Fidye yazılımı operatörleri artık yalnızca production sunucularını şifrelemiyor, önce yedekleme altyapısını arıyor. Backup sunucusu hem tüm kurumsal verinin kopyasına hem de çok sayıda sistemin hesap bilgisine erişebildiği için ideal bir hedeftir. Aşağıdaki tablo, yönetim düzlemini ele geçiren bir saldırganın tipik hamlelerini ve karşı önlemleri özetliyor.
Control Plane ele geçirildiğinde tipik saldırı hamleleri
| Saldırı hamlesi | Seviye | Etkisi | Karşı önlem |
|---|---|---|---|
| Job’ları devre dışı bırakmak veya silmek | Kritik | Yeni recovery point oluşmaz, RPO (Recovery Point Objective) sessizce büyür | Job durum değişikliği için alarm, RPO aşım izleme, MUA (Multi-User Authorization) |
| Retention süresini kısaltıp eski recovery point’leri silmek | Kritik | Geçmiş kurtarma noktaları kaybolur | Immutable depo, retention değişikliği için ikinci onay |
| Repository dosyalarını doğrudan silmek | Kritik | Yerel yedeklerin tamamı kaybedilir | Hardened veya immutable repository, ayrı kimlik, sertleştirilmiş işletim sistemi |
| Şifreleme anahtarlarını silmek veya erişilemez yapmak | Kritik | Yedek vardır ama okunamaz | KMS (Key Management Service) veya HSM (Hardware Security Module), ayrı kurtarma anahtarı, offline kopya |
| Credential store’dan hesap bilgilerini çıkarmak | Yüksek | Hypervisor, domain ve veritabanı hesapları ele geçirilir, saldırı production’a yayılır | En az yetki ilkesi, ayrı servis hesapları, backup sunucusunun sertleştirilmesi |
| Katalog veya yapılandırma veritabanını bozmak | Yüksek | Yedekler durur ama bulunması ve geri yüklenmesi zorlaşır | Yapılandırma yedeğinin off-site tutulması, anahtarın ayrı saklanması |
| Restore işlemiyle veri sızdırmak | Yüksek | Yedek tüm kurumsal verinin kopyasıdır, saldırgan restore edip dışarı çıkarır | Restore yetkisinin ayrılması, restore audit alarmı, şifreleme |
Katalog ve Yapılandırma Veritabanı: Gizli Tek Hata Noktası
Yedek verisinin kendisi sağlam olsa bile katalog ve yapılandırma veritabanı kaybedilirse hangi dosyanın nerede olduğunu, hangi anahtarla şifrelendiğini ve hangi zincire ait olduğunu bilemezsiniz. Birçok üründe depoyu yeniden taramak (rescan) ve kataloğu yeniden oluşturmak mümkündür, ancak bu işlem büyük ortamlarda saatler veya günler sürebilir. Bu nedenle yapılandırma yedeğinin düzenli alınması, off-site bir konuma kopyalanması ve şifreleme anahtarlarından ayrı saklanması gerekir.
>Serinin 7. bölümünde ele alacağımız tam yeniden kurulum testi tam olarak bu senaryoyu doğrular: yedekleme sunucusu, katalog ve anahtarlar sıfırdan kurulduğunda yedekler bulunabiliyor ve geri yüklenebiliyor mu?
Tasarım Kontrol Listesi
Aşağıdaki tablo, mevcut bir yedekleme altyapısını bu bölümdeki bakış açısıyla hızlıca değerlendirmeniz için hazırlandı. Her satıra net bir evet veya hayır cevabı verebiliyorsanız temel olgunluk seviyesine sahipsiniz demektir.
Yedekleme anatomisi kontrol listesi
| Kontrol | Neden önemli | Sorulacak soru |
|---|---|---|
| Backup sunucusunun kimlik sınırı | Production AD (Active Directory) ele geçirilirse yedekleme yönetimi de düşer | Backup sunucusu production AD’ye üye mi, yoksa ayrı bir kimlik alanında mı? |
| Yönetim arayüzünün erişim yüzeyi | Geniş ağdan erişilebilen konsol saldırı yüzeyini büyütür | Yönetim konsoluna yalnızca ayrı yönetim ağından ve yönetim istasyonlarından mı erişiliyor? |
| Yönetici hesapları | Tek faktörlü yönetici hesabı en kolay hedeftir | Tüm yönetici hesaplarında MFA (Multi-Factor Authentication) zorunlu mu? |
| Yıkıcı işlemlerin onayı | Tek kişinin silebilmesi kötü niyetli kullanımı kolaylaştırır | Retention değişikliği ve yedek silme için ikinci onay mekanizması var mı? |
| Yapılandırma yedeği | Katalog kaybında kurtarma süresi uzar | Yapılandırma yedeği off-site mı ve anahtarlardan ayrı mı saklanıyor? |
| Audit log izleme | Saldırı belirtileri yönetim loglarında görünür | Yedekleme audit logları SIEM’e (Security Information and Event Management) akıyor mu? |
| Bağımsız kurtarma kabiliyeti | Yönetim sunucusu kaybında yedeklere erişim kritik hale gelir | Backup sunucusu olmadan sıfırdan restore hiç denendi mi? |
Sonuç ve Sonraki Bölüm
Bir yedekleme sistemini anlamanın ilk adımı onu katmanlara ayırmaktır: production, veri hareketi, depo, izole kasa ve off-site. İkinci adım, bu katmanları yöneten Control Plane’i veri düzleminden ayrı bir güven sınırı olarak görmektir. Yedekleme başarısı ile kurtarma başarısının farklı mühendislik problemleri olduğunu kabul ettiğinizde, sonraki bölümlerdeki mimari kararlar çok daha anlamlı hale gelir.
Serinin 2. bölümünde merkezi, dağıtık ve scale-out yedekleme mimarilerini ele alıyoruz: ortam büyüdükçe repository, proxy ve katalog tasarımı nasıl değişiyor, hangi mimari hangi ölçekte darboğaz oluşturuyor, 8+2 erasure coding gibi dayanıklılık şemaları kapasiteyi nasıl etkiliyor.
