Hızlı Geri Alma: Snapshot ile Rollback Stratejisi

Tarafındankomut
0 Comments

Bir production sunucusunda kritik bir güncelleme yapıyorsun, her şey yolunda gidiyor gibi görünüyor, sonra birden servisler çökmeye başlıyor. Veritabanı bağlantıları kopuyor, uygulama hata veriyor, telefon çalmaya başlıyor. Bu senaryoyu yaşadıysan ne kadar değerli olduğunu bilirsin: tek bir komutla 30 saniye önceye dönme yeteneği. Snapshot ve rollback stratejisi tam olarak bu yeteneği sana veriyor.

Bu yazıda snapshot’ın sadece “bir yedek türü” olmadığını, doğru kullanıldığında neredeyse anlık geri alma imkanı sunan güçlü bir operasyonel araç olduğunu göreceğiz. Hem Linux (LVM, Btrfs, ZFS) hem de sanallaştırma ortamları (VMware, KVM/libvirt) için pratik rollback stratejilerini ele alacağız.

Snapshot Nedir ve Backup’tan Farkı Ne?

Snapshot ile klasik yedek arasındaki farkı anlamak, stratejiyi doğru kurgulamak için kritik.

Klasik yedek: Verinin o anki kopyasını başka bir yere taşır. Geri yüklemek için kopyayı tekrar aynı yere yazmak gerekir, bu da zaman alır.

Snapshot: Verinin o anki durumunu “dondurur”, değişiklikler yeni bir katmana yazılır (Copy-on-Write veya Redirect-on-Write mekanizması ile). Rollback yaparken sadece pointer’ı değiştirirsin, veriyi fiziksel olarak taşımazsın. Bu yüzden rollback saniyelerde tamamlanır.

Ama dikkat: Snapshot, backup’ın yerini tutmaz. Snapshot, aynı disk üzerinde yaşar. Disk giderse snapshot da gider. Strateji her ikisini birlikte kullanmak üzerine kurulmalı.

LVM Snapshot ile Linux’ta Rollback

LVM (Logical Volume Manager), enterprise Linux kurulumlarının büyük çoğunluğunda kullanılır ve yerleşik snapshot desteği sunar.

Mevcut Durumu Kontrol Et

# Volume group ve logical volume bilgilerini göster
sudo vgs
sudo lvs -a -o +devices

# Snapshot için ne kadar alan var?
sudo vgdisplay | grep -E "Free|Total"

Snapshot Alma

Diyelim ki /dev/vg_prod/lv_app üzerinde bir uygulama dizini var ve kritik bir güncelleme öncesi snapshot almak istiyorsun:

# 10GB snapshot alanı ayır (değişim miktarına göre boyutlandır)
sudo lvcreate -L10G -s -n lv_app_snap_$(date +%Y%m%d_%H%M) /dev/vg_prod/lv_app

# Snapshot'ı listele
sudo lvs -a | grep snap

# Snapshot doluluk oranını izle (100% olursa geçersiz olur!)
sudo lvs -o name,snap_percent /dev/vg_prod/lv_app_snap_20240115_1430

Önemli uyarı: LVM snapshot’ı dolduğunda otomatik olarak “invalid” işaretlenir. Boyutlandırmayı cömert tutmak veya monitoring eklemek şart.

Rollback: Snapshot’a Geri Dön

Güncelleme bozulduysa ve geri almak istiyorsun:

# Önce servisi durdur
sudo systemctl stop myapp

# Orijinal volume'ü unmount et
sudo umount /mnt/app

# Snapshot'ı orijinal volume'e merge et (rollback)
sudo lvconvert --merge /dev/vg_prod/lv_app_snap_20240115_1430

# Volume'ü tekrar aktive et
sudo lvchange -an /dev/vg_prod/lv_app
sudo lvchange -ay /dev/vg_prod/lv_app

# Mount et ve servisi başlat
sudo mount /dev/vg_prod/lv_app /mnt/app
sudo systemctl start myapp

Bu işlem root filesystem için yapılıyorsa, merge bir sonraki reboot’ta otomatik gerçekleşir. Reboot sonrası snapshot silinir ve sistem eski haline döner.

Snapshot Boyutunu Dinamik Olarak Artırma

# Snapshot dolmaya başladıysa ve rollback yapmak istemiyorsun
sudo lvextend -L+5G /dev/vg_prod/lv_app_snap_20240115_1430

# Doluluk oranını anlık izlemek için basit bir döngü
watch -n 5 'sudo lvs -o name,snap_percent | grep snap'

Btrfs ile Snapshot Yönetimi

Btrfs, modern Linux dağıtımlarında (özellikle openSUSE, Fedora, bazı Ubuntu kurulumları) varsayılan dosya sistemi olarak gelmeye başladı. Snapshot desteği dosya sisteminin içine entegre edilmiş durumda.

Btrfs Subvolume ve Snapshot Yapısı

# Mevcut subvolume'leri listele
sudo btrfs subvolume list /

# Anlık snapshot al
sudo btrfs subvolume snapshot / /mnt/btrfs_root/@snapshots/root_$(date +%Y%m%d_%H%M)

# Read-only snapshot (daha güvenli, değiştirilemiyor)
sudo btrfs subvolume snapshot -r / /mnt/btrfs_root/@snapshots/root_ro_$(date +%Y%m%d_%H%M)

Snapper ile Otomatik Snapshot Yönetimi

openSUSE ve bazı dağıtımlarda snapper aracı, Btrfs snapshot’larını otomatik olarak yönetir. Her zypper veya dnf komutu öncesi/sonrası otomatik snapshot alır.

# Snapper konfigürasyonunu gör
sudo snapper -c root list

# Manuel snapshot al (güncelleme öncesi)
sudo snapper -c root create --description "pre-nginx-update" --userdata "important=yes"

# Rollback yap (örneğin snapshot 42'ye)
sudo snapper -c root rollback 42

# İki snapshot arasındaki farkı gör
sudo snapper -c root diff 42..43

Bu yaklaşımın güzelliği şu: Snapper, güncelleme öncesi ve sonrası otomatik snapshot çifti oluşturur. Bir şeyler ters giderse “pre” durumuna tek komutla dönebilirsin.

ZFS ile Kurumsal Düzey Snapshot Stratejisi

ZFS, özellikle FreeBSD ve ileri düzey Linux kurulumlarında (Ubuntu ZFS on root) tercih edilen, snapshot konusunda en olgun teknoloji.

# ZFS pool ve dataset durumunu gör
sudo zpool status
sudo zfs list

# Snapshot al
sudo zfs snapshot rpool/ROOT/ubuntu@pre_upgrade_$(date +%Y%m%d)

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

# Snapshot'tan veri oku (mount etmeden)
ls /rpool/ROOT/ubuntu/.zfs/snapshot/pre_upgrade_20240115/

ZFS Rollback

# Snapshot'a geri dön (en son snapshot'a)
sudo zfs rollback rpool/ROOT/ubuntu@pre_upgrade_20240115

# Araya başka snapshot'lar girdiyse -r ile zorla
sudo zfs rollback -r rpool/ROOT/ubuntu@pre_upgrade_20240115

# Snapshot'ı başka bir sisteme gönder (backup olarak)
sudo zfs send rpool/ROOT/ubuntu@pre_upgrade_20240115 | ssh backup-server "sudo zfs receive tank/backups/ubuntu@pre_upgrade_20240115"

ZFS’in muazzam bir özelliği: zfs send/receive ile snapshot’ı ağ üzerinden başka bir sunucuya aktarabilirsin. Bu hem offsite backup hem de hızlı sunucu klonlama için kullanılabilir.

VMware / vSphere’de Snapshot Rollback

Sanallaştırma ortamlarında snapshot yönetimi çok daha görsel ve basit, ama yanlış kullanımda ciddi performans sorunlarına yol açabilir.

VMware CLI ile Snapshot Yönetimi

# vmrun ile snapshot al (VMware Workstation/Fusion)
vmrun snapshot /path/to/vm.vmx "pre_update_snapshot"

# vSphere ortamında govc aracı ile
govc snapshot.create -vm myvm "pre_update_$(date +%Y%m%d)"

# Snapshot listesi
govc snapshot.tree -vm myvm

# Rollback (revert)
govc snapshot.revert -vm myvm "pre_update_20240115"

# Snapshot'ı sil (disk alanını geri al)
govc snapshot.remove -vm myvm "pre_update_20240115"

Kritik uyarı: VMware snapshot’ları uzun süre canlı bırakmak performansı öldürür. Delta dosyaları büyüdükçe I/O operasyonları yavaşlar. Rollback yapmayacaksan snapshot’ı en geç 24-48 saat içinde sil veya “consolidate” et.

KVM/libvirt ile Snapshot

# KVM VM'in internal snapshot'ını al
sudo virsh snapshot-create-as --domain myvm 
  --name "pre_update_20240115" 
  --description "Before kernel update" 
  --atomic

# Snapshot listesi
sudo virsh snapshot-list myvm

# Snapshot detayı
sudo virsh snapshot-info myvm pre_update_20240115

# Rollback
sudo virsh snapshot-revert myvm pre_update_20240115

# External snapshot al (daha güvenli, VM çalışırken)
sudo virsh snapshot-create-as --domain myvm 
  --name "live_snap_$(date +%Y%m%d_%H%M)" 
  --diskspec vda,snapshot=external 
  --memspec snapshot=external 
  --atomic --live

Gerçek Dünya Senaryosu: Kernel Güncelleme Öncesi Snapshot

Bunu gerçekten yaşadım. Bir müşterinin production Ubuntu sunucusunda kernel güncellemesi yapacaktık. Sunucu fiziksel makina, ZFS dosya sistemi var.

#!/bin/bash
# pre_update_snapshot.sh
# Güncelleme öncesi otomatik snapshot script'i

TIMESTAMP=$(date +%Y%m%d_%H%M)
DATASET="rpool/ROOT/ubuntu"
SNAP_PREFIX="pre_apt_update"

echo "[$(date)] Snapshot alınıyor: ${DATASET}@${SNAP_PREFIX}_${TIMESTAMP}"

# Snapshot al
if sudo zfs snapshot "${DATASET}@${SNAP_PREFIX}_${TIMESTAMP}"; then
    echo "[$(date)] Snapshot başarıyla alındı."
    
    # Son 5 snapshot'tan fazlasını temizle
    SNAP_COUNT=$(sudo zfs list -t snapshot -o name | grep "${DATASET}@${SNAP_PREFIX}" | wc -l)
    if [ "$SNAP_COUNT" -gt 5 ]; then
        OLDEST=$(sudo zfs list -t snapshot -o name | grep "${DATASET}@${SNAP_PREFIX}" | head -1)
        echo "[$(date)] Eski snapshot siliniyor: $OLDEST"
        sudo zfs destroy "$OLDEST"
    fi
    
    echo "[$(date)] Güncelleme başlatılıyor..."
    sudo apt update && sudo apt upgrade -y
    
    echo "[$(date)] İşlem tamamlandı. Snapshot adı: ${DATASET}@${SNAP_PREFIX}_${TIMESTAMP}"
else
    echo "[$(date)] HATA: Snapshot alınamadı, güncelleme iptal edildi."
    exit 1
fi

Kernel güncellemesi sonrası sunucu boot etmedi. GRUB menüsünden eski kernel seçemiyoruz çünkü initrd oluşturulamamış. Tek çözüm?

# Rescue moddan ZFS snapshot rollback
sudo zfs rollback rpool/ROOT/ubuntu@pre_apt_update_20240115_1423

# Reboot
sudo reboot

5 dakikada sorun çözüldü. Klasik backup ile bu en az 45 dakika sürerdi.

Snapshot Politikası ve Otomasyonu

Snapshot’ları manuel almak hata yapmaya açık. Bunu bir politikaya bağlamak gerekiyor.

Cron ile Otomatik Snapshot Rotasyonu

# /usr/local/bin/lvm_snapshot_rotate.sh

#!/bin/bash
VG="vg_prod"
LV="lv_app"
MAX_SNAPS=3
SNAP_PREFIX="${LV}_autosnap"
TIMESTAMP=$(date +%Y%m%d_%H%M)

# Yeni snapshot al
lvcreate -L5G -s -n "${SNAP_PREFIX}_${TIMESTAMP}" "/dev/${VG}/${LV}" 2>&1

# Eski snapshot'ları say ve temizle
EXISTING=$(lvs --noheadings -o lv_name | grep "^  ${SNAP_PREFIX}" | sort)
COUNT=$(echo "$EXISTING" | wc -l)

if [ "$COUNT" -gt "$MAX_SNAPS" ]; then
    REMOVE_COUNT=$((COUNT - MAX_SNAPS))
    echo "$EXISTING" | head -n "$REMOVE_COUNT" | while read snap; do
        snap=$(echo $snap | tr -d ' ')
        echo "Removing old snapshot: $snap"
        lvremove -f "/dev/${VG}/${snap}"
    done
fi
# Crontab'a ekle: Her gece 02:00'de çalışsın
sudo crontab -e
# Şu satırı ekle:
# 0 2 * * * /usr/local/bin/lvm_snapshot_rotate.sh >> /var/log/snapshot_rotate.log 2>&1

Snapshot Sağlık Monitörü

#!/bin/bash
# snapshot_monitor.sh
# LVM snapshot'larının doluluk oranını kontrol eder

THRESHOLD=80

while IFS= read -r line; do
    SNAP_NAME=$(echo "$line" | awk '{print $1}')
    SNAP_PERCENT=$(echo "$line" | awk '{print $2}' | tr -d '%')
    
    if [ -n "$SNAP_PERCENT" ] && [ "$SNAP_PERCENT" -ge "$THRESHOLD" ]; then
        echo "UYARI: $SNAP_NAME snapshot'ı %${SNAP_PERCENT} dolu!"
        # Burada mail veya slack alert gönderilebilir
        # echo "Snapshot kritik: $SNAP_NAME" | mail -s "Snapshot Alert" [email protected]
    fi
done < <(sudo lvs --noheadings -o lv_name,snap_percent | grep -v '^s*$' | awk '$2 != ""')

Snapshot Stratejisi Kurarken Dikkat Edilecekler

Ne Zaman Snapshot Almalısın?

  • Sistem güncellemesi (apt upgrade, yum update, zypper patch) öncesi
  • Kernel değişikliği öncesi
  • Uygulama major versiyon güncellemesi öncesi
  • Konfigürasyon değişikliği öncesi (özellikle database config)
  • Production’a deploy öncesi

Ne Zaman Snapshot Kullanmamalısın?

  • Uzun dönem arşivleme için: Snapshot’lar backup değildir, aynı fiziksel disk üzerinde yaşarlar
  • Büyük veri değişimlerinde uzun süre tutmak için: Snapshot ne kadar uzun kalırsa performans o kadar düşer
  • Disk dolmak üzereyken: Snapshot dolunca invalid olur ve o noktaya geri dönemezsin

Snapshot Boyutlandırma Mantığı

LVM snapshot boyutunu hesaplarken şu düşünce yapısını kullan:

  • Snapshot canlıyken ne kadar veri değişecek?
  • Log dosyaları var mı, ne kadar büyüyecekler?
  • Database write-heavy mi?

Genel kural: Kaynak volume’ün %10-20’si veya beklenen değişim miktarının 2 katı. Kararsız kalırsan büyük al, snapshot alanı boş kalmak üretim verisini bozmaz.

Veritabanı Tutarlılığı

Snapshot alırken veritabanı çalışıyorsa crash-consistent bir snapshot alırsın. Bu genellikle yeterli (InnoDB crash recovery yapabilir) ama application-consistent snapshot için:

# MySQL/MariaDB için flush ve lock
mysql -u root -p -e "FLUSH TABLES WITH READ LOCK; FLUSH LOGS;"

# Snapshot al
sudo lvcreate -L5G -s -n lv_data_snap /dev/vg_prod/lv_data

# Lock'u bırak
mysql -u root -p -e "UNLOCK TABLES;"

Rollback Kararı: Ne Zaman Geri Dönersin?

Rollback kararı vermek teknik bir karar olduğu kadar operasyonel bir karar da. Şu kriterleri kullanıyorum:

  • Servis tamamen çöktüyse ve 15 dakikada düzeltemiyorsan: Rollback yap, debug etmeye devam et
  • Hata intermittent’sa: Önce log’ları incele, acele rollback yapma
  • Veri bütünlüğü riske girdiyse: Hemen rollback yap
  • Sadece bir feature çalışmıyorsa: Rollback yerine hotfix değerlendir

Rollback’in de maliyeti var. Güncelleme ile gelen güvenlik yamaları geri alınır, snapshot alındıktan sonra yapılan meşru değişiklikler (örneğin manuel config düzenlemeleri) kaybolur. Bu yüzden rollback öncesi neyi kaybedecektin bil.

Sonuç

Snapshot ve rollback stratejisi, sysadmin araç kutusunun vazgeçilmez bir parçası. Ama etkili olması için planlı kullanılması gerekiyor. Rasgele snapshot almak ve “gerekirse dönerim” demek yeterli değil. Boyutlandırma, rotasyon politikası, tutarlılık ve monitoring bu stratejinin ayakta durmasını sağlayan dört sütun.

En önemli çıkarım şu: Snapshot’ı bir güvenlik ağı olarak gör, backup’ın yerini tutan bir çözüm olarak değil. ZFS, LVM veya sanallaştırma hangisini kullanırsan kullan, offsite backup’ınla birlikte çalışan bir snapshot stratejisi kur.

Bir sonraki büyük güncelleme öncesi bu yazıdaki script’leri adapt et, test ortamında bir kez rollback yaptığından emin ol. Çünkü kriz anında ilk kez öğrenmek istemezsin.

Bir yanıt yazın

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