Snapshot Yedekleme ve Hızlı Kurtarma: Saniyede Block-Level Geri Yükleme

Bozulan bir sistemi geri yüklemeniz gerektiğinde, snapshot yedekleme ve hızlı kurtarma stratejisi her şeyi değiştirir. Dosya tabanlı yedeklerin veriyi geri kopyalamasını saatlerce beklemek yerine, block-level snapshot'larla tüm bir volume'u veya VM'i saniyeler içinde geri alabilirsiniz. Benim ortamımda bu yaklaşım, kritik e-ticaret sunucularında geri yükleme sürelerini 45 dakikadan 10 saniyenin altına düşürdü. Hala sadece rsync veya tar tabanlı dosya yedeklemelerine güveniyorsanız, ciddi RTO'larda kaybediyorsunuz.

Temel fikir basit: tek tek dosyaları kopyalamak yerine, belirli bir andaki storage block durumunu yakalarsınız. Bir şey bozulduğunda dosyaları değil, blokları geri yüklersiniz. Dosya sisteminin ne olduğunu anlamasına bile gerek yok — sadece snapshot anındaki durumu görür.

Dosya Tabanlı vs Block-Level Yedekler: Fark Neden Önemli

Dosya tabanlı yedekler tek tek belgeler veya küçük dizinler için gayet iyi çalışır. Hala belirli kullanım senaryolarında bunları kullanıyorum. Ama bir production database bozulduğunda veya ransomware tüm bir volume'ı şifrelediğinde, dosya tabanlı geri yükleme acı verici şekilde yavaştır.

Nedenine gelirsek:

Dosya seviyesi geri yükleme metadata okur, dizinleri dolaşır, izinleri kontrol eder ve her dosyayı tek tek yazar
Block-level snapshot'lar raw storage durumunu yakalar; inode'lar, journal verisi ve tahsis edilmiş bloklar dahil
500GB'lık bir volume'u dosya kopyalamayla geri yüklemek 40 dakika sürebilir; snapshot rollback ile aynı volume saniyeler sürer
Block snapshot'lar ayrıca dosya tabanlı araçların genellikle kaçırdığı veya bozduğu açık dosyaları ve database durumlarını yakalar

PostgreSQL replica'larının bozulduğunu gördüm çünkü dosya tabanlı yedekleme yarım yazılmış bir WAL dosyasını yakalamıştı. Block snapshot'larında bu sorun yok — dosya sisteminin altındaki storage katmanını yakalarlar, dolayısıyla tutarlılık block seviyesinde korunur.

Block-Level Snapshot'lar Gerçekte Nasıl Çalışır

Snapshot'lar tüm verinizi anında kopyalamaz. Junior adminlerden duyduğum yaygın bir yanılgıdır bu. Gerçekte olan, sistemin snapshot noktasından sonra değişen blokları takip etmek için copy-on-write (COW) veya redirect-on-write (ROW) kullanmasıdır.

Snapshot oluşturduğunuzda, sistem mevcut durumu bir geri yükleme noktası olarak işaretler. Yeni yazımlar yeni bloklara gider veya yönlendirilir. Orijinal bloklar snapshot'ı silene kadar donmuş halde kalır. Yani snapshot oluşturma, volume boyutundan bağımsız olarak neredeyse anındadır.

Kamu sektörü altyapısında yoğun olarak kullandığım Proxmox'da ZFS bunu harika şekilde yönetir:

# Create a snapshot of a VM disk
zfs snapshot rpool/data/vm-100-disk-0@pre-update-20250115

# List snapshots
zfs list -t snapshot

# Rollback to that snapshot in seconds
zfs rollback rpool/data/vm-100-disk-0@pre-update-20250115

O rollback komutu çalıştıracağınız en hızlı kurtarmadır. VM diski snapshot noktasındaki tam durumuna döner — her dosya, her database kaydı, her sistem config'i. Dosya kopyalama yok, izin sorunu yok, yarım durum yok.

Production Sunucuları için Gerçek Dünya Snapshot Stratejisi

Plansız rastgele snapshot'lar almak çözdüğünden daha fazla sorun yaratır. RPO ve RTO gereksinimlerinize uyan bir retention policy'e ihtiyacınız var. İşte altyapımda uyguladıklarım:

Update öncesi snapshot'lar: Herhangi bir patch veya config değişikliğinden önce her zaman snapshot alın. Bu beni sayamayacağım kadar çok kurtardı.
Mesai saatlerinde saatlik snapshot'lar: 24 saat tutulur. Yanlışlıkla silmeler ve kötü commit'leri kapsar.
Günlük snapshot'lar: 7 günlük retention. Hafta sonu felaketlerini ve pazartesi sabahı sürprizlerini yönetir.
Haftalık snapshot'lar: 4 haftalık retention. Daha uzun vadeli rollback ihtiyaçlarını kapsar.

Önemli olan otomasyon. Manuel snapshot oluşturmaya güvenmem — biri her zaman unutur. ZFS için basit bir cron yaklaşımı:

# /etc/cron.d/zfs-snapshots
# Hourly snapshot at :05
5 * * * * root zfs snapshot -r rpool/data@hourly-$(date +\%H)
# Daily at 02:00
0 2 * * * root zfs snapshot -r rpool/data@daily-$(date +\%Y\%m\%d)
# Cleanup old snapshots
30 2 * * * root zfs destroy -r rpool/data@hourly-*[0,1,2,3,4,5,6,7,8,9]

Snapshot Yedeklemelerinde Yaygın Hatalar

Snapshot'lar tek başlarına yedek değildir. Bunu net bir şekilde söylemem lazım çünkü yedek tartışmalarında en tehlikeli yanılgı budur. Snapshot, orijinal veriyle aynı storage üzerinde yaşar. Disk bozulursa, snapshot da onunla birlikte bozulur.

Bunu yönetmek için yaptıklarım:

zfs send ve zfs receive kullanarak snapshot'ları ayrı bir storage pool'a replicate etme
Felaket kurtarma için kritik snapshot'ları offsite storage'a gönderme
Geri yüklemeleri çeyrek yılda bir test etme — test edilmemiş yedek, dosya sistemine sahip bir umuttan ibaret

# Replicate snapshot to backup pool
zfs send rpool/data/vm-100-disk-0@daily-20250115 | zfs receive bpool/backup/vm-100-disk-0

# Incremental replication (only changed blocks)
zfs send -I rpool/data/vm-100-disk-0@daily-20250114 rpool/data/vm-100-disk-0@daily-20250115 | zfs receive bpool/backup/vm-100-disk-0

O incremental send sadece snapshot'lar arasında değişen blokları transfer eder. Günlük 2GB değişiklik olan 500GB'lık bir diskte 500GB değil, 2GB gönderirsiniz. Snapshot replication'ı daha yavaş ağ bağlantılarında uygulanabilir kılan da budur.

Başka bir tuzak: snapshot retention storage kullanımını sessizce büyütür. COW, her snapshot'ın eski blokları canlı tuttuğu anlamına gelir. Hızla değişen bir database'in 30 snapshot'ı varsa, storage kullanımınız hızla şişebilir. Snapshot alanını izleyin ve agresif budayın.

Snapshot'ları Geleneksel Yedeklerle Ne Zaman Birleştirmeli

Snapshot'ları tüm yedeklerin yerine koymuyorum. Kurtarma stratejimde farklı amaçlara hizmet ederler. Snapshot'lar size hız verir. Geleneksel yedekler dayanıklılık ve offsite koruma sağlar.

Daha önce bulut yedekleme maliyet optimizasyonu yazımda (https://furkanikkan.com/urun/bulut-yedekleme-maliyet-optimizasyonu-faturayi-dusuren-5-yontem-59) bahsettiğim gibi, yedekleme stratejilerini katmanlandırmak maliyetleri makul tutup sağlam RTO'yu korumanın yoludur. Aynı prensip burada da geçerli.

Katmanlı yaklaşımım:

Katman 1: Anında yerel kurtarma için ZFS snapshot'ları (RTO: saniyeler)
Katman 2: İkincil bir node'a ZFS replication (RTO: dakikalar)
Katman 3: Offsite S3 uyumlu storage'a haftalık dosya tabanlı yedek (RTO: saatler, ama site çöküşünden kurtulur)

Bu bana yaygın durumlar için hızlı kurtarma verir (kötü update, yanlışlıkla silme, config hatası) ve felaket niteliğindeki çöküşler için de bir güvenlik ağı sağlar.

Snapshot Kurtarma Planınızı Test Etmek

Staging ortamında snapshot geri yüklemelerini aylık olarak test ediyorum. Rollback'in kendisini değil — o her zaman çalışır. Tam workflow'u test ederim: sorunu tespit et, doğru snapshot'ı seç, rollback yap, uygulamanın temiz başladığını doğrula ve veri bütünlüğünü kontrol et.

Rollback kolaydır. Hangi snapshot'a rollback yapılacağını bilmek zor kısımdır. Production sistemi sabah 3'te bozulduğunda, 02:00'daki saatlik snapshot mı yoksa 01:00'daki mı temiz duruma sahip olduğunu tahmin etmek istemezsiniz. Snapshot noktalarınızı belgelendirin ve anlamlı şekilde etiketleyin.

İpucu: Açıklayıcı snapshot isimleri kullanın. Gece stres altında debug yaparken snap-1234567890 yerine pre-nginx-config-change sonsuz daha faydalıdır.

Block-level snapshot'lar kurtarmayı yönetme şeklimi değiştirdi. 200GB'lık bozulmuş bir database volume'unu 8 saniyede rollback yaptığınızda, bir daha asla dosya tabanlı geri yüklemeye dönmek istemezsiniz. Ama sadece snapshot komutunu değil — replication, retention, testing içeren tam stratejiyi kurun.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/computer-hard-2J3PLNMO9M