Yedek Depolama Kapasitesi Nasıl Hesaplanır? Saklama ve GFS

Yedek deposu alınırken sahada en sık gördüğümüz hesap şudur: kaynak veri 10 TB, “üç katını alalım”, 30 TB. Bir yıl sonra aylık GFS noktaları biriktiğinde depo dolar, gece işleri yetersiz boş alan hatasıyla düşmeye başlar. Gerçek ihtiyaç yedek zinciri türüne, günlük değişim oranına, saklama politikasına, veri azaltma oranına ve dosya sisteminin blok klonlama desteğine göre katlarca farklı çıkar. Aşağıda bu değişkenleri, örnek bir hesap tablosunu ve kapasiteyi sonradan izleme yöntemini adım adım veriyoruz.

Kapasiteyi belirleyen değişkenler

Bir yedek deposunun boyutu beş girdiyle hesaplanır. Birini atlarsanız sonuç yanlış çıkar.

• Kaynak veri boyutu: VM disklerinin ayrılmış boyutu değil, kullanılan blok miktarı. İnce (thin) diskli ortamlarda aradaki fark ciddi boyutlara ulaşır.
• Günlük değişim oranı: Bir yedek aralığında değişen tekil blok miktarı. Artımlı yedeklerin boyutunu doğrudan belirler.
• Veri azaltma oranı: Sıkıştırma ve iş içi tekilleştirmenin birlikte sağladığı küçülme. Veri tipine göre çok değişir; zaten sıkıştırılmış medya, şifreli dosyalar ve veritabanı yedek dosyaları neredeyse hiç küçülmez.
• Saklama politikası: Kısa süreli kurtarma noktası sayısı ve GFS (haftalık, aylık, yıllık) tam yedek sayısı.
• Yedek zinciri ve dosya sistemi: Sentetik tam yedeklerin fiziksel olarak yer kaplayıp kaplamadığını belirler.

Üstüne büyüme payı ve çalışma alanı (birleştirme işlemleri sırasında geçici olarak gereken boş alan) eklenir. Çalışma alanını unutan depo, birleştirme sırasında dolar.

Değişim oranını ölçme

Hesabı en çok oynatan girdi değişim oranıdır. Tahmin etmeyin; mevcut sunucu ve sistem altyapısında ölçün. Pratik yöntemler:

1. Mevcut yedek işlerinin geçmişi: En güvenilir kaynaktır. Son iki–dört haftadaki artımlı yedeklerin “transferred” (aktarılan) boyutlarını, veri azaltma öncesi ve sonrası değerleriyle birlikte not edin. Hafta sonu ve ay sonu kapanışı gibi uç günlere ayrıca bakın; ortalamayı değil tepeyi karşılayacak alan gerekir.
2. Hipervizör değişen blok takibi: VMware CBT ve Hyper-V RCT, değişen blokları izler; yedek yazılımı bu bilgiyle artımlı boyutu hesaplar. Henüz yedek yoksa kısa bir deneme işi çalıştırmak, haftalarca performans sayacı izlemekten daha doğru sonuç verir.
3. Raporlama araçları: Veeam ONE gibi izleme ürünlerinde VM değişim oranı tahmin raporları bulunur.

Disk yazma sayaçları (örneğin Windows’ta LogicalDisk\Disk Write Bytes/sec) değişim oranını olduğundan yüksek gösterir. Aynı blok gün içinde yüz kez yazılsa da artımlı yedekte bir kez yer kaplar. Bu sayaçlar yalnızca üst sınırdır.

Yedek zinciri türleri ve depolamaya etkisi

Aynı saklama politikası, farklı zincir türlerinde farklı alan kaplar ve depoya farklı I/O yükü bindirir. Zincir türünü seçmeden kapasite hesabı yapılmaz.

Sentetik tam yedek, depodaki mevcut tam ve artımlı dosyalardan yeni bir tam dosya inşa eder. Klasik bir dosya sisteminde (NTFS, reflink kapalı ext4/XFS) bu, verinin fiziksel olarak kopyalanması demektir: hem saatler sürer hem de her sentetik tam, tam yedek boyutunda yer kaplar. Aktif tam yedek ise zinciri kaynaktan yeniden başlatır. Sessiz veri bozulmasına karşı bağımsız bir kopya üretir, karşılığında kaynak sistemi ve ağı yorar. Bedava değildir.

GFS saklama politikası

GFS (Grandfather-Father-Son) yaklaşımı, kısa süreli günlük kurtarma noktalarının yanına seyrekleşen uzun süreli tam yedekler ekler. Tipik bir politika: 14 günlük kurtarma noktası, 4 haftalık, 12 aylık ve birkaç yıllık tam yedek. Kapasite hesabını iki nokta belirler:

• GFS noktaları tam yedektir; artımlı olarak saklanmazlar. Blok klonlama yoksa her biri tam yedek boyutunda yer kaplar.
• Uzun süreli noktaları birincil depoda tutmak zorunlu değildir. Aylık ve yıllık noktalar genellikle ikincil depoya, nesne depolamaya veya teybe kopyalanır. Bu katmanın ortam seçimi LTO teyp ve nesne depolama karşılaştırması yazısında ele alınıyor.

Saklama sürelerini sistem ekibi kendi başına seçmez; kurumsal saklama politikası ve mevzuat belirler. “Ne olur ne olmaz, yedi yıl tutalım” yaklaşımı da hatadır: gereğinden uzun saklamak hem disk maliyeti hem de kişisel verinin saklama süresi yükümlülükleri açısından sorun yaratabilir.

Örnek hesap tablosu

Aşağıdaki örnek hesap varsayımlara dayanır: 10 TB kullanılan kaynak veri, 2:1 veri azaltma, günlük değişim oranı %3, 14 günlük kurtarma noktası, 4 haftalık + 12 aylık + 3 yıllık GFS. Blok klonlamalı senaryoda her GFS tam yedeğinin yalnızca bir önceki saklanan tamdan bu yana değişen tekil blokları yer kapladığı varsayılmıştır (haftalık 0,5 TB, aylık 1,2 TB, yıllık 2,5 TB; azaltılmış boyut).

Veeam’de aynı tam yedek birden çok GFS bayrağı taşıyabilir (örneğin ayın son haftalık tamı aynı zamanda aylık nokta olur); bu çakışma yüzünden gerçek tüketim tablodaki değerden biraz düşük çıkabilir. Tablo güvenli tarafta kalan bir üst tahmindir. Sonuca birleştirme ve geçici işlemler için çalışma alanı eklenir. Depo kullanımı için kurum içinde bir üst eşik tanımlayın (örneğin dolulukta %80) ve satın alınacak brüt kapasiteyi bu eşiğe göre belirleyin. RAID veya erasure coding koruma payı da brüt kapasiteye ayrıca eklenmelidir: 12 diskli RAID 6’da iki diskin kapasitesi parite için kullanılır.

Tablo iki şeyi gösteriyor. GFS içeren politikalarda blok klonlama kapasiteyi kat kat düşürür. Klonlama olmayan ortamda ise en etkili tasarruf, uzun süreli noktaları birincil depodan çıkarmaktır. Örnekte fark yaklaşık 102 TB ile 31 TB arasında.

Blok klonlama ve tekilleştirme

Windows Server’da ReFS ve Linux’ta reflink destekli XFS, aynı veriyi fiziksel olarak kopyalamadan yeni bir dosyanın bloklarına referans verebilir. Veeam bu özelliği “Fast Clone” adıyla kullanır: sentetik tam yedek oluşturmak ve artımlıları birleştirmek, veri taşımak yerine meta veri işlemine dönüşür. Saatler süren birleştirme dakikalara iner, yer de kazanılır.

Burada sahada en sık gördüğümüz hata, depo birimini varsayılan 4 KB küme boyutuyla biçimlendirip sonradan fark etmektir; küme boyutu sonradan değişmez, birim yeniden biçimlendirilir. Veeam’in ReFS için önerdiği 64 KB küme boyutu ve XFS için reflink ile biçimlendirme örnekleri:

# Windows Server – ReFS, 64 KB küme
Format-Volume -DriveLetter E -FileSystem ReFS -AllocationUnitSize 65536 -NewFileSystemLabel "VeeamRepo"
fsutil fsinfo refsinfo E:

# Linux – reflink açık XFS
mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb
xfs_info /mnt/veeamrepo | grep reflink

Blok klonlamanın sınırları:

• Tasarruf yalnızca aynı birim içinde geçerlidir. Yedekler başka bir depoya kopyalandığında veya taşındığında bloklar yeniden fiziksel olarak yazılır.
• Aktif tam yedek klonlanmaz; her aktif tam fiziksel olarak tam boyutta yer kaplar.
• Dosya boyutları toplamı gerçek kullanımı göstermez. Linux’ta du paylaşılan blokları her dosyada ayrı sayar; doğru değer için df ile birimin boş alanına bakın. Windows’ta da dosya özellikleri yerine birim boş alanı esas alınmalıdır.

Donanım tekilleştirme cihazları ise yedek dosyalarındaki tekrar eden blokları global olarak azaltır. Uzun saklama süreli GFS politikalarında belirgin tasarruf sağlayabilir; ama geri yükleme sırasında veriyi yeniden oluşturma (rehydration) maliyeti RTO’yu uzatır. Yazmak hızlı, okumak yavaş. Hızlı geri dönüş gereken son kurtarma noktalarını klasik bir depoda, uzun süreli noktaları tekilleştirme cihazında tutmak yaygın bir katmanlama yöntemidir. İşletim sistemi düzeyinde tekilleştirmeyi yedek dosyaları üzerine eklemeden önce yedek yazılımı üreticisinin destek durumunu kontrol edin.

Büyüme payı ve izleme

Kapasite hesabı satın alma günü doğrudur, altı ay sonra değildir. Planı gerçek kullanımla düzenli karşılaştırın:

• Aylık olarak depo doluluğunu, tam ve artımlı yedek boyutlarını ve gerçekleşen veri azaltma oranını kaydedin.
• Yeni sistem devreye alındığında, özellikle büyük veritabanı veya dosya sunucusu eklendiğinde, hesabı güncelleyin.
• Doluluk eşiğine ulaşmadan alarm üreten bir izleme kuralı tanımlayın. Dolan depo, o geceden itibaren yedek yok demektir.
• Birden çok depo kullanılıyorsa yerleşim politikasını ve uzantı kapasitelerini birlikte izleyin; ölçeklenebilir depo tasarımı Veeam proxy ve repository mimarisi yazısında anlatılıyor.

Hesap kontrol listesi

• Kaynak boyutu kullanılan blok üzerinden mi alındı?
• Değişim oranı sistem tipine göre ölçüldü mü, uç günler dahil edildi mi?
• Veri azaltma oranı gerçek iş geçmişinden mi geliyor?
• GFS noktalarının hangi depoda tutulacağı kararlaştırıldı mı?
• Dosya sistemi blok klonlamayı destekliyor ve doğru biçimlendirildi mi?
• İkinci ve üçüncü kopya (dış konum, değiştirilemez kopya) ayrıca hesaplandı mı?
• RAID/erasure coding payı, çalışma alanı ve doluluk eşiği brüt kapasiteye eklendi mi?

Kopya sayısı ve konum gereksinimleri için 3-2-1-1-0 yedekleme kuralı, küçük ortamlarda ücretsiz başlangıç için Veeam Community Edition yazılarına bakabilirsiniz. Depo donanımını seçip boyutlandırırken donanım danışmanlığı ve yedekleme ve felaket kurtarma sayfalarımızda nasıl çalıştığımızı görebilirsiniz. ReFS blok klonlamanın çalışma şekli Microsoft’un ReFS block cloning belgesinde anlatılır.

Sık sorulan sorular

Yedek deposu için kaynak verinin kaç katı kapasite gerekir?

Sabit bir çarpan yoktur. Değişim oranı, veri azaltma oranı, GFS saklama politikası ve blok klonlama desteğine göre aynı kaynak veri için gereken kapasite birkaç kat farklı çıkar. Bu değişkenlerle örnek hesap yapın.

Günlük değişim oranı nasıl ölçülür?

En güvenilir yöntem, mevcut yedek işlerinin son birkaç haftalık artımlı yedek boyutlarına bakmaktır. Yedek yoksa kısa bir deneme işi çalıştırın. Disk yazma sayaçları aynı bloğun tekrar yazılmasını da saydığı için değişim oranını olduğundan yüksek gösterir.

ReFS veya XFS blok klonlama ne kadar yer kazandırır?

Sentetik tam yedekler ve birleştirme işlemleri veri kopyalamak yerine blok referansı oluşturduğu için GFS tam yedekleri yalnızca değişen tekil bloklar kadar yer kaplar. Kazanç saklama politikasına bağlıdır ve yalnızca aynı birim içinde geçerlidir.

GFS yedekleri birincil depoda mı tutulmalı?

Zorunlu değildir. Aylık ve yıllık noktalar genellikle ikincil depoya, nesne depolamaya veya teybe kopyalanır. Hızlı birincil depo kısa süreli geri dönüşe ayrılır, kapasite maliyeti düşer.