Snapshot ile Anlık Yedek: Farklar ve Karşılaştırma

Yıllarca sistem yöneticiliği yapan biri olarak şunu rahatlıkla söyleyebilirim: “Yedeğim var” demek ile “Yedeğim çalışıyor ve ne zaman kullanacağımı biliyorum” demek arasında dağlar kadar fark var. Bu farkın tam ortasında ise snapshot ile geleneksel yedek kavramları duruyor. Çoğu ekip bu ikisini birbirinin yerine kullanıyor, bazen de ikisinden birini tamamen göz ardı ediyor. Oysa ikisi farklı sorunları çözmek için tasarlanmış, birbirini tamamlayan araçlar.

Snapshot Nedir, Yedek Nedir?

Önce terminolojiyi netleştirelim çünkü bu ayrımı doğru anlamamak, felaket anında yanlış araca başvurmanıza yol açar.

Snapshot (Anlık Görüntü): Bir diskin, dosya sisteminin veya sanal makinenin belirli bir andaki durumunu kaydeden bir referans noktasıdır. Snapshot, genellikle veriyi kopyalamaz; sadece o anki blok haritasını ve değişikliklerin nereye yazılacağını takip eder. Bu yüzden çok hızlı oluşturulur ve başlangıçta çok az yer kaplar.

Geleneksel Yedek: Verinin fiziksel olarak başka bir konuma kopyalanmasıdır. Tam yedek (full backup), artımlı yedek (incremental) veya fark yedek (differential) olarak uygulanabilir. Asıl amacı veriyi farklı bir depolama konumuna taşımaktır.

Bu tanımların pratikte ne anlama geldiğini bir senaryo üzerinden görelim.

Diyelim ki üretim veritabanı sunucunuzda bir PostgreSQL instance çalışıyor ve her gece 02:00’de yedek alıyorsunuz. Sabah 10:00’da bir developer yanlışlıkla kritik bir tabloyu sildi. Geleneksel yedeğiniz size dün gece 02:00’nin verilerini geri verir, yani 8 saatlik veri kaybı yaşarsınız. Eğer snapshot kullandıysanız ve sabah 09:00’da bir snapshot aldıysanız, sadece 1 saatlik veri kaybıyla kurtulursunuz.

Copy-on-Write ve Redirect-on-Write Mekanizmaları

Snapshot’ın nasıl çalıştığını anlamak için iki temel mekanizmayı bilmek gerekiyor.

Copy-on-Write (CoW): Snapshot alındığı anda hiçbir şey kopyalanmaz. Orijinal veri üzerinde bir değişiklik yapılmak istendiğinde, sistem önce eski bloğu snapshot alanına kopyalar, sonra yeni veriyi orijinal konuma yazar. LVM snapshot’ları bu mekanizmayı kullanır.

# LVM snapshot oluşturma - CoW mekanizması
lvcreate -L 10G -s -n data_snap /dev/vg0/data

# Snapshot'ın durumunu kontrol etme
lvdisplay /dev/vg0/data_snap

# Snapshot boyutunu izleme
watch -n 5 'lvs /dev/vg0/data_snap --units m'

Redirect-on-Write (RoW): Snapshot alındıktan sonra yapılan yeni yazma işlemleri, orijinal konuma değil yeni bir alana yönlendirilir. Snapshot ise orijinal bloklara işaret etmeye devam eder. ZFS ve Btrfs bu yaklaşımı kullanır.

# ZFS snapshot oluşturma - RoW mekanizması
zfs snapshot tank/data@2024-01-15_09:00

# Snapshot listesini görüntüleme
zfs list -t snapshot

# Snapshot kullanımını kontrol etme
zfs get used,referenced tank/data@2024-01-15_09:00

LVM Snapshot Yönetimi

Linux ortamında en yaygın snapshot yöntemi LVM üzerinden yapılandırmaktır. Özellikle fiziksel sunucularda veya LVM üzerine kurulu sistemlerde oldukça güvenilirdir.

# Mevcut volume group'ları listele
vgs

# Logical volume bilgilerini göster
lvs -o lv_name,lv_size,origin,snap_percent

# Snapshot oluştur ve boyut ver
lvcreate --size 5G --snapshot --name mysql_snap_$(date +%Y%m%d_%H%M) /dev/vg_data/mysql_lv

# Snapshot'ı geçici olarak bağla ve kontrol et
mkdir /mnt/snapshot_check
mount -o ro /dev/vg_data/mysql_snap_20240115_0900 /mnt/snapshot_check
ls -la /mnt/snapshot_check

# Geri yükleme işlemi - önce servisi durdur
systemctl stop mysql
lvconvert --merge /dev/vg_data/mysql_snap_20240115_0900
systemctl start mysql

LVM snapshot kullanırken dikkat etmeniz gereken kritik bir nokta var: Snapshot için ayırdığınız alan dolduğunda, snapshot geçersiz hale gelir ve otomatik olarak silinir. Bu yüzden snap_percent değerini düzenli izlemeniz şart.

Btrfs ile Modern Snapshot Yönetimi

Btrfs, snapshot konusunda LVM’ye göre çok daha esnek bir yapı sunuyor. Subvolume tabanlı çalışması sayesinde granüler snapshot alımı mümkün.

# Btrfs subvolume oluştur
btrfs subvolume create /data/production

# Anlık snapshot al (salt-okunur)
btrfs subvolume snapshot -r /data/production /data/snapshots/production_$(date +%Y%m%d_%H%M%S)

# Snapshot listesini görüntüle
btrfs subvolume list /data

# Snapshot'tan geri yükleme
btrfs subvolume snapshot /data/snapshots/production_20240115_090000 /data/production_restored

# Eski snapshot'ları temizle
btrfs subvolume delete /data/snapshots/production_20240115_090000

# Snapshot boyutlarını karşılaştır
btrfs filesystem du -s /data/snapshots/*

Btrfs’in güzel tarafı, snapshot alma işleminin neredeyse anlık gerçekleşmesi. 500 GB’lık bir veri için snapshot alma süresi milisaniyeler mertebesinde kalır.

VMware ve Hyper-V Snapshot Farkları

Sanallaştırma ortamlarında snapshot yönetimi biraz daha karmaşık bir yapı alıyor. VMware ve Hyper-V farklı yaklaşımlar benimsiyor.

VMware’de snapshot alındığında, delta diskler oluşturulur ve tüm yazma işlemleri bu delta disklere yönlendirilir. Bu yaklaşımın dezavantajı, uzun süre snapshot açık bırakıldığında I/O performansının ciddi ölçüde düşmesidir.

Hyper-V ise checkpoint mekanizmasını kullanır ve AVHD/AVHDX formatında delta dosyaları oluşturur. Hyper-V 2016 ve sonrasında production checkpoint desteğiyle uygulama tutarlılığı sağlanır.

# VMware ESXi üzerinde CLI ile snapshot yönetimi
vim-cmd vmsvc/getallvms
vim-cmd vmsvc/snapshot.create <vmid> "pre-update-snap" "Guncelleme oncesi snapshot" 1 1

# Snapshot listesini görüntüle
vim-cmd vmsvc/snapshot.get <vmid>

# Snapshot'a geri dön
vim-cmd vmsvc/snapshot.revert <vmid> <snapid> 0

# Snapshot sil
vim-cmd vmsvc/snapshot.remove <vmid> <snapid>

Sanal makine ortamlarında sık yapılan hata, snapshot’ı yedek gibi kullanmaktır. VMware’de birden fazla snapshot katmanı oluştukça disk I/O performansı dramatik biçimde düşer. Genel kural olarak, VMware snapshot’larını 72 saatten fazla açık bırakmayın.

Geleneksel Yedekleme: rsync ve tar ile Pratik Örnekler

Snapshot’ı anladıktan sonra geleneksel yedeklemenin neyi iyi yaptığına bakalım.

# rsync ile artımlı yedek - hardlink desteğiyle
rsync -avz --delete 
  --link-dest=/backup/daily/$(date -d "yesterday" +%Y-%m-%d) 
  /data/production/ 
  /backup/daily/$(date +%Y-%m-%d)/

# Yedek boyutunu kontrol et
du -sh /backup/daily/$(date +%Y-%m-%d)

# Belirli bir tarihe ait yedeği geri yükle
rsync -avz /backup/daily/2024-01-10/ /data/production_restore/

# tar ile sıkıştırılmış arşiv yedek
tar -czf /backup/archive/data_$(date +%Y%m%d).tar.gz 
  --exclude='/data/production/tmp' 
  --exclude='/data/production/cache' 
  /data/production/

# Arşiv içeriğini kontrol et
tar -tzf /backup/archive/data_20240115.tar.gz | head -20

# Seçici geri yükleme
tar -xzf /backup/archive/data_20240115.tar.gz 
  -C /tmp/restore 
  data/production/important_file.db

Geleneksel yedeklemenin kritik avantajı coğrafi ayrıştırma (geo-separation). Snapshot’ınız her zaman aynı depolama sistemi üzerinde durur. Disk array’iniz çöktüğünde snapshot’larınız da gider. Yedekleriniz farklı lokasyondaysa bu riski ortadan kaldırmış olursunuz.

Snapshot vs Yedek: Hangi Senaryo Hangisini Gerektirir?

Snapshot’ın Öne Çıktığı Durumlar

Uygulama güncellemesi öncesi: Bir web uygulamasını güncellemeden önce snapshot alırsınız. Güncelleme bozulursa 5 dakika içinde geri dönersiniz. Alternatif olarak tam yedek alıp restore etseydiniz bu işlem saatler sürebilirdi.

Geliştirme ve test ortamları: Developer’lar belirli bir veritabanı durumuna tekrar tekrar dönmek ister. Snapshot bu iş için biçilmiş kaftan.

Patch yönetimi: Kernel güncellemesi yapmadan önce sistem snapshot’ı almak, güncelleme sonrası sorun çıkarsa hızlı recovery sağlar.

Geleneksel Yedeğin Vazgeçilmez Olduğu Durumlar

Uzun süreli saklama: Vergi kaydları, müşteri verileri, hukuki belgeler. Bunları aylar veya yıllar boyunca saklamanız gerekir. Snapshot bu süre boyunca tutamazsınız.

Fidye yazılımı (ransomware) koruması: Ransomware atağında şifrelenmiş verilerle birlikte snapshot’larınız da etkilenebilir. Çevrimdışı veya immutable yedekler burada hayat kurtarır.

Donanım arızası: Disk array’in tamamen çökmesi durumunda snapshot’larınız işe yaramaz. Farklı lokasyondaki yedekleriniz devreye girer.

Seçici dosya kurtarma: Kullanıcı yanlışlıkla tek bir dosyayı sildi ve bunu 3 ay sonra fark etti. Snapshot’lar bu süre için tutulmaz ama yedekleriniz tutulabilir.

Snapshot Tutarlılığı: Application-Consistent vs Crash-Consistent

Bu ayrım çok kritik ve çoğu zaman göz ardı ediliyor.

Crash-consistent snapshot: Sistemi fiziksel olarak fişten çekmiş gibi anlık görüntü alır. Bellekteki veriler, database buffer’ları diske yazılmamış olabilir. MySQL veya PostgreSQL için bu, recovery sürecini başlatabilir.

Application-consistent snapshot: Uygulama durdurulur veya uygulamaya “flush” komutu verilir, sonra snapshot alınır. Bu yöntem daha güvenli ama kısa süreli de olsa servis kesintisi yaratabilir.

# MySQL için application-consistent snapshot
mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;"

# Başka bir terminalde snapshot al
lvcreate -L 10G -s -n mysql_consistent_snap /dev/vg0/mysql_data

# Kilidi kaldır
mysql -u root -p -e "UNLOCK TABLES;"

# PostgreSQL için benzer yaklaşım
psql -U postgres -c "SELECT pg_start_backup('snap_$(date +%Y%m%d_%H%M%S)');"
lvcreate -L 10G -s -n pg_snap /dev/vg0/pg_data
psql -U postgres -c "SELECT pg_stop_backup();"

Production veritabanı ortamlarında her zaman application-consistent snapshot kullanmalısınız. Crash-consistent snapshot, durumu belirsiz bir veritabanı bırakabilir.

Otomasyon: Snapshot Rotasyonu Script Örneği

#!/bin/bash
# snapshot_rotation.sh - Otomatik snapshot rotasyonu

LV_PATH="/dev/vg0/data"
SNAP_PREFIX="auto_snap"
MAX_SNAPS=5
SNAP_SIZE="10G"

# Mevcut snapshot sayısını kontrol et
CURRENT_SNAPS=$(lvs --noheadings -o lv_name | grep "^  ${SNAP_PREFIX}" | wc -l)

# Maksimum sayıya ulaşıldıysa en eskisini sil
if [ "$CURRENT_SNAPS" -ge "$MAX_SNAPS" ]; then
    OLDEST=$(lvs --noheadings --sort lv_time -o lv_name | grep "^  ${SNAP_PREFIX}" | head -1 | xargs)
    echo "En eski snapshot siliniyor: $OLDEST"
    lvremove -f "/dev/vg0/$OLDEST"
fi

# Yeni snapshot oluştur
SNAP_NAME="${SNAP_PREFIX}_$(date +%Y%m%d_%H%M%S)"
lvcreate -L "$SNAP_SIZE" -s -n "$SNAP_NAME" "$LV_PATH"

if [ $? -eq 0 ]; then
    echo "Snapshot basariyla olusturuldu: $SNAP_NAME"
else
    echo "HATA: Snapshot olusturulamadi!" >&2
    exit 1
fi

Bu script’i cron ile saatlik çalıştırarak otomatik snapshot rotasyonu sağlayabilirsiniz.

# Cron kaydı ekle - her saat başı çalışır
echo "0 * * * * root /usr/local/bin/snapshot_rotation.sh >> /var/log/snapshot.log 2>&1" 
  >> /etc/cron.d/snapshot-rotation

3-2-1 Kuralı ve Snapshot’ın Yeri

Yedekleme dünyasının altın kuralı olan 3-2-1’i snapshot perspektifinden değerlendirmek gerekiyor.

3 kopya: Verinin 3 farklı kopyası olmalı. Snapshot bunu destekler ama hepsi aynı array üzerinde kalırsa gerçek anlamda 3 kopya sayılmaz.

2 farklı medya: Farklı depolama ortamları kullanılmalı. Disk üzerindeki snapshot ile ikincil bir backup storage birbirini tamamlar.

1 offsite kopya: En az bir kopya fiziksel olarak farklı lokasyonda olmalı. Snapshot tek başına bu kriteri karşılayamaz.

Bu yüzden hibrit yaklaşım en mantıklısı: Operasyonel esneklik için snapshot + uzun vadeli koruma için geleneksel yedek.

Gerçek Dünya Senaryosu: E-ticaret Sitesi Felaketi

Geçmişte bir e-ticaret şirketinin altyapısını yönetirken yaşadığım bir olayı paylaşayım (detaylar anonimleştirilmiştir).

Kara Cuma günü akşamı, bir developer yanlış ortamda migration script çalıştırdı ve production veritabanındaki sipariş tablosunu truncate etti. Saat 22:30’du, en yoğun alışveriş saatlerindeydi.

Elinde şunlar vardı: Gece 02:00’den kalma full yedek (20.5 saatlik veri kaybı riski) ve her 4 saatte bir alınan snapshot’lar (son snapshot saat 20:00’deydi, yani 2.5 saatlik veri kaybı riski).

Snapshot’tan geri yükleme yapıldı, saat 22:30’dan 20:00’a döndü. Kaybedilen 2.5 saatlik sipariş verisi için ödeme sağlayıcısından transaction log’ları çekildi ve manuel olarak yeniden işlendi.

Eğer snapshot olmasaydı 20.5 saatlik veri kaybı ve büyük ihtimalle şirket için ölümcül bir sonuç olurdu. Bu olay snapshot’ların değerini somut biçimde gösteriyor.

Snapshot Boyutu Hesaplama ve Kapasite Planlaması

# Btrfs snapshot boyutlarını detaylı incele
btrfs qgroup show -p /data

# ZFS snapshot boyutunu hesapla
zfs get -r used,referenced,compressratio tank/data

# LVM snapshot doluluk oranını izle
lvs -o lv_name,lv_size,data_percent,snap_percent vg0

# Disk yazma hızına göre snapshot boyutu tahmini
# Saatlik yazma hızını ölçmek için
iostat -x 1 60 | grep sda | awk '{sum += $8} END {print "Ortalama yazma (KB/s):", sum/NR}'

Kapasite planlaması için kaba bir formül: Snapshot boyutu, saatlik değişim hızı ile snapshot’ın kaç saat tutulacağının çarpımına eşit olmalı. Bir partition’da saatlik 2 GB değişim varsa ve 8 saatlik snapshot tutmak istiyorsanız, snapshot havuzunuz en az 16 GB olmalı.

İzleme ve Uyarı Sistemi Kurma

#!/bin/bash
# snapshot_monitor.sh - Snapshot sağlık kontrolü

ALERT_EMAIL="[email protected]"
SNAP_THRESHOLD=80  # Yüzde olarak doluluk uyarı eşiği

# LVM snapshot doluluk kontrolü
lvs --noheadings -o lv_name,snap_percent 2>/dev/null | grep -v "-" | while read lv_name snap_pct; do
    pct=${snap_pct%.*}
    if [ "$pct" -ge "$SNAP_THRESHOLD" ]; then
        echo "UYARI: $lv_name snapshot dolulugu $snap_pct% seviyesinde!" | 
          mail -s "[KRITIK] Snapshot Doluluk Uyarisi" "$ALERT_EMAIL"
    fi
done

# ZFS snapshot yaşını kontrol et
zfs list -t snapshot -o name,creation | while read snap creation; do
    snap_age=$(( ($(date +%s) - $(date -d "$creation" +%s)) / 3600 ))
    if [ "$snap_age" -gt 168 ]; then  # 1 haftadan eski
        echo "Eski snapshot tespit edildi: $snap ($snap_age saat)"
    fi
done

Sonuç

Snapshot ve geleneksel yedek birbirinin rakibi değil, tamamlayıcısı. Snapshot size hız ve esneklik verir; konfigürasyon değişikliği öncesi güvenlik ağı kurar, uygulama tutarlılığı sağlar ve dakikalar içinde geri yükleme imkanı tanır. Geleneksel yedek ise size coğrafi ayrıştırma, uzun süreli saklama ve donanım arızasına karşı gerçek koruma sunar.

İkisini birden kullanmayan bir altyapı, ya çok yavaş kurtarılır ya da hiç kurtarılamaz.

Pratik öneri olarak şunu söyleyeyim: Snapshot’larınızı operasyonel hataları düzeltmek ve hızlı geri dönüş için kullanın. Geleneksel yedeklerinizi ise katastrofik senaryolar, uzun dönemli arşiv ve compliance gereksinimleri için saklayın. Herbiri için ayrı bir RTO ve RPO hedefi belirleyin, bu hedefleri belgelendirin ve en önemlisi düzenli aralıklarla test edin.

Çalışmayan bir yedeğin değeri yoktur. Test etmediğiniz bir snapshot planı, kağıt üzerinde var olan bir güvencedir.