Sanal Makine Snapshot Yönetimi ve Riskleri

Bir güncelleme öncesi "bir snapshot alayım da bir şey olursa dönerim" cümlesini kurmayan sistem yöneticisi yoktur. Sanal makine snapshot özelliği gerçekten de hayat kurtarır; ama aynı özellik, unutulduğunda bir gece yarısı diski dolduran, sanal makineyi durduran ve saatlerce sürecek bir birleştirme işlemine sebep olan en sinsi risklerden biridir. Snapshot'ın ne olduğunu bilmek yetmez, diskte tam olarak ne yaptığını ve zaman geçtikçe nasıl davrandığını bilmek gerekir.

Bu rehberde snapshot'ın altyapıda gerçekte ne yarattığını, hangi durumlarda alınmasının doğru olduğunu, neden hiçbir zaman bir yedek yerine geçmediğini, zincir büyüdüğünde ne tür performans ve alan sorunlarının çıktığını ve snapshot silme (consolidate) işleminin neden bazen alan tüketerek başladığını anlatacağım. VMware ESXi, Proxmox VE ve Hyper-V için gerçek komutlarla örnekler vereceğim, sonda da yıllardır aynı biçimde tekrarlanan hataları tek tek toplayacağım.

Snapshot Tam Olarak Nedir ve Diskte Ne Olur#

Snapshot, bir sanal makinenin belirli bir andaki durumunun dondurulmuş bir görüntüsüdür. Ama önemli olan kısım şu: snapshot alındığında sanal diskinizin bir kopyası çıkarılmaz. Bunun yerine mevcut disk dosyası salt okunur hâle getirilir ve o andan itibaren yapılan tüm yazma işlemleri yeni bir "delta" (fark) dosyasına yönlendirilir. Yani snapshot aslında bir kopya değil, bir dallanma noktasıdır.

VMware tarafında bunu dosya sisteminde açıkça görürsünüz. Snapshot almadan önce datastore'da tek bir disk dosyanız vardır; snapshot aldıktan sonra yanına delta dosyaları eklenir:

# ESXi kabuğunda sanal makinenin klasörüne bak
ls -lh /vmfs/volumes/datastore1/web01/

# Snapshot ÖNCESİ:
# web01.vmdk           (tanım dosyası)
# web01-flat.vmdk      40G  (asıl veri)

# Snapshot SONRASI:
# web01.vmdk           (artık salt okunur)
# web01-flat.vmdk      40G  (dondu)
# web01-000001.vmdk    (delta tanımı)
# web01-000001-delta.vmdk  1.2G  (bu andan sonraki TÜM yazmalar burada)
# web01-Snapshot1.vmsn (RAM ve VM durumu, bellek dahil edildiyse)

Buradaki -delta dosyası zamanla büyür ve büyüme hızı doğrudan sanal makinenin yazma yoğunluğuna bağlıdır. Veritabanı çalıştıran bir makinede bu dosya günde onlarca gigabayt büyüyebilir; sadece log tutan durgun bir makinede ise haftada birkaç yüz megabayt kalabilir. Proxmox tarafında ise altta ne kullandığınıza göre davranış değişir: ZFS ve LVM-thin üzerinde snapshot blok seviyesinde ve neredeyse maliyetsiz alınır, qcow2 dosya formatında ise dosyanın içine yeni bir katman yazılır. Depolama katmanınızın nasıl davrandığını bilmiyorsanız disk kullanımı df du ncdu yazısı, alan tüketimini doğru okumanız için iyi bir başlangıç.

Snapshot Almanın Doğru Zamanı ve Adımları#

Snapshot'ın tek meşru kullanım amacı vardır: kısa süreli, geri dönülebilir bir değişiklik penceresi açmak. Çekirdek güncellemesi, uygulama sürüm yükseltmesi, sürücü değişikliği, riskli bir yapılandırma denemesi. Bu işlerin ortak özelliği birkaç saat içinde ya başarıyla biteceği ya da geri alınacağıdır. Snapshot bu pencerenin dışına taştığı anda faydadan çok zarar üretmeye başlar.

Doğru bir snapshot alma akışı şöyle işler:

1. Diskte boş alan olduğunu doğrulayın. Kural olarak, snapshot alacağınız makinenin disk boyutunun en az yarısı kadar boş alan bırakın.
2. Mümkünse sanal makineyi tutarlı bir noktada bırakın: veritabanını flush edin, uygulamayı bakım moduna alın.
3. Snapshot'a bellek dahil etmeyin (memory snapshot). Bellek almak snapshot süresini uzatır, dosya boyutunu RAM kadar şişirir ve çoğu bakım işinde hiçbir işe yaramaz.
4. Snapshot'a anlamlı bir isim ve açıklama verin: 2026-08-25-kernel-6.8-oncesi gibi. "Snapshot1" adında bir dosyanın neden alındığını üç hafta sonra kimse hatırlamaz.
5. Takviminize aynı gün için bir silme hatırlatması koyun.

Adım 5 ciddi bir öneri. Snapshot'ları unutulmuş hâlde bulmanın en yaygın sebebi, alan kişinin işi bitirip silmeyi ertelemesidir. VMware ortamında snapshot alma komutları şöyle:

# Çalışan sanal makineleri ve ID'lerini listele
vim-cmd vmsvc/getallvms

# Snapshot al: vmid, ad, açıklama, bellek dahil mi, sessize al mı
vim-cmd vmsvc/snapshot.create 12 "2026-08-25-kernel-oncesi" "Kernel guncellemesi" 0 1

# Mevcut snapshot ağacını gör
vim-cmd vmsvc/snapshot.get 12

Buradaki 0 1 parametreleri sırasıyla "belleği dahil etme" ve "dosya sistemini sessize al (quiesce)" anlamına gelir. Quiesce, VMware Tools kuruluysa konuk işletim sistemine disk tamponlarını boşaltmasını söyler ve snapshot'ın tutarlılığını ciddi biçimde artırır. VMware Tools kurulu değilse bu bayrak sessizce göz ardı edilir; kurulum sonrası kontrol listenizde VMware Tools mutlaka bulunsun. ESXi tarafında henüz kurulum yapmadıysanız VMware ESXi kurulumu rehberi baştan sona adımları anlatıyor.

Snapshot Bir Yedek Değildir#

Bu bölümü ayrı bir başlık yaptım çünkü sahada en pahalıya patlayan yanlış anlama budur. Snapshot bir yedek değildir ve asla bir yedeğin yerine geçemez. Sebebi teknik ve çok net: snapshot, asıl disk dosyasına bağımlıdır. Delta dosyası tek başına hiçbir işe yaramaz; üzerine kurulduğu ana disk bozulursa, silinirse ya da altındaki fiziksel disk arızalanırsa snapshot da onunla birlikte gider.

Aradaki farkı bir tabloda netleştirelim:

Snapshot'ın tek gerçek üstünlüğü geri dönüş hızıdır. On dakika önceki hâle saniyeler içinde dönmek istiyorsanız snapshot doğru araçtır. Ama üç gün önceki hâle, silinmiş bir dosyaya ya da bir fidye yazılımı saldırısı öncesine dönmek istiyorsanız ihtiyacınız olan şey bir yedekleme stratejisidir. Uygulamalı bir yedek kurulumu için Borg ile sunucu yedekleme yazısındaki yaklaşımı sanal makine seviyesine de taşıyabilirsiniz; hazır bir çözüm tercih ederseniz yedekleme hizmetimiz sanal makine imajlarını ayrı bir depolama alanında saklar.

Bir noktayı daha ekleyeyim: snapshot'ı olan bir sanal makine, altındaki fiziksel diskte bir sorun çıktığında iki kat kırılgandır, çünkü artık tek değil iki dosyaya birden bağımlıdır. Fiziksel disk sağlığını nasıl izleyeceğinizi disk arızası tespiti SMART ve RAID yazısında bulabilirsiniz.

Snapshot Zinciri Büyüdüğünde Ne Olur#

Bir snapshot varken ikinci bir snapshot alırsanız zincir uzar: her yeni delta, bir öncekinin üzerine biner. Üç snapshot'lı bir makinede disk okuması artık üç dosya arasında gezinmek zorundadır; okunan blok en üstteki deltada yoksa bir alta, orada da yoksa daha alta bakılır. Bu arama zinciri her katmanla birlikte gecikme ekler.

Etkisi doğrusal değil, kümülatiftir ve en çok rastgele okuma yapan iş yüklerinde hissedilir. Kabaca beklenebilecek davranış şöyledir:

En tehlikeli senaryo, delta dosyasının datastore'daki tüm boş alanı tüketmesidir. Bu olduğunda ESXi sanal makineyi yazma yapamadığı için durdurur; makine "paused" durumuna düşer ve siz alan açana kadar orada bekler. Bu tam olarak gece yarısı olur ve hiçbir uyarı vermeden gelmez — datastore doluluk alarmı kurulmuş olsaydı önceden görülürdü. Alan tükenmesinin genel semptomlarını ve kurtarma yollarını disk dolu no space left çözümü yazısında bulabilirsiniz.

Kaç snapshot'ınız olduğunu düzenli olarak taramak iyi bir alışkanlıktır:

# ESXi: datastore genelinde delta dosyalarını bul
find /vmfs/volumes/ -name "*-delta.vmdk" -exec ls -lh {} \;

# Proxmox: tüm sanal makinelerin snapshot listesi
for id in $(qm list | awk 'NR>1{print $1}'); do
  echo "== VM $id =="
  qm listsnapshot $id
done

Snapshot Silme ve Birleştirme Tuzağı#

Snapshot silmek "delta dosyasını çöpe atmak" değildir. Aksine, silme işlemi deltadaki tüm değişiklikleri ana diske geri yazmak demektir; buna consolidate ya da commit denir. Yani snapshot silmek bir yazma fırtınası başlatır ve zincir ne kadar uzunsa o kadar uzun sürer.

Burada iki tuzak vardır. Birincisi: silme işlemi sırasında geçici olarak daha fazla disk alanı gerekebilir. Alanınız kritik seviyedeyse ve "snapshot'ı silersem yer açılır" diye düşünüp silmeye başlarsanız, işlem yer bulamayıp yarıda kalabilir. Bu yüzden alan sıkışmasını snapshot silerek çözmeye kalkışmadan önce başka bir yerden birkaç gigabayt açın.

İkincisi: birleştirme sırasında sanal makine çalışmaya devam eder ve yazmaya devam eder. Çok yoğun yazan bir makinede birleştirme, deltayı kapatmaya çalışırken deltanın büyümesine yetişemez. Bu yüzden büyük birleştirmeleri düşük trafikli saatlerde planlayın.

# ESXi: tüm snapshot'ları sil (birleştir) — snapshotId 1'den başlar
vim-cmd vmsvc/snapshot.removeall 12

# Tek bir snapshot'ı sil: vmid, snapshotId, removeChildren
vim-cmd vmsvc/snapshot.remove 12 1 0

# Proxmox: snapshot sil
qm delsnapshot 105 kernel-oncesi

# Hyper-V (PowerShell): checkpoint sil, birleştirme arka planda başlar
Remove-VMSnapshot -VMName "WEB01" -Name "kernel-oncesi"

Hyper-V tarafında bir ayrıntı var: checkpoint silindiğinde birleştirme hemen tamamlanmaz, .avhdx dosyası arka planda ana .vhdx içine yedirilir. Silme komutunun dönmesi işin bittiği anlamına gelmez; Get-VHD ile dosyanın hâlâ farklı bir üst diske bağlı olup olmadığını kontrol edin.

Platform Farkları ve Hangi Sınırları Bilmelisiniz#

Snapshot davranışı platformdan platforma ciddi biçimde değişir ve bir platformda güvenli olan alışkanlık diğerinde risk üretebilir. Aşağıdaki tablo pratikte en çok işinize yarayacak farkları özetliyor:

Proxmox'ta LVM-thin kullanıyorsanız özellikle dikkatli olun: thin havuz yüzde yüze ulaştığında yalnızca snapshot'lar değil, üzerindeki tüm makineler etkilenir ve bazı senaryolarda veri kaybı yaşanır. Havuz doluluğu için mutlaka eşik alarmı kurun. XCP-ng tarafında ise arka plandaki coalesce görevinin takılıp kalması klasik bir sorundur; kurulum ve yönetim detayları için XCP-ng kurulumu yazısına bakabilirsiniz.

Ham işlem gücü ile snapshot maliyeti arasındaki ilişkiyi de göz ardı etmeyin: zincirli disk erişimi CPU'ya da yük bindirir. Zaten sıkışık bir çekirdek bütçesi üzerinde çalışıyorsanız CPU overcommit yazısındaki ölçüm yöntemleri, yavaşlamanın kaynağını ayırt etmenizi kolaylaştırır.

Sık Yapılan Hatalar#

Yıllardır aynı hataları görüyorum; hepsi önlenebilir ve hepsi maliyetli.

Snapshot'ı düzenli yedek yerine kullanmak. Haftalık "yedek" olarak snapshot alan ekipler, ana disk bozulduğunda hiçbir şey kurtaramaz. Snapshot ile yedeği aynı cümlede kullanmayın.

Bellek dahil snapshot almak. Rutin bakım işlerinde belleğe ihtiyacınız yoktur. Bellek dahil snapshot, RAM boyutu kadar ek dosya üretir ve snapshot alma anında makineyi saniyelerce durdurur.

Snapshot varken diski büyütmek. Snapshot açıkken sanal disk boyutunu değiştirmek çoğu platformda ya reddedilir ya da zinciri tutarsız hâle getirir. Önce birleştirin, sonra büyütün.

Datastore alarmı kurmamak. Yüzde 80 doluluk için uyarı, yüzde 90 için kritik alarm kurulmamışsa snapshot'ın diski doldurduğunu ancak makine durduğunda öğrenirsiniz.

Snapshot'ı yükseltme testi için alıp sonra "her ihtimale karşı" bırakmak. Bu, unutulan snapshot'ların bir numaralı doğuş biçimidir. Bakım penceresi kapandıysa snapshot da kapanmalıdır.

Yedekleme yazılımının bıraktığı snapshot'ları görmezden gelmek. Ajan tabanlı yedekleme araçları iş sırasında snapshot alır ve normalde siler; iş yarıda kaldığında geride kalan snapshot haftalarca fark edilmeden büyür. Tarama betiğinizi bunları da yakalayacak biçimde yazın.

Sıkça Sorulan Sorular#

Snapshot ne kadar süre tutulabilir#

Pratik kural şudur: 24 saatten uzun tutmayın, 72 saati kesinlikle aşmayın. Snapshot bir bakım penceresi aracıdır ve pencere kapandığında silinmelidir. Bunun ötesinde tutulan her snapshot hem delta dosyasının büyümesi hem de birleştirme süresinin uzaması anlamına gelir. Uzun süreli saklamaya ihtiyacınız varsa doğru araç snapshot değil, ayrı depolamada tutulan bir yedektir.

Snapshot almak sanal makineyi durdurur mu#

Kısa bir an için evet, ama fark edilmeyecek kadar kısa. Snapshot alınırken sanal makine birkaç yüz milisaniye ile birkaç saniye arasında duraklar (stun); bu süre disk sayısına ve depolama hızına bağlıdır. Belleği de dahil ettiğinizde bu süre RAM boyutuyla orantılı olarak uzar ve saniyeler seviyesine çıkabilir. Bu yüzden rutin bakım snapshot'larında belleği dahil etmemek en iyi uygulamadır.

Snapshot silmek veri kaybına yol açar mı#

Hayır, snapshot silmek veri kaybetmez; tam tersine snapshot alındıktan sonra yapılan tüm değişiklikleri ana diske kalıcı olarak yazar. Veri kaybettiren işlem "snapshot'a geri dön" (revert) komutudur, çünkü o komut snapshot anından sonraki her şeyi atar. Bu iki komutu birbirine karıştırmamak için panelde işlem yaparken düğme adını dikkatle okuyun.

Snapshot yedek yerine geçer mi#

Geçmez. Snapshot ana disk dosyasına bağımlı bir katmandır; ana disk ya da altındaki fiziksel depolama bozulursa snapshot da kullanılamaz hâle gelir. Ayrıca aynı sunucuda durduğu için bir fidye yazılımı saldırısında şifrelenebilir ya da silinebilir. Gerçek koruma için verinin farklı bir makinede, tercihen değiştirilemez biçimde saklandığı bir yedekleme düzeni kurmanız gerekir.

Kaç tane snapshot alabilirim#

Teknik olarak platformlar onlarca snapshot'a izin verir, ama pratikte aynı anda ikiden fazla snapshot tutmamak gerekir. Her katman disk okumasına gecikme ekler ve birleştirme süresini katlar. Üç ve üzeri derinlikteki zincirlerde hem gözle görülür yavaşlama hem de saatler süren birleştirme işlemleri normaldir. Sağlıklı bir ortamda "sıfır snapshot" varsayılan durum olmalıdır.

Unutulmuş snapshot'ları nasıl bulurum#

En güvenilir yöntem, dosya sistemini doğrudan taramaktır çünkü panel bazen zombi kalmış dosyaları göstermez. ESXi'de find /vmfs/volumes/ -name "*-delta.vmdk", Proxmox'ta qm listsnapshot döngüsü, Hyper-V'de Get-VMSnapshot -VMName * komutlarını haftalık bir görev olarak çalıştırın. Ayrıca datastore doluluk alarmı kurun; alan tüketimindeki ani artış çoğu zaman unutulmuş bir snapshot'ın ilk sinyalidir.

Snapshot alırken bellek dahil edilmeli mi#

Çoğu bakım işinde hayır. Bellek dahil snapshot yalnızca çalışan uygulamanın tam durumuna geri dönmeniz gereken özel durumlarda anlamlıdır; örneğin bir hata ayıklama oturumunu dondurmak istediğinizde. Rutin güncelleme ve yükseltme işlerinde belleği dahil etmek snapshot süresini uzatır, dosya boyutunu şişirir ve geri dönüşte fayda sağlamaz.

Kapanış#

Snapshot, kısa süreli ve geri dönülebilir bir değişiklik penceresi açmak için mükemmel bir araçtır; onu bir yedekleme yöntemi ya da uzun vadeli bir güvenlik ağı olarak gördüğünüz anda ise sizi düşüren şeye dönüşür. Aklınızda kalması gereken dört alışkanlık şunlar: snapshot almadan önce boş alanı doğrulayın, isim ve tarih verin, aynı gün için silme hatırlatması koyun, ve datastore doluluk alarmınızı mutlaka kurun. Zinciri asla ikiden derin tutmayın ve büyük birleştirmeleri düşük trafikli saatlere planlayın.

Sanallaştırma altyapınızı kendi elinizle yönetmek istiyorsanız tam root erişimli VDS ve sanal sunucu paketlerimizle kendi hypervisor kurulumunuzu yapabilir, kaynak esnekliği arıyorsanız bulut sunucu tarafına bakabilirsiniz. Snapshot'ın kapatamadığı boşluğu doldurmak için yedekleme hizmetimiz sanal makine imajlarınızı ayrı depolamada saklar; günlük bakım, alarm kurulumu ve birleştirme planlaması gibi işleri üstlenmemizi isterseniz sunucu yönetimi hizmetimiz bu yükü sizin yerinize taşır.