Kurumsal yedekleme altyapılarında veri hacmi büyüdükçe yalnızca “daha büyük bir disk alanı” sağlamak yeterli olmaz. Yedekleme ortamının ölçeklenebilir, yönetilebilir, güvenli, performanslı ve uzun süreli saklama ihtiyaçlarına uygun olması gerekir.
Bu noktada Veeam Backup & Replication içinde yer alan Scale-Out Backup Repository kısaca SOBR klasik tekil repository yaklaşımını genişleterek birden fazla depolama kaynağını mantıksal olarak tek bir yapı altında toplamayı sağlar.
SOBR farklı backup repository veya object storage repository kaynaklarını bir araya getirerek yatay ölçeklenebilir bir yedekleme havuzu oluşturur.
Veeam dokümantasyonunda SOBR Performance Tier, Capacity Tier ve Archive Tier gibi farklı mantıksal depolama katmanlarından oluşabilen bir repository sistemi olarak tanımlanır.
- Performance Tier hızlı erişim için,
- Capacity Tier daha az erişilen veriler için,
- Archive Tier ise nadiren erişilen ve uzun süre saklanacak arşiv verileri için kullanılır.
Bu makalemde Veeam Scale-Out Backup Repositories yapısını detaylı şekilde ele alacağız. SOBR’nin ne olduğu, hangi avantajları sunduğu, hangi repository türleriyle çalıştığı, katmanların nasıl konumlandırılması gerektiği, immutability kullanımının önemi, lisans ve limitasyonlar, sık yapılan hatalar ve tasarım sırasında dikkat edilmesi gereken kritik noktalar ayrıntılı olarak incelenecektir.
Scale-Out Backup Repository Nedir?
Scale-Out Backup Repository birden fazla repository kaynağını tek bir mantıksal repository gibi kullanmayı sağlayan Veeam bileşenidir. Bu yapı sayesinde backup job’lar tek bir hedefe yönlendirilir arka planda ise Veeam, veriyi SOBR içindeki extent’lere belirlenen politika ve kurallara göre dağıtır.
SOBR içindeki her depolama kaynağına extent adı verilir. Bu extent bir Windows repository, Linux repository, SMB/NFS share, deduplication appliance veya object storage repository olabilir.
Veeam SOBR içindeki kapasiteyi mantıksal olarak bir araya getirir ve backup job’lar açısından tek bir hedef repository sunar.
Veeam’in resmi dokümantasyonuna göre SOBR Windows ve Linux repository’ler, SMB/CIFS, NFS, deduplication storage appliance ve object storage repository türlerini destekler.
SOBR’nin en temel amacı backup depolama altyapısını esnek ve büyütülebilir hale getirmektir. Örneğin mevcut backup repository kapasitesi dolmaya başladığında tüm backup verisini daha büyük bir storage’a taşımak yerine mevcut SOBR yapısına yeni bir extent eklenebilir. Böylece yeni storage’ın boş kapasitesi SOBR’nin toplam kapasitesine dahil edilir. Bu yaklaşım özellikle veri hacmi sürekli artan ortamlarda ciddi yönetim kolaylığı sağlar.
SOBR Neden Kullanılır?
SOBR’nin tercih edilmesinin temel sebeplerini birkaç ana başlık altında değerlendirebiliriz.
İlk olarak yönetim kolaylığı sağlar. Birden fazla fiziksel veya mantıksal repository ayrı ayrı yönetilmek yerine tek bir Scale-Out Backup Repository altında toplanır. Backup job’lar tek tek repository’lere değil SOBR’ye hedeflenir. Bu da operasyonel karmaşıklığı azaltır.
İkinci olarak kapasiteyi yatay olarak büyütme imkanı sunar. Klasik yöntemde repository dolduğunda yeni bir büyük storage almak, eski backup’ları taşımak veya job hedeflerini yeniden düzenlemek gerekebilir. SOBR’de ise yeni bir extent eklenerek toplam kapasite artırılır.
Üçüncü olarak farklı storage türlerini birlikte kullanma esnekliği verir. Örneğin yerel disk tabanlı hızlı repository’ler Performance Tier’da S3 uyumlu object storage ise Capacity Tier’da kullanılabilir. Daha düşük maliyetli arşiv depolama için Archive Tier eklenebilir.
Dördüncü olarak uzun süreli saklama ve cloud offload senaryolarını kolaylaştırır. Capacity Tier ile veriler object storage’a kopyalanabilir veya belirli süre sonunda taşınabilir. Archive Tier ile nadiren erişilecek GFS full backup’lar daha düşük maliyetli arşiv storage’a gönderilebilir.
Beşinci olarak immutability ve ransomware dayanıklılığı açısından önemli bir güvenlik katmanı oluşturabilir. Özellikle object storage repository’ler üzerinde immutability etkinleştirildiğinde backup verisinin belirli süre boyunca silinmesi engellenebilir.
Veeam SOBR’ye eklenen object storage repository’lerdeki veriyi geçici olarak immutable hale getirerek kötü amaçlı silme, malware veya saldırı kaynaklı veri kaybına karşı koruma sağlayabilir.
SOBR Mimarisi: Extent Kavramı
SOBR’nin temel yapı taşı extenttir. Extent SOBR’ye dahil edilen repository kaynağıdır. Bir extent fiziksel bir disk alanı, Linux/Windows repository, network share, deduplication appliance veya object storage olabilir.
Bir repository SOBR’ye extent olarak eklendikten sonra artık bağımsız bir backup repository gibi kullanılmaz. Backup job’lar doğrudan o extent’e değil SOBR’ye hedeflenmelidir.
Veeam dokümantasyonunda bir backup repository veya object storage repository Performance Tier extent’i olarak eklendiğinde artık bireysel backup repository olarak davranmadığı belirtilir.
Bu nokta operasyonel açıdan çok önemlidir. Çünkü yöneticiler bazen mevcut bir repository’yi SOBR’ye ekledikten sonra aynı repository’ye ayrıca job yönlendirmeye çalışabilir. Bu doğru bir kullanım değildir. SOBR’ye dahil edilen extent, artık SOBR’nin bir parçası olarak yönetilmelidir.
SOBR Katmanları
SOBR üç temel katmandan oluşabilir;
- Performance Tier
- Capacity Tier
- Archive Tier
Her ortamda üç katmanın tamamını kullanmak zorunlu değildir. Küçük veya orta ölçekli yapılarda yalnızca Performance Tier yeterli olabilir.
Daha büyük ortamlarda Capacity Tier ve Archive Tier eklenerek hem maliyet hem de uzun süreli saklama politikaları optimize edilir.
1) Performance Tier
Performance Tier SOBR’nin hızlı erişim katmanıdır. Backup job’ların ilk yazdığı restore işlemlerinde en hızlı erişimin beklendiği ana katmandır. Bu katman bir veya birden fazla performance extent’ten oluşabilir.
Veeam’e göre Performance Tier; hızlı veri erişimi için kullanılan katmandır ve Windows/Linux repository, SMB, NFS, deduplication appliance veya object storage repository gibi kaynaklardan oluşabilir.
Performance Tier tasarlanırken şu sorular mutlaka yanıtlanmalıdır:
- Backup job’ların günlük yazacağı veri miktarı nedir?
- Full backup, synthetic full ve incremental backup süreçlerinde oluşacak I/O yükü ne kadardır?
- Restore sırasında beklenen RTO nedir?
- Repository üzerindeki disk altyapısı yeterli IOPS ve throughput sağlayabiliyor mu?
- Aynı anda kaç job veya task çalışacak?
- Repository gateway, proxy ve network kapasitesi yeterli mi?
Performance Tier sadece kapasite açısından değil performans açısından da doğru tasarlanmalıdır. Yetersiz disk performansı backup window’un uzamasına, synthetic full işlemlerinin yavaşlamasına, merge süreçlerinin problemli hale gelmesine ve restore sürelerinin artmasına neden olur.
Backup File Placement Policy
SOBR’de Performance Tier için en önemli konulardan biri Backup File Placement Policy seçimidir. Bu politika ile backup dosyalarının performance extent’ler üzerinde nasıl dağıtılacağını belirler.
Veeam dokümantasyonuna göre iki temel politika vardır: Data Locality ve Performance.
a) Data Locality Policy
Data Locality, aynı backup chain’e ait dosyaların aynı extent üzerinde tutulmasını sağlar. Yani bir full backup ve ona bağlı incremental backup dosyaları aynı extent’te kalır. Yeni bir backup chain oluştuğunda, Veeam bu yeni chain’i aynı veya farklı bir extent’e yerleştirebilir.
Bu politika özellikle restore operasyonlarında sadelik sağlar. Bir backup chain’in parçaları farklı storage’lara dağılmadığı için chain bütünlüğünü yönetmek daha kolaydır. Ayrıca ReFS veya XFS üzerinde Fast Clone kullanımı planlanıyorsa Data Locality tercih edilmesi önerilir; Veeam dokümantasyonunda Fast Clone için Data Locality seçilmesi tavsiye edilir.
Data Locality çoğu ortam için güvenli ve anlaşılır bir başlangıç tercihidir. Özellikle küçük ve orta ölçekli ortamlarda, yönetim kolaylığı ve backup chain bütünlüğü açısından avantaj sağlar.
b) Performance Policy
Performance Policy, full ve incremental backup dosyalarını farklı extent’lere dağıtabilir. Bu yaklaşım özellikle transform, merge veya synthetic full gibi işlemlerde I/O yükünü farklı storage kaynaklarına yayarak performans avantajı sağlayabilir.
Veeam dokümantasyonuna göre Performance Policy kullanıldığında full ve incremental dosyalar aynı backup chain içinde farklı extent’lerde tutulabilir.
Ancak bu politikanın önemli bir riski vardır. Backup chain’in parçaları farklı extent’lere dağılacağı için tüm ilgili extent’lerin erişilebilir olması gerekir.
Eğer chain’in bir parçasının bulunduğu extent offline ise job veya restore işlemi başarısız olabilir.
Bu nedenle Performance Policy seçilecekse network bağlantısının hızlı ve güvenilir olması, extent’lerin erişilebilirliğinin sürekli izlenmesi ve gerekli durumlarda “required extent offline ise full backup oluştur” gibi seçeneklerin dikkatle değerlendirilmesi gerekir.
2) Capacity Tier
Capacity Tier Performance Tier üzerindeki verinin daha uzun süreli veya daha düşük maliyetli object storage alanında saklanmasını sağlayan ek katmandır.
Bu katman cloud-based veya on-premises object storage repository’lerden oluşur.
Veeam dokümantasyonuna göre Capacity Tier, Performance Tier’daki verinin uzun süreli saklama amacıyla object storage’a taşınabildiği veya kopyalanabildiği katmandır.
Capacity Tier şu senaryolarda özellikle faydalıdır:
- Yerel repository kapasitesi hızla doluyorsa
- Kurum politikası belirli bir süreden eski yedeklerin farklı ortamda saklanmasını gerektiriyorsa
- Felaket senaryoları için farklı lokasyonda ek kopya isteniyorsa
- Cloud object storage ile uzun süreli saklama maliyeti optimize edilmek isteniyorsa
- 3-2-1 backup stratejisinin daha güçlü uygulanması hedefleniyorsa
Capacity Tier’da iki temel çalışma yaklaşımı vardır.
Copy Mode
Bu modda yeni backup dosyaları oluşturulur oluşturulmaz object storage’a kopyalanır. Böylece Performance Tier’da bulunan backup’ın bir kopyası kısa sürede Capacity Tier’a da aktarılmış olur.
Bu yaklaşım felaket kurtarma ve ransomware dayanıklılığı açısından güçlüdür. Çünkü primary repository zarar görse bile object storage üzerinde ek bir kopya bulunabilir.
Veeam, Capacity Tier ile yeni backup dosyalarının oluşturulur oluşturulmaz capacity extent’lere kopyalanmasını destekler.
Move Mode
Bu modda inactive backup chain’ler, belirlenen operational restore window dışına çıktığında Performance Tier’dan Capacity Tier’a taşınır.
Veeam dokümantasyonuna göre inactive backup chain’leri Capacity Tier’a taşımak için offload session kullanılır ve bu session otomatik olarak her 4 saatte bir çalışır.
Move Mode kapasite yönetimi açısından faydalıdır. Sık erişilen son backup’lar Performance Tier’da kalırken daha eski ve daha az erişilen veriler object storage’a taşınır. Ancak restore ihtiyacı olduğunda object storage erişim hızı, internet/MPLS bağlantısı, egress maliyeti ve object storage performansı dikkate alınmalıdır.
Capacity Tier Tasarımında Dikkat Edilmesi Gerekenler
Capacity Tier tasarımında sadece “hangi object storage kullanılacak?” sorusu yeterli değildir.
Aşağıdaki başlıklar mutlaka değerlendirilmelidir:
Object storage sağlayıcısı: Amazon S3, Azure Blob, Google Cloud Object Storage, IBM Cloud Object Storage, Wasabi, S3-compatible object storage veya on-prem object storage çözümleri kullanılabilir.
Veeam dokümantasyonunda Capacity Tier için Veeam Data Cloud Vault, S3-compatible, Amazon S3, Azure Blob, Google Cloud Object Storage, IBM Cloud Object Storage, Wasabi ve benzeri object storage seçenekleri listelenir.
Immutability desteği: Object storage tarafında Object Lock veya benzeri immutability özelliği desteklenmeli ve Veeam’e eklenmeden önce doğru yapılandırılmalıdır.
Immutability, repository ayarından ibaret değildir; storage sağlayıcısı tarafında da uyumlu konfigürasyon gerektirir.
Network bant genişliği: Copy Mode kullanılıyorsa backup oluşturulduktan sonra object storage’a sürekli veri aktarımı olacaktır. Bu nedenle internet hattı, VPN/MPLS bağlantısı veya cloud bağlantı kapasitesi planlanmalıdır.
Egress maliyetleri: Cloud object storage’dan geri veri çekmek ücretli olabilir. Bu özellikle büyük felaket kurtarma veya toplu restore senaryolarında ciddi maliyet oluşturabilir.
Bucket/container tasarımı: S3-compatible object storage kullanılıyorsa her SOBR için bucket tasarımı dikkatli yapılmalıdır.
Veeam, bazı S3-compatible object storage repository’lerde her SOBR için birden fazla bucket kullanımını önermediğini ve aynı bucket içinde birden fazla SOBR için farklı folder kullanımının metadata işleme nedeniyle yavaşlığa yol açabileceğini belirtir.
Restore senaryosu: Capacity Tier sadece arşiv alanı gibi düşünülmemelidir. Felaket anında restore yapılabilir olmalıdır.
Veeam dokümantasyonunda Capacity Tier’dan doğrudan restore yapılabileceği ve felaket durumunda SOBR’yi yeniden oluşturmadan object storage backup’larının import edilerek restore edilebileceği belirtilir.
3) Archive Tier
Archive Tier, nadiren erişilen uzun süre saklanacak backup verileri için kullanılan daha düşük maliyetli arşiv katmanıdır.
Capacity Tier’dan farklı olarak restore süreci daha yavaş ve maliyetli olabilir.
Veeam dokümantasyonuna göre Archive Tier; Performance Tier veya Capacity Tier’dan veri alabilir arşivlenen verinin saklama maliyeti daha düşük olabilir ancak restore süresi daha uzun ve restore maliyeti Capacity Tier’a göre daha yüksek olabilir.
Ayrıca Archive Tier’dan restore için verinin önce hazırlanması gerekir.
Archive Tier özellikle şu senaryolarda kullanılır:
- GFS full backup’ların uzun süre saklanması
- Yasal saklama zorunlulukları
- Ayda, çeyrekte veya yılda bir erişilebilecek arşiv verileri
- Maliyeti düşük, erişim süresi daha uzun storage ihtiyacı
- Büyük veri setlerinin uzun vadeli korunması
Veeam Archive Tier için Amazon S3 Glacier, S3-compatible object storage with data archiving ve Microsoft Azure Archive Storage gibi soğuk veri depolama seçeneklerini destekler.
Ayrıca her SOBR için yalnızca bir archive extent eklenebilir.
Archive Tier tasarımında en kritik konu şudur Archive Tier restore için hızlı erişim katmanı değildir. Bu nedenle operasyonel restore ihtiyacı olan veriler Archive Tier’a erken taşınmamalıdır. Restore süresi, retrieval maliyeti, minimum storage duration, encryption ayarları ve compliance gereksinimleri önceden planlanmalıdır.
Immutability: Ransomware’e Karşı Kritik Katman
Modern backup mimarilerinde en önemli konulardan biri backup verisinin sadece alınması değil, saldırı anında korunabilmesidir. Ransomware saldırılarında hedeflerden biri de backup sistemleridir. Saldırganlar backup verisini silmeye, şifrelemeye veya erişilemez hale getirmeye çalışabilir.
Veeam SOBR tarafında immutability, object storage repository’lerdeki verinin belirli süre boyunca silinmesini engelleyen önemli bir güvenlik mekanizmasıdır. Veeam dokümantasyonunda SOBR’ye extent olarak eklenen object storage repository’lerdeki verinin geçici olarak immutable yapılabildiği ve bunun saldırı, malware veya zararlı işlemlerden kaynaklanan veri kaybına karşı koruma sağladığı belirtilir.
Immutability şu katmanlarda kullanılabilir:
- Performance Tier
- Capacity Tier
- Archive Tier
Ancak önemli bir nokta vardır: Object storage repository immutable extent olarak kullanılmadan önce, object storage tarafında immutability desteği ve gerekli ayarlar yapılandırılmış olmalıdır. Yani yalnızca Veeam arayüzünde bir seçenek işaretlemek yeterli değildir; storage sağlayıcısında Object Lock, retention mode, bucket versioning veya ilgili mekanizmalar doğru hazırlanmalıdır.
İmmutability Tasarımında Dikkat Edilecekler
İlk olarak immutability süresi retention politikalarıyla uyumlu olmalıdır. Çok kısa immutability süresi ransomware dayanıklılığını zayıflatabilir. Çok uzun süre ise storage tüketimini ve maliyeti artırabilir.
İkinci olarak, Performance Tier’da birden fazla extent varsa immutability konfigürasyonu tutarlı olmalıdır. Veeam, Performance Tier’da birden fazla extent ve immutability kullanılıyorsa tüm aktif extent’lerde immutability’nin etkin olması gerektiğini belirtir.
Object storage extent’lerden oluşan Performance Tier’da mixed immutability kullanılacaksa mutable veya immutable extent’lerin sealed mode’a alınması gerekir.
Üçüncü olarak, immutability silme işlemine karşı koruma sağlar fakat tek başına bütün güvenlik mimarisi değildir. Backup server erişimleri, MFA, role-based access control, network segmentation, offline/air-gapped kopyalar, ayrı credential kullanımı, Windows/Linux hardening ve düzenli restore testleri de bu mimarinin parçası olmalıdır.
SOBR ile Kullanılabilen Repository Türleri
SOBR tasarımında kullanılabilecek repository türleri şunlardır;
- Microsoft Windows backup repositories
- Linux backup repositories
- SMB/CIFS shared folders
- NFS shared folders
- Deduplicating storage appliances
- Object Storage Repositories
Veeam’in resmi dokümantasyonu bu repository türlerinin SOBR içinde extent olarak kullanılabileceğini belirtir.
Her repository türünün avantajı ve riski farklıdır.
Windows repository’ler kolay yönetilebilir ancak ransomware saldırılarında domain erişimleri ve Windows servis hesapları dikkatle izole edilmelidir.
Linux repository’ler özellikle hardened repository tasarımları için daha güvenli bir yaklaşım sunabilir.
SMB/NFS share’ler kullanım kolaylığı sağlasa da izinler, network erişimi, locking davranışı ve performans dikkatle test edilmelidir.
Deduplication appliance’lar kapasite avantajı sağlayabilir fakat restore ve synthetic operasyon performansı ürüne göre değişebilir.
Object storage ise uzun süreli saklama, cloud offload ve immutability için güçlüdür; ancak latency, API limitleri, egress maliyeti ve metadata tasarımı önemlidir.
SOBR’nin Desteklemediği veya Sınırlı Desteklediği Senaryolar
SOBR çok esnek bir yapı olsa da her job tipi için kullanılmaz.
Veeam dokümantasyonuna göre SOBR aşağıdaki job türleri için hedef olarak kullanılamaz;
- Configuration backup job
- Replication jobs, replica seeding dahil
- VMware vSphere VM copy jobs
- SOBR object storage extent’lerden oluşuyorsa file backup jobs
- SOBR object storage extent’lerden oluşuyorsa object storage backup job
- Cloud machines için backup destination
- Managed mode’da Amazon EC2 veya Microsoft Azure VM gibi cloud machine yedekleyen Veeam Agent for Microsoft Windows/Linux job’ları
Bu limitasyonlar tasarım aşamasında mutlaka kontrol edilmelidir. Çünkü yanlış hedef seçimi, job oluşturma sırasında hata alınmasına veya mevcut repository’nin SOBR’ye eklenememesine neden olabilir.
Genel Limitasyonlar ve Kritik Uyarılar
SOBR kullanırken aşağıdaki limitasyonlar özellikle dikkate alınmalıdır.
Bir repository, unsupported job tiplerine hedef olmuşsa veya unsupported job verisi içeriyorsa doğrudan SOBR extent’i olarak eklenemez. Önce ilgili job’lar başka repository’ye alınmalı ve unsupported veri temizlenmelidir.
SOBR, rotated drives kullanımını desteklemez. Bir extent üzerinde “This repository is backed by rotated hard drives” ayarı etkin olsa bile Veeam bu ayarı yok sayar ve repository’yi standart extent gibi kullanır.
SOBR’ye eklenen bir repository artık normal repository gibi kullanılmamalıdır. Job’lar doğrudan extent’e değil, SOBR’ye hedeflenmelidir.
Bir SOBR başka bir SOBR’ye extent olarak eklenemez. Aynı repository birden fazla SOBR’ye extent olarak eklenemez. Aynı object storage repository de aynı anda iki veya daha fazla farklı SOBR’nin extent’i olarak kullanılamaz.
Üzerinde aktif işlem olan bir repository, örneğin çalışan backup job veya restore task varsa, SOBR extent’i olarak eklenemez. Bu nedenle migration veya SOBR’ye geçiş işlemleri planlı bakım penceresinde yapılmalıdır.
Veeam, bir SOBR içindeki bir tier için 24’ten fazla aktif extent eklenmesini önermemektedir; aksi durumda performans sorunları yaşanabilir.
Veeam Backup & Replication bir backup dosyasını birden fazla extent’e bölmez. Yani tek bir büyük VBK dosyası farklı extent’lere parçalanarak yazılmaz. Bu nedenle extent boyutları, beklenen full backup dosyası boyutlarını karşılayabilecek şekilde tasarlanmalıdır.
VBM dosya adları ve VBM dosya yolları da önemlidir. SOBR rescan sırasında backup’ların otomatik import edilebilmesi için VBM dosya adları ve repository root’tan VBM dosyasına kadar olan path yalnızca izin verilen karakterleri içermelidir; boşluk olmamalıdır. Veeam izin verilen karakterleri alphanumeric karakterler ve _-.+=@^ özel karakterleri olarak belirtir.
Lisans Bazlı Sınırlamalar
SOBR kullanılabilirliği lisansa bağlıdır. Lisans düşürme yapılırsa SOBR’ye hedeflenmiş job’lar çalışmayabilir ancak restore işlemleri yapılabilir. Bu konu özellikle lisans yenileme, edition değişikliği veya VUL dönüşümlerinde gözden kaçırılmamalıdır.
Veeam dokümantasyonuna göre Enterprise edition için SOBR tarafında belirli limitler vardır: 2 adet Scale-Out Backup Repository oluşturulabilir; her SOBR için 3 aktif ve 1 inactive, yani Maintenance Mode’daki performance veya capacity extent kullanılabilir. 4 performance extent eklenir ve hiçbiri Maintenance Mode’a alınmazsa SOBR’ye hedeflenen job’lar başarısız olur. Veeam Universal License ve Enterprise Plus edition’larda ise SOBR sayısı ve performance/capacity extent sayısı açısından bu limitlerin olmadığı belirtilir.
Bu nedenle SOBR tasarımına başlamadan önce mevcut lisans türü, edition, Veeam sürümü ve kullanılacak feature set mutlaka kontrol edilmelidir.
Maintenance Mode, Sealed Mode ve Extent Yönetimi
SOBR’de extent yönetimi operasyonel açıdan önemlidir. Bir extent bakım için devre dışı bırakılacaksa Maintenance Mode kullanılabilir. Eğer extent artık yeni veri kabul etmesin ancak mevcut backup verileri restore için kullanılmaya devam etsin isteniyorsa Sealed Mode değerlendirilebilir.
Örneğin kapasitesi dolan bir extent’e yeni backup yazılmasını istemiyorsanız, extent’i sealed hale getirmek mantıklı olabilir. Eğer extent üzerinde bakım yapılacaksa Maintenance Mode kullanılmalıdır. Eğer extent tamamen kaldırılacaksa, veri tahliyesi yani evacuation planlanmalıdır.
Burada dikkat edilmesi gereken nokta, backup chain bütünlüğüdür. Özellikle Performance Policy kullanılıyorsa full ve incremental dosyalar farklı extent’lerde bulunabilir. Yanlış extent kapatma veya kaldırma işlemi backup chain’i etkileyebilir. Bu nedenle extent kaldırma, bakım veya migration işlemleri öncesinde mutlaka backup chain konumu ve job politikası kontrol edilmelidir.
SOBR ve Restore Operasyonları
SOBR’nin en önemli avantajlarından biri farklı katmanlarda bulunan backup verilerinden restore yapılabilmesidir. Performance Tier en hızlı restore alanıdır. Capacity Tier’dan da restore yapılabilir; ancak object storage performansı ve bağlantı hızı restore süresini etkiler. Archive Tier’dan restore ise daha uzun sürebilir ve veri önce restore için hazırlanmalıdır. Veeam, Archive Tier’daki verinin restore edilmeden önce hazırlanması gerektiğini belirtir.
Bu nedenle SOBR tasarımında yalnızca backup alma performansı değil, restore performansı da planlanmalıdır. Backup sistemi başarılı görünse bile restore testleri yapılmadan tasarım tamamlanmış sayılmaz.
Restore planlamasında şu başlıklar değerlendirilmelidir:
- En kritik sistemler hangi tier’da tutulacak?
- Son kaç günlük backup Performance Tier’da kalacak?
- Capacity Tier’dan restore kabul edilebilir sürede tamamlanıyor mu?
- Archive Tier’dan restore için beklenen süre iş gereksinimiyle uyumlu mu?
- Büyük felaket senaryosunda object storage’dan toplu veri çekme maliyeti nedir?
- Instant Recovery veya bare-metal restore senaryoları test edildi mi?
- SureBackup ile yedek doğrulama yapılacak mı?
Veeam, SOBR’de tutulan backup dosyalarının farklı restore türleri, replication from backup, backup copy job ve SureBackup doğrulama işlemleri için kullanılabileceğini belirtir.
Tasarım Örneği
Orta veya büyük ölçekli bir ortam için örnek SOBR mimarisi şu şekilde olabilir:
Performance Tier:
- 2 adet Linux repository veya Windows ReFS repository
- Yüksek hızlı disk altyapısı
- Günlük backup ve kısa süreli restore ihtiyacı için kullanılır
- Data Locality policy tercih edilir
- Kritik sistemlerin son 14 veya 30 günlük restore point’leri burada tutulur
Capacity Tier:
- S3-compatible immutable object storage veya Azure Blob/Amazon S3
- Copy Mode ile yeni backup’lar object storage’a hızlıca kopyalanır
- Move Mode ile 30 günden eski inactive chain’ler object storage’a taşınır
- Ransomware ve site kaybı senaryoları için ek koruma sağlar
Archive Tier:
- Amazon S3 Glacier, Azure Archive Storage veya desteklenen cold object storage
- GFS monthly/yearly full backup’lar için kullanılır
- Restore süresi uzun olabileceği için operasyonel backup yerine compliance amaçlı değerlendirilir
- Encryption ve retrieval maliyeti önceden planlanır
Bu mimaride en kritik nokta, hangi verinin hangi süreyle hangi tier’da kalacağının net belirlenmesidir. Her veriyi Archive Tier’a hızlıca göndermek doğru değildir. Aynı şekilde tüm eski veriyi Performance Tier’da tutmak da maliyeti artırır. Doğru denge; RPO, RTO, saklama süresi, regülasyon, maliyet ve güvenlik gereksinimlerine göre kurulmalıdır.
Kurulum ve Yapılandırma Öncesi Kontrol Listesi
SOBR oluşturulmadan önce aşağıdaki kontrol listesi kullanılabilir:
Lisans kontrolü: Mevcut Veeam lisansı SOBR, Capacity Tier, Archive Tier ve immutability özelliklerini destekliyor mu?
Sürüm kontrolü: Kullanılan Veeam Backup & Replication sürümü hedeflenen repository ve object storage özelliklerini destekliyor mu?
Repository hazırlığı: SOBR’ye eklenecek Windows/Linux/NFS/SMB/object repository’ler Veeam Backup Infrastructure içine doğru şekilde eklenmiş mi?
Kapasite planlaması: Günlük incremental büyüme, haftalık full/synthetic full, GFS retention ve yıllık büyüme hesaplandı mı?
Performans planlaması: Disk throughput, IOPS, CPU, RAM, gateway server ve network kapasitesi yeterli mi?
Placement policy: Data Locality mi, Performance mı kullanılacak? Performance seçilecekse tüm extent’lerin sürekli erişilebilirliği garanti mi?
Immutability: Object storage tarafında immutability destekleniyor ve doğru yapılandırıldı mı?
Security: Repository erişimleri izole edildi mi, MFA/RBAC kullanılıyor mu, domain admin bağımlılığı azaltıldı mı?
Network: Capacity Tier ve Archive Tier veri transferleri için bant genişliği yeterli mi?
Maliyet: Cloud storage, API request, egress, archive retrieval ve minimum saklama süreleri hesaplandı mı?
Restore testi: Performance, Capacity ve Archive Tier’dan restore testleri yapıldı mı?
Sık Yapılan Hatalar
SOBR tasarımında en sık yapılan hatalardan biri, SOBR’yi yalnızca “kapasite birleştirme” aracı gibi görmektir. Oysa SOBR; performans, saklama politikası, güvenlik, object storage entegrasyonu ve restore stratejisini birlikte etkileyen bir mimaridir.
Bir diğer hata, Capacity Tier’ın otomatik olarak “ucuz ve risksiz” kabul edilmesidir. Object storage maliyeti sadece saklama ücretinden ibaret değildir. API çağrıları, veri okuma, egress, archive retrieval ve minimum storage duration maliyetleri toplam maliyeti ciddi şekilde değiştirebilir.
Üçüncü hata, Archive Tier’dan hızlı restore beklemektir. Archive Tier düşük maliyetli uzun süreli saklama için uygundur; operasyonel restore için tasarlanmamalıdır.
Dördüncü hata, immutability ayarlarının retention politikalarıyla uyumsuz yapılmasıdır. Çok kısa süre koruma sağlamaz; çok uzun süre ise silinemeyen veri nedeniyle kapasite ve maliyet baskısı oluşturur.
Beşinci hata, Performance Policy seçilip extent erişilebilirliğinin yeterince güvence altına alınmamasıdır. Full ve incremental dosyaların farklı extent’lerde olduğu senaryolarda bir extent kaybı chain bütünlüğünü etkileyebilir.
Altıncı hata, backup dosyasının extent’lere bölüneceğini varsaymaktır. Veeam tek bir backup dosyasını birden fazla extent’e bölmez. Bu nedenle extent kapasitesi büyük full backup dosyalarını karşılayacak şekilde planlanmalıdır.
Güvenlik Açısından Öneriler
SOBR güvenliğini artırmak için aşağıdaki prensipler uygulanmalıdır:
- Backup server domain admin hesabıyla günlük yönetilmemelidir.
- Repository erişimleri minimum yetki prensibine göre verilmelidir.
- Linux repository veya object storage immutability seçenekleri değerlendirilmelidir.
- Capacity Tier’da mümkünse immutable object storage kullanılmalıdır.
- Backup infrastructure ağı production ağından segmentlere ayrılmalıdır.
- MFA ve RBAC kullanılmalıdır.
- Backup configuration backup ayrıca güvenli bir alana alınmalıdır.
- Restore testleri düzenli yapılmalıdır.
- Veeam console erişimleri loglanmalı ve izlenmelidir.
- Repository silme ve retention değişiklikleri için change management uygulanmalıdır.
Unutulmamalıdır ki immutability çok güçlü bir koruma katmanıdır fakat tek başına yeterli değildir. Saldırgan backup server üzerinde yetki elde ederse job ayarlarını değiştirebilir, retention politikalarını bozabilir veya gelecekteki backup zincirlerini etkileyebilir. Bu nedenle backup altyapısı ayrı bir güvenlik alanı olarak ele alınmalıdır.
SOBR Kullanımında En İyi Pratikler
SOBR tasarımında genel olarak aşağıdaki iyi uygulamalar önerilir:
Öncelikle, mümkünse basit bir tasarımla başlayın. Karmaşık placement policy, çok sayıda extent ve birden fazla object storage sağlayıcısı ilk aşamada yönetimi zorlaştırabilir.
İkinci olarak, kritik restore ihtiyacı olan verileri Performance Tier’da yeterli süre tutun. Capacity Tier ve Archive Tier maliyet avantajı sağlar ancak restore süreleri ve maliyetleri farklıdır.
Üçüncü olarak, object storage kullanırken her SOBR için bucket/container tasarımını sade tutun. Özellikle S3-compatible ortamlarda metadata işleme ve bucket tasarımı performansı etkileyebilir.
Dördüncü olarak, immutability’yi sadece işaretlenen bir seçenek olarak değil, uçtan uca güvenlik mimarisinin parçası olarak değerlendirin.
Beşinci olarak, extent sayısını kontrol altında tutun. Çok fazla extent yönetim ve performans karmaşıklığı yaratabilir. Veeam, bir tier içinde 24’ten fazla aktif extent kullanılmasını önermemektedir.
Altıncı olarak, lisans limitlerini tasarımın en başında kontrol edin. Özellikle Enterprise edition kullanılıyorsa SOBR ve extent limitleri mimariyi doğrudan etkileyebilir.
Yedinci olarak, her değişiklikten sonra restore testi yapın. Repository ekleme, Capacity Tier etkinleştirme, Archive Tier yapılandırma veya immutability değişiklikleri sonrasında sadece backup job başarılarını değil, restore kabiliyetini de doğrulayın.
Veeam Scale-Out Backup Repository, büyüyen backup ihtiyaçları için güçlü ve esnek bir mimari sunar. Tekil repository yönetiminin sınırlarını aşarak birden fazla storage kaynağını tek bir mantıksal yapı altında birleştirir. Performance Tier ile hızlı backup ve restore, Capacity Tier ile uzun süreli object storage saklama, Archive Tier ile düşük maliyetli arşivleme ve immutability ile ransomware dayanıklılığı sağlanabilir.
Ancak SOBR doğru tasarlanmadığında performans sorunları, restore gecikmeleri, lisans limitleri, object storage maliyetleri ve backup chain karmaşıklığı gibi problemler ortaya çıkabilir. Bu nedenle SOBR yalnızca “disk alanını büyütme” çözümü olarak değil; kapasite, performans, güvenlik, maliyet, lisans ve felaket kurtarma hedeflerini birlikte yöneten stratejik bir backup mimarisi olarak ele alınmalıdır.
Başarılı bir SOBR tasarımı için en kritik prensip şudur Backup almak kadar, doğru zamanda doğru veriyi geri döndürebilmek de planlanmalıdır. SOBR’nin gerçek değeri, backup verisini farklı katmanlarda akıllıca konumlandırırken, ihtiyaç anında güvenilir ve test edilmiş restore kabiliyeti sunmasında ortaya çıkar.
Kaynak :
