ZFS snapshot ve uzaktan replikasyon ile sıfır veri kaybına yakın yedekleme: Copy-on-Write, artımlı aktarım (ZFS Send/Receive) ve kurtarma rehberi. İnceleyin.
Hızlı Özet (TL;DR)
Geleneksel yedekleme yöntemleri (günlük veya gecelik imaj alma), mesai saatleri içinde saat 16:30’da meydana gelen bir sunucu çökmesinde veya fidye yazılımı saldırısında sabahtan akşama kadar girilen tüm irsaliye, fatura, kalite kontrol ve üretim verilerinin kaybolmasına yol açar (RPO süresi 24 saattir). OpenZFS dosya sisteminin Copy-on-Write (CoW) mimarisi ve ZFS Send/Receive blok replikasyon yeteneği sayesinde; canlı çalışan sistemlerde sıfır performans kaybıyla her 5 dakikada bir anlık görüntü (Snapshot) alınabilir ve bu görüntüler saniyeler içinde ikincil bir yedekleme sunucusuna replike edilebilir.
Klasik Yedekleme ve Sanal Makine Snapshot’ları Neden Sistemi Yavaşlatır?
VMware, Hyper-V veya klasik LVM yapılarında çalışan bir sanal makinenin yedekleme sırasında anlık görüntüsü (Snapshot) alındığında, hipervizör ana disk dosyasını dondurur ve yeni gelen yazma işlemlerini ayrı bir fark (Delta) dosyasına yönlendirir. Yedekleme bittiğinde ise bu fark dosyasının ana diske birleştirilmesi (Consolidation / Merge) sırasında disk I/O performansı ağır darbe alır ve veritabanları saniyelerce kilitlenir (Stun).
Bu performans cezası nedeniyle sistem yöneticileri mesai saatleri içinde yedek alamaz; yedeklemeyi yalnızca gece 02:00’ye planlamak zorunda kalır. ZFS (Zettabyte File System) ise geleneksel dosya sistemlerinin ve donanımsal RAID kartlarının çalışma mantığını tamamen değiştirerek bu darboğazı ortadan kaldırır.
ZFS Copy-on-Write (CoW) Mimarisi Nasıl Çalışır?
ZFS’te disk üzerindeki aktif bir veri bloğunun üzerine asla doğrudan yazılmaz. Bir ERP veritabanı veya CAD dosyası üzerindeki 128 KB’lık bir blok değiştiğinde:
- ZFS yeni veriyi diskteki boş bir alana yazar.
- Dosya ağacındaki (Merkle Tree) işaretçiyi (Pointer) eski bloktan yeni bloğa yönlendirir.
- Eğer o an bir ZFS Snapshot mevcutsa, ZFS eski bloğu silmez; sadece salt okunur (Read-Only) olarak referans göstermeye devam eder.
Bu mimari sayesinde 50 Terabaytlık bir veri havuzunun (zpool) ZFS Snapshot’ını almak 0 milisaniye sürer, başlangıçta 0 bayt yer kaplar ve disk üzerinde hiçbir birleştirme (merge) yükü oluşturmaz. Bu sayede gün içinde her 5 veya 15 dakikada bir snapshot almak sistem performansını zerre kadar etkilemez.
| Yedekleme Kriteri | Geleneksel Gecelik İmaj Yedeği | Rsync / Dosya Bazlı Senkronizasyon | ZFS Snapshot & Send/Receive Replikasyonu |
|---|---|---|---|
| RPO (Maksimum Veri Kaybı) | 24 Saat (Tüm günün emeği kaybolur) | 1 – 4 Saat | 1 – 5 Dakika (Sıfır veri kaybına yakın) |
| Değişen Veriyi Bulma Süresi | Tüm diski veya CBT tablosunu okur | Milyonlarca dosyayı tek tek tarar (Yavaş) | Sıfır Tarama Süresi (Blok ağacından anında bilir) |
| Canlı Sistem I/O Etkisi | Yüksek (Snapshot birleştirme sancısı) | Yüksek (Metadata ve inode okuma yükü) | Sıfıra Yakın (Doğal Copy-on-Write akışı) |
| RTO (Geri Dönüş Süresi) | Saatler (Arşivden çıkarma ve kopyalama) | Saatler (Dosyaları geri kopyalama) | Saniyeler (zfs rollback veya zfs clone) |
| Sessiz Veri Bozulması (Bit Rot) | Bozuk veriyi fark etmeden yedekler | Bozuk dosyayı hedefe kopyalar | SHA-256 Checksum ile bozulmayı anında onarır |
ZFS Send / Receive ile Blok Seviyesinde Artımlı Replikasyon
Yalnızca ana sunucu üzerinde snapshot almak, ana sunucunun fiziksel olarak yanması durumunda veriyi kurtarmaz. Alınan snapshot’ların fabrikanın farklı bir yangın zonundaki veya uzak şubedeki ikincil bir ZFS sunucusuna (TrueNAS / Proxmox Backup / Linux ZFS) aktarılması gerekir.
1. İlk Tam Eşleme (Initial Base Stream)
Ana depolama havuzundaki veri kümesinin (tank/uretim_veritabani@snap1) ilk hali ikincil sunucuya tam akış olarak gönderilir.
2. Saniyelik Artımlı Blok Gönderimi (Incremental Stream)
Beş dakika sonra ikinci snapshot (@snap2) alındığında, zfs send -i @snap1 @snap2 komutu devreye girer. ZFS milyonlarca dosyayı taramakla vakit kaybetmez; iki snapshot arasındaki blok doğum zamanlarını (Transaction Group - TXG) bildiği için yalnızca o 5 dakika içinde değişen birkaç megabaytlık bloğu LZ4/Zstd sıkıştırmalı olarak SSH tüneli üzerinden hedef sunucuya akıtır.
3. Fidye Yazılımına Karşı İzole ve Salt Okunur Hedef
Hedef yedekleme sunucusu, ana sunucuya yazma izni vermez; tam tersine yedekleme sunucusu kendi üzerinden bağlanarak (Pull Replication) veriyi çeker veya kısıtlı yetkili (zfs allow) özel bir hesap kullanır. Ayrıca ikincil sunucudaki tüm snapshot’lar Salt Okunur (Read-Only) olduğu ve SMB/NFS üzerinden son kullanıcılara paylaşılmadığı için, şirket ağına sızan bir fidye yazılımı bu snapshot’ları şifreleyemez.
Felaket Anında Kurtarma: Dakikalar İçinde Hayata Dönüş
ZFS mimarisinin gerçek gücü felaket anındaki geri dönüş hızında (RTO) ortaya çıkar:
- Senaryo 1 (Fidye Yazılımı veya Yanlışlıkla Silme): Saat 14:22’de dosya sunucusundaki tüm dosyalar şifrelendi veya bir veritabanı tablosu silindi. Sistem yöneticisi tek bir komutla (
zfs rollback tank/ortak@14_20) 50 TB’lık veri kümesini saat 14:20’deki sağlam haline 2 saniye içinde geri döndürür. - Senaryo 2 (Ana Sunucunun Tamamen Yanması): Ana sunucu donanımsal olarak kül olduğunda, ikincil odadaki ZFS yedekleme sunucusu üzerindeki son replike edilen snapshot anında yazılabilir bir klona (
zfs clone) dönüştürülür ve sanallaştırma kümesine bağlanarak işletme dakikalar içinde çalışmaya devam eder.
Ağ üzerinden şubeler arası yapılan ZFS replikasyon trafiğinin güvenliği Güvenlik Duvarı Hizmetleri üzerindeki donanımsal IPsec/WireGuard VPN tünelleriyle korunurken, veri bütünlüğü ve erişim denetimi DLP Veri Sızıntısı Önleme standartlarıyla güvenceye alınır.
Kurumunuz için sıfır veri kaybına yakın ZFS depolama ve replikasyon mimarisi kurulumu hakkında detaylı bilgi için Sunucu ve Yedekleme Altyapısı sayfamızı inceleyebilirsiniz.
Sıkça Sorulan Sorular
Her 5 dakikada bir snapshot alırsak disklerimiz birkaç gün içinde tamamen dolmaz mı?
Hayır. ZFS snapshot’ları verinin tam bir kopyasını oluşturmaz; yalnızca değişen blokların farkını tutar. Eğer 10 TB’lık bir dosya sunucusunda 5 dakika içinde yalnızca 50 MB’lık Excel ve CAD dosyası değiştiyse, alınan snapshot diskte sadece 50 MB yer kaplar. Ayrıca otomatik yaşam döngüsü (Retention / Pruning) kuralları sayesinde; 5 dakikalık snapshot’lar 24 saat, saatlik snapshot’lar 7 gün, günlük snapshot’lar 30 gün ve aylık snapshot’lar 1 yıl tutularak eski görüntüler otomatik temizlenir.
Ancak bir fidye yazılımı sunucudaki tüm dosyaları şifrelerse değişim boyutu çok büyüyeceği için eski snapshot’lar silinir mi?
Çok kritik bir mühendislik sorusudur. Eğer fidye yazılımı 10 TB verinin tamamını şifrelerse, tüm bloklar değiştiği için yeni yazılan şifreli veriler ekstra 10 TB alan talep eder. ZFS varsayılan olarak mevcut snapshot’ları asla kendiliğinden silmez; bunun yerine disk dolduğunda yeni yazma işlemlerini durdurur (yani fidye yazılımı diski doldurduğu anda kilitlenir ama eski sağlam snapshot’lar korunur). Ayrıca veri kümelerine refquota uygulanarak aktif alanın snapshot alanını tüketmesi kesin olarak engellenir.
ZFS dosya sistemi için ECC RAM kullanmak zorunlu mudur?
ZFS yüksek performans için sistem belleğini (ARC - Adaptive Replacement Cache) yoğun şekilde kullanır ve tüm veri bütünlüğü özetlerini (Checksum) RAM üzerinde hesaplar. Standart (Non-ECC) belleklerde nadir de olsa oluşan tek bitlik kozmik/elektriksel kaymalar (Bit Flip) verinin bozuk yazılmasına neden olabilir. Bu nedenle kurumsal üretim ortamlarında ZFS sunucularını her zaman ECC (Error-Correcting Code) bellekli kurumsal sunucu donanımları üzerinde konumlandırıyoruz.