BTRFS ve ZFS Snapshot Karşılaştırması: Hangisi Daha İyi?

Tarafındankomut
0 Comments

Yedekleme dünyasında snapshot teknolojisi, modern sistem yöneticilerinin vazgeçilmez araçlarından biri haline geldi. “Bir şeyler ters giderse geri dönebilir miyim?” sorusunun cevabı artık büyük ölçüde kullandığınız dosya sistemine bağlı. BTRFS ve ZFS, bu alanda en güçlü iki oyuncu olarak öne çıkıyor ve her ikisi de Copy-on-Write (CoW) mimarisi üzerine inşa edilmiş olmalarına rağmen, pratikte oldukça farklı deneyimler sunuyorlar. Bu yazıda her iki sistemi gerçek dünya senaryoları üzerinden karşılaştıracağız, hangi durumda hangisinin daha iyi seçenek olduğunu konuşacağız.

Temel Fark: Snapshot Nasıl Çalışıyor?

Her iki sistemde de snapshot mantığını anlamadan karşılaştırma yapmak sağlıklı olmaz. Copy-on-Write mimarisinde, bir blok değiştirildiğinde orijinal blok yerinde bırakılır ve yeni veri farklı bir konuma yazılır. Snapshot, bu orijinal blokların referanslarını tutan bir işaretçi tablosu gibi düşünülebilir.

BTRFS tarafında subvolume kavramı merkezi öneme sahiptir. Her snapshot aslında bir subvolume’dür ve başka bir subvolume’ün anlık görüntüsüdür. Bu yapı, BTRFS’in Linux çekirdeğine entegre olması sayesinde herhangi bir ek araç kurmadan kullanılabilmesini sağlar.

ZFS tarafında ise pool, dataset ve snapshot hiyerarşisi vardır. ZFS snapshot’ları salt okunurdur ve clone işlemiyle yazılabilir hale getirilebilir. ZFS’in en büyük gücü, bu hiyerarşiyi tutarlı ve öngörülebilir biçimde yönetmesidir.

BTRFS Snapshot: Hızlı Başlangıç

Önce BTRFS tarafına bakalım. Debian veya Ubuntu tabanlı bir sistemde BTRFS kullanıyorsanız, snapshot almak gerçekten iki dakikalık iş.

# Mevcut subvolume'leri listele
btrfs subvolume list /

# Yeni bir snapshot al (salt okunur)
btrfs subvolume snapshot -r /home /home_snapshots/home_$(date +%Y%m%d_%H%M%S)

# Yazılabilir snapshot al (dikkatli kullanın)
btrfs subvolume snapshot /home /home_snapshots/home_writable_$(date +%Y%m%d_%H%M%S)

# Snapshot'ları listele
btrfs subvolume list -s /

Burada -r flag’i önemli: salt okunur snapshot oluşturur ve bu, yedekleme amaçlı kullanımda tercih edilmesi gereken seçenektir. Yazılabilir snapshot’lar test ortamları için kullanışlı olsa da yanlışlıkla değiştirme riskini beraberinde getirir.

Bir senaryoyu düşünelim: Geliştirici ekibiniz production veritabanı sunucusunda schema migration yapmak istiyor. Gece yarısı operasyonu. Bir şeyler ters giderse ne yapacaksınız?

#!/bin/bash
# pre-migration snapshot scripti
SNAPSHOT_DIR="/mnt/btrfs_snapshots"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
SUBVOL="/var/lib/postgresql"

echo "Migration öncesi snapshot alınıyor..."
btrfs subvolume snapshot -r "$SUBVOL" "${SNAPSHOT_DIR}/postgres_pre_migration_${TIMESTAMP}"

if [ $? -eq 0 ]; then
    echo "Snapshot başarıyla alındı: postgres_pre_migration_${TIMESTAMP}"
    echo "Migration başlayabilir."
else
    echo "HATA: Snapshot alınamadı! Migration iptal ediliyor."
    exit 1
fi

Migration başarısız olursa geri dönüş:

# Snapshot'tan geri yükleme
SNAPSHOT_PATH="/mnt/btrfs_snapshots/postgres_pre_migration_20240115_230000"

# Mevcut subvolume'ü sil (ya da taşı)
mv /var/lib/postgresql /var/lib/postgresql_broken

# Snapshot'tan yazılabilir kopya oluştur
btrfs subvolume snapshot "$SNAPSHOT_PATH" /var/lib/postgresql

echo "Geri yükleme tamamlandı."

ZFS Snapshot: Kurumsal Güç

ZFS tarafına geçelim. ZFS’i Linux’ta kullanmak için OpenZFS projesi gerekiyor ve Ubuntu 20.04+ üzerinde apt install zfsutils-linux ile kurulabiliyor.

# ZFS pool oluştur (örnek: iki disk ile mirror)
zpool create mypool mirror /dev/sdb /dev/sdc

# Dataset oluştur
zfs create mypool/postgresql
zfs create mypool/home

# Snapshot al
zfs snapshot mypool/postgresql@pre_migration_$(date +%Y%m%d_%H%M%S)

# Tüm snapshot'ları listele
zfs list -t snapshot

# Belirli bir dataset'in snapshot'larını listele
zfs list -t snapshot -o name,creation,used mypool/postgresql

ZFS snapshot’larının en çarpıcı özelliği recursive snapshot desteğidir. Birden fazla dataset’i aynı anda tutarlı biçimde snapshot almak mümkün:

# Tüm alt dataset'leri dahil ederek recursive snapshot
zfs snapshot -r mypool@nightly_$(date +%Y%m%d)

# Snapshot'tan geri yükleme (rollback)
zfs rollback mypool/postgresql@pre_migration_20240115_230000

# Eğer aralarında başka snapshot'lar varsa -r ile hepsini sil
zfs rollback -r mypool/postgresql@pre_migration_20240115_230000

ZFS rollback operasyonu BTRFS’e kıyasla çok daha temiz ve kontrollüdür. zfs rollback komutu dataset’i direkt olarak belirtilen snapshot haline getirir. Ancak dikkat: rollback yapılan snapshot’tan sonra oluşturulan tüm snapshot’lar silinir (aksi belirtilmedikçe).

BTRFS Send/Receive ile Uzak Yedekleme

BTRFS’in güçlü yanlarından biri btrfs send ve btrfs receive komutlarıdır. Bu özellik, snapshot’ları uzak bir sunucuya kademeli (incremental) olarak göndermeyi sağlar.

#!/bin/bash
# BTRFS incremental remote backup scripti
REMOTE_HOST="backup-server.example.com"
REMOTE_USER="backup"
REMOTE_PATH="/backup/snapshots"
LOCAL_SUBVOL="/home"
SNAPSHOT_DIR="/mnt/snapshots"
PREV_SNAPSHOT=""

# Önceki snapshot'ı bul
PREV_SNAPSHOT=$(btrfs subvolume list -s "$SNAPSHOT_DIR" | grep "home_" | tail -2 | head -1 | awk '{print $NF}')
NEW_SNAPSHOT="${SNAPSHOT_DIR}/home_$(date +%Y%m%d_%H%M%S)"

# Yeni snapshot al
btrfs subvolume snapshot -r "$LOCAL_SUBVOL" "$NEW_SNAPSHOT"

# İlk kez tam yedek, sonraki seferlerde incremental
if [ -z "$PREV_SNAPSHOT" ]; then
    echo "İlk yedekleme - tam snapshot gönderiliyor..."
    btrfs send "$NEW_SNAPSHOT" | ssh "${REMOTE_USER}@${REMOTE_HOST}" 
        "btrfs receive ${REMOTE_PATH}"
else
    echo "Incremental yedekleme - değişiklikler gönderiliyor..."
    btrfs send -p "${SNAPSHOT_DIR}/${PREV_SNAPSHOT}" "$NEW_SNAPSHOT" | 
        ssh "${REMOTE_USER}@${REMOTE_HOST}" 
        "btrfs receive ${REMOTE_PATH}"
fi

echo "Yedekleme tamamlandı: $(basename $NEW_SNAPSHOT)"

Bu yaklaşım özellikle bant genişliği sınırlı ortamlarda çok değerlidir. Sadece değişen bloklar aktarıldığı için hem zaman hem de bant genişliği tasarrufu sağlanır.

ZFS Send/Receive: Daha Zengin Özellikler

ZFS’in send/receive implementasyonu BTRFS’inkinden daha olgun ve özellik açısından daha zengindir.

#!/bin/bash
# ZFS incremental remote backup
REMOTE_HOST="backup-server.example.com"
DATASET="mypool/home"
REMOTE_POOL="backuppool"
TODAY=$(date +%Y%m%d)
YESTERDAY=$(date -d "yesterday" +%Y%m%d)

# Günlük snapshot al
zfs snapshot "${DATASET}@daily_${TODAY}"

# Incremental send (şifreli, sıkıştırılmış)
zfs send -i "${DATASET}@daily_${YESTERDAY}" 
         "${DATASET}@daily_${TODAY}" | 
    pv -s $(zfs send -i "${DATASET}@daily_${YESTERDAY}" 
                      "${DATASET}@daily_${TODAY}" --dryrun -P 2>&1 | 
            grep "total estimated size" | awk '{print $4}') | 
    ssh "root@${REMOTE_HOST}" 
        "zfs receive -F ${REMOTE_POOL}/home"

echo "ZFS yedekleme tamamlandı."

ZFS’in BTRFS’e göre öne çıktığı alan, send/receive sırasında şifreleme ve sıkıştırmayı dataset seviyesinde yönetebilmesidir. ZFS üzerinde şifreli dataset oluşturulduğunda, send işlemi ham şifreli veriyi gönderebilir; bu da hedef sistemin şifre anahtarına ihtiyaç duymadığı anlamına gelir.

# Şifreli ZFS dataset ile çalışmak
zfs set encryption=aes-256-gcm keylocation=prompt keyformat=passphrase mypool/sensitive_data

# Şifreli veriyi çözmeden uzağa gönder
zfs send -w mypool/sensitive_data@snapshot1 | 
    ssh root@backup-server "zfs receive backuppool/sensitive_data"

Snapshot Yönetimi ve Otomasyonu

Her iki sistemde de snapshot birikimine karşı otomatik temizlik şarttır. Disk dolar, sistem yavaşlar. Production’da bunu yaşamak istemezsiniz.

BTRFS için snapper aracı bu işi gayet iyi yapıyor:

# snapper kurulumu ve yapılandırması
apt install snapper

# Home dizini için snapper yapılandırması oluştur
snapper -c home create-config /home

# Otomatik snapshot politikası ayarla
snapper -c home set-config 
    TIMELINE_CREATE=yes 
    TIMELINE_CLEANUP=yes 
    TIMELINE_LIMIT_HOURLY=24 
    TIMELINE_LIMIT_DAILY=7 
    TIMELINE_LIMIT_WEEKLY=4 
    TIMELINE_LIMIT_MONTHLY=6 
    TIMELINE_LIMIT_YEARLY=2

# Mevcut snapshot'ları listele
snapper -c home list

ZFS tarafında ise zfs-auto-snapshot veya özel cron scriptleri yaygın kullanılır:

# /etc/cron.d/zfs-snapshots dosyası
# Her saat başı snapshot
0 * * * * root /usr/local/bin/zfs-snapshot-cleanup.sh

# /usr/local/bin/zfs-snapshot-cleanup.sh içeriği
#!/bin/bash
DATASET="mypool/home"
MAX_SNAPSHOTS=24

# Yeni snapshot al
zfs snapshot "${DATASET}@hourly_$(date +%Y%m%d_%H%M)"

# Eski snapshot'ları temizle
SNAPSHOT_COUNT=$(zfs list -t snapshot -o name "$DATASET" | grep "hourly" | wc -l)
if [ "$SNAPSHOT_COUNT" -gt "$MAX_SNAPSHOTS" ]; then
    OLDEST=$(zfs list -t snapshot -o name "$DATASET" | grep "hourly" | head -1)
    zfs destroy "$OLDEST"
    echo "Silindi: $OLDEST"
fi

Gerçek Dünya: Hangi Durumda Hangisi?

Teorik karşılaştırma yeterli değil, gerçek senaryolara bakalım.

Senaryo 1: Ev sunucusu veya küçük şirket ortamı

Tek disk veya basit RAID yapısı, Ubuntu veya Fedora kullanan bir ortam. Burada BTRFS açık ara öne çıkıyor. Çekirdek içinde yer alıyor, ek paket gerektirmiyor ve snapper + systemd timer kombinasyonuyla kurumsal kalitede snapshot yönetimi mümkün. Fedora bu yapıyı varsayılan olarak zaten sunuyor.

Senaryo 2: Kurumsal depolama sunucusu

Onlarca TB veri, SSD önbellekleme ihtiyacı, birden fazla havuz yönetimi. Burada ZFS tartışmasız. ZFS’in L2ARC (SSD önbellek), SLOG (yazma günlüğü için ayrı SSD) ve dedup (tekrarlayan veri tespiti) özellikleri kurumsal ortamda büyük fark yaratır. TrueNAS gibi kurumsal NAS çözümleri ZFS üzerine inşa edilmiş olması tesadüf değil.

Senaryo 3: Konteyner ortamı

Docker veya LXC kullanan bir sistem yöneticisiyseniz, BTRFS’in Docker storage driver olarak doğrudan desteklenmesi avantaj. ZFS da Docker ile çalışır ancak yapılandırma daha karmaşıktır.

Senaryo 4: Felaket kurtarma planı

Bir altyapıyı başka bir lokasyona birebir kopyalamak istiyorsanız, ZFS send/receive pipeline’ının güvenilirliği ve özellik seti daha güçlüdür. Özellikle şifrelenmiş yedekler ve tutarlılık garantisi konusunda ZFS bir adım önde.

BTRFS Zayıf Noktaları

Dürüst olmak gerekirse, BTRFS’in production ortamlarda yaşattığı bazı acı deneyimler var. RAID 5/6 implementasyonu uzun süre kararsızdı ve hala tam olarak güvenilir kabul edilmiyor. Yüksek yük altında subvolume silme işlemleri zaman zaman beklenmedik davranışlar gösterebiliyor. Snapper ile otomatik snapshot yönetimi yapıyorsanız ve disk dolmaya başlarsa, quota özelliği etkin değilse snapshot’ların ne kadar yer kapladığını anlamak zor olabiliyor.

# BTRFS quota aktifleştirmek (snapshot boyutlarını görmek için)
btrfs quota enable /home

# Biraz zaman sonra boyutları kontrol et
btrfs qgroup show /home

# df ile genel durum
btrfs filesystem df /home
btrfs filesystem usage /home

ZFS Zayıf Noktaları

ZFS’in en büyük dezavantajı bellek iştahı. ZFS ARC (Adaptive Replacement Cache) sistem RAM’ini agresif şekilde kullanır. Küçük belleğe sahip sistemlerde (8GB altı) ZFS performansı düşebilir. Ayrıca lisans uyumsuzluğu nedeniyle bazı Linux dağıtımları ZFS’i çekirdek içine entegre edemez; DKMS modülü olarak gelir ve çekirdek güncellemelerinde bazen sorun çıkarabilir.

Deduplication özelliğini açmak cazip görünse de gerçek hayatta sizi yavaşlatır. Dedup tablosu RAM’de tutulur ve devasa boyutlara ulaşabilir. Açmadan önce iki kez düşünün:

# Dedup AÇMADAN önce simülasyon yap
zdb -S mypool

# Bu çıktı size tahmini dedup kazanımını gösterir
# Çıktıda "dedup ratio" 1.5x'in altındaysa kesinlikle açmayın

Snapshot Performans Karşılaştırması

Snapshot alma hızı her iki sistemde de neredeyse anlıktır, veri boyutundan bağımsız olarak. Asıl fark snapshot’tan sonra yaşanır.

BTRFS’de çok sayıda snapshot birikince dosya sistemi metadata operasyonları yavaşlayabilir. Özellikle küçük dosya yoğun iş yüklerinde (web sunucusu log dizinleri gibi) bu belirginleşir. Genel öneri: aynı subvolume üzerinde 100’den fazla snapshot bulundurmayın.

ZFS bu konuda daha iyi ölçeklenir. Yüzlerce snapshot bile yönetilebilir durumdadır, ancak snapshot sayısı arttıkça zfs list komutu yavaşlar ve snapshot silinmesi daha uzun sürer.

# ZFS snapshot boyutlarını izle
watch -n 5 "zfs list -t snapshot -s used -o name,used,refer mypool/home | tail -20"

# Belirli snapshot'lar arası farkı göster
zfs diff mypool/home@daily_20240114 mypool/home@daily_20240115

zfs diff komutu özellikle güzel bir özellik. İki snapshot arasında hangi dosyaların değiştiğini gösterir. Güvenlik olaylarını araştırırken veya hangi backup’ın hangi dosyayı içerdiğini anlamaya çalışırken çok işe yarıyor.

Bootloader Entegrasyonu

Her ikisinin de önemli ama çok konuşulmayan bir özelliği: boot ortamı yönetimi.

BTRFS üzerinde Fedora veya openSUSE kullanıyorsanız, GRUB otomatik olarak snapshot’lardan boot edebilir. Kötü bir kernel güncellemesi sonrası sisteminiz açılmıyorsa, GRUB menüsünden önceki snapshot’ı seçip kurtarabilirsiniz. Bu özelliği aktif tutmak için:

# openSUSE/Fedora'da snapshot boot entegrasyonu
grub2-mkconfig -o /boot/grub2/grub.cfg

# Snapper'ın boot entry oluşturmasını sağla
systemctl enable snapper-boot.timer

ZFS tarafında ise ZFSBootMenu veya Proxmox gibi platformlar bu entegrasyonu sağlar. Proxmox özellikle ilginç: hem ZFS hem de snapshot boot entegrasyonunu kutudan çıkar çıkmaz sunuyor.

Monitoring ve Alerting

Production ortamında snapshot başarısız olursa ne zaman haberiniz oluyor? Script çıktısını bir yere yazmak yeterli değil.

#!/bin/bash
# Her iki sistem için basit monitoring scripti
check_btrfs_snapshot() {
    local subvol=$1
    local max_age_hours=$2
    
    # Son snapshot'ın yaşını kontrol et
    LAST_SNAP=$(btrfs subvolume list -s --sort=-gen "$subvol" | head -1 | awk '{print $NF}')
    
    if [ -z "$LAST_SNAP" ]; then
        echo "CRITICAL: ${subvol} için hiç snapshot yok!"
        # Slack veya PagerDuty webhook'u çağırın
        curl -s -X POST "$SLACK_WEBHOOK" 
            -d "{"text": "CRITICAL: BTRFS snapshot eksik - ${subvol}"}"
        exit 2
    fi
    
    echo "OK: Son snapshot ${LAST_SNAP}"
}

check_zfs_snapshot() {
    local dataset=$1
    local max_age_hours=${2:-25}
    
    LAST_SNAP_TIME=$(zfs list -t snapshot -o name,creation -s creation 
                     -r "$dataset" | tail -1 | awk '{print $2, $3, $4, $5, $6}')
    
    echo "Son ZFS snapshot zamanı: $LAST_SNAP_TIME"
}

# Kullanım
check_btrfs_snapshot /home 25
check_zfs_snapshot mypool/home 25

Sonuç

İki yıl önce hem BTRFS hem de ZFS kullanan ortamları yönetirken sürekli şu soruyla karşılaştım: “Hangisini öğrenmeli, hangisine odaklanmalıyım?” Cevabım hala aynı: ikisini de bilin, ama ikisini de aynı yerde kullanmayın.

BTRFS, Linux ekosistemiyle derin entegrasyonu, düşük sistem gereksinimleri ve kolay başlangıç eğrisi ile küçük-orta ölçekli ortamlar ve geliştirici workstation’ları için mükemmel seçenek olmaya devam ediyor. Snapper entegrasyonu ile kurulumu, production kalitesinde otomatik snapshot yönetimi sunuyor. Ancak RAID 5/6’dan uzak durun ve snapshot sayısını kontrollü tutun.

ZFS ise kurumsal depolama, yüksek güvenilirlik gerektiren ortamlar ve gelişmiş özellik seti (şifreli yedekler, dedup simülasyonu, ARC önbellekleme) ihtiyacı olan senaryolar için birinci sınıf araç. TrueNAS, Proxmox veya kendi kurduğunuz büyük ölçekli depolama sunucularında ZFS ile yanlış gidemezsiniz.

Her iki teknoloji de 2024 itibarıyla olgunlaşmış, production’a hazır araçlar. Seçiminizi ekibinizin bilgi birikimi, donanım kapasitesi ve spesifik iş yükü gereksinimlerine göre yapın. Ve her zaman şunu hatırlayın: test edilmemiş bir yedek, yedek değildir. Snapshot aldınız mı? Restore etmeyi de test edin.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir