VMware Snapshot Silinemiyor Hatası Nasıl Güvenle Çözülür?

VMware snapshot silinemiyor hatası, vSphere Client üzerinde snapshot kaldırma görevinin başarısız olması, uzun süre yüzde 95–99 seviyesinde kalması veya “Unable to access file”, “File is locked” ve “The operation is not allowed in the current state” gibi mesajlar vermesiyle görülür. Bu problem, yalnızca snapshot ağacını değil, sanal makinenin disk zincirini ve datastore alanını da etkileyebilir. Güvenli çözüm; önce görev çakışmasını, boş alanı, dosya kilidini ve ESXi günlüklerini doğrulamak, ardından hatanın nedenine uygun silme ya da birleştirme işlemini kontrollü yürütmektir. Snapshot dosyalarını datastore üzerinden elle silmek veya VMDK tanım dosyalarını düzenlemek veri kaybına yol açabilir.

Belirti ve kapsam: Snapshot silme neden kritik bir işlemdir?

VMware snapshot, sanal makinenin o andan sonraki disk değişikliklerini delta disklerde tutar. Snapshot silme işlemi bu değişiklikleri temel diske veya üstteki snapshot katmanına işler. Bu nedenle işlem, snapshot boyutu, yazma yoğunluğu ve depolama gecikmesine göre uzun sürebilir. Görevin uzun sürmesi tek başına hata olduğu anlamına gelmez.

Ancak görev hata verirse veya yarım kalırsa snapshot yöneticisinde görünen ağaç ile datastore üzerindeki dosyalar farklılaşabilir. Özellikle yoğun çalışan veritabanı, dosya sunucusu ve uygulama sunucularında rastgele yeniden deneme yapmak disk I/O yükünü artırabilir.

Hızlı teşhis özeti

• vSphere Client içindeki görev ayrıntısındaki tam hata metnini ve zamanı kaydedin.
• Aynı sanal makinede çalışan yedekleme, replikasyon, storage vMotion veya başka snapshot görevi olup olmadığını kontrol edin.
• Snapshot işleminin hedef datastore’unda yeterli boş alan bulunduğunu doğrulayın.
• VM üzerinde etkin snapshot ağacını ve ESXi tarafında görev durumunu görüntüleyin.
• hostd.log, vpxa.log ve gerektiğinde vmkernel.log içinde hata zamanını arayın.
• “File is locked” bulgusunda kilit sahibini belirlemeden hiçbir VMDK, delta veya snapshot dosyasını silmeyin.

VMware snapshot silinemiyor hatasının yaygın nedenleri

Neden	Tipik belirti	Güvenli yaklaşım
Yetersiz datastore alanı	Silme/birleştirme görevi alan hatasıyla durur	Alan açın veya uygun planlama ile depolama kapasitesini artırın
Dosya kilidi	“File is locked”, “Unable to access file”	Kilit sahibini tespit edin; ilgili host, işlem veya yedekleme oturumunu değerlendirin
Çakışan görev	Başka snapshot, yedek, replikasyon veya taşıma işlemi sürer	Çakışan işi güvenli biçimde tamamlayın ya da durdurun
Yedekleme yazılımı snapshotı	Snapshot beklenmedik şekilde yeniden oluşur veya görev meşguldür	Yedekleme konsolundaki aktif işi ve VADP oturumlarını kontrol edin
ESXi yönetim ajanı sorunu	Görev zaman aşımına uğrar, arayüz durumu güncellenmez	Logları doğrulayın; bakım penceresinde yönetim ajanı müdahalesini değerlendirin
Disk zinciri veya depolama erişim sorunu	I/O hataları, APD/PDL veya VMDK erişim hataları	Önce datastore ve storage katmanını düzeltin; snapshot işlemini zorlamayın

Loglar ve komutlarla güvenli teşhis

1. vSphere görev kaydını ve çakışan işleri inceleyin

vSphere Client’ta ilgili sanal makinenin Monitor > Tasks and Events alanına bakın. Hata metnini kopyalayın; hata saati, görev kimliği ve işlemi başlatan kullanıcı/servis hesabı sonraki inceleme için önemlidir. Aynı zaman aralığında çalışan yedekleme, replikasyon veya taşıma işi varsa önce o işin gerçekten tamamlanıp tamamlanmadığını ilgili ürün konsolunda doğrulayın.

ESXi Shell veya SSH erişimi yalnızca yetkili yönetici tarafından ve kurum güvenlik politikasına uygun şekilde kullanılmalıdır. VM kimliğini ve mevcut snapshot bilgisini görmek için:

vim-cmd vmsvc/getallvms
vim-cmd vmsvc/snapshot.get VMID

VMID yerine ilk komutun döndürdüğü sayısal sanal makine kimliğini yazın. Snapshot bilgisi yokken arayüzde silme hatası görülüyorsa, sorun kalan disk dosyaları veya ayrı bir birleştirme ihtiyacı olabilir. Bu durum, aktif snapshot ağacını silme işleminden farklı ele alınmalıdır.

2. Datastore boş alanını ve VM dizinini kontrol edin

Silme işlemi sırasında ek çalışma alanı gerekebilir. Kesin ihtiyaç; snapshot zinciri, disk düzeni ve anlık yazma yüküne bağlıdır. Datastore’u tamamen dolduracak şekilde işlem başlatmayın. ESXi üzerinde bağlı datastore’ları görmek için:

esxcli storage filesystem list
df -h

Ardından sanal makinenin bulunduğu dizindeki dosyaları, silme veya taşıma yapmadan inceleyin:

ls -lah /vmfs/volumes/DATASTORE_ADI/VM_DIZINI

-00000X.vmdk, -delta.vmdk veya sesparse.vmdk benzeri dosyaların varlığı snapshot ilişkisini gösterebilir; fakat dosya adına bakarak silme kararı verilemez. Dosya listesi, vSphere envanteri ve log bulguları birlikte değerlendirilmelidir.

3. ESXi günlüklerinde hata zamanını arayın

SSH ile ilgili hostta aşağıdaki günlükleri inceleyin. Zaman damgasına göre daraltmak için hata saatini kullanın:

grep -iE "snapshot|consolidat|lock|error|fail" /var/log/hostd.log | tail -n 100
grep -iE "snapshot|consolidat|lock|error|fail" /var/log/vpxa.log | tail -n 100
grep -iE "APD|PDL|I/O error|NMP|lock" /var/log/vmkernel.log | tail -n 100

hostd.log yerel yönetim işlemlerini, vpxa.log vCenter ile host iletişimini, vmkernel.log ise depolama ve I/O katmanını anlamaya yardımcı olur. APD, PDL veya tekrarlayan I/O hatası görülürse snapshot silmeyi tekrar denemeden önce storage bağlantısını ve datastore sağlığını giderin.

4. Dosya kilidini doğrulayın

Hata açıkça kilit belirtiyorsa, şüpheli VMDK ya da delta dosyası için kilit bilgisi sorgulanabilir:

vmkfstools -D /vmfs/volumes/DATASTORE_ADI/VM_DIZINI/DISK_ADI.vmdk

Bu komut, VMFS üzerindeki kilit sahibine ilişkin tanılama verisi verir. Çıktıyı, VM’nin çalıştığı host ve yedekleme altyapısındaki etkin işler ile karşılaştırın. Kilidi “açmak” amacıyla dosya silmek, VM klasörünü taşımak veya hostu plansız yeniden başlatmak doğru yaklaşım değildir.

Güvenli adım adım çözüm

1. Değişiklik öncesi koruma ve bakım planı oluşturun

Snapshot kaldırma disk zincirini değiştiren bir işlemdir. Mümkünse uygulama sahibiyle bakım penceresi planlayın; özellikle yüksek yazma üreten VM’lerde yazma yükünü azaltın. Sanal makinenin yakın tarihli ve geri yüklenebilir yedeğinin bulunduğunu doğrulayın. Var olan snapshotı “yedek” kabul etmeyin.

İşletim sistemi ve uygulama tutarlılığı önemliyse, uygun bir bakım penceresinde VM’yi kapatmak bazı senaryolarda riski ve I/O yükünü azaltabilir. Bununla birlikte kapatma, kilit veya datastore erişim arızasını tek başına çözmez.

2. Alan sorununu çözün ve işlemi yeniden değerlendirin

Datastore alanı kritik düzeydeyse önce güvenli ve onaylı yöntemle kapasite sağlayın: gereksiz ISO’ları veya kurumsal politikaya göre doğrulanmış artık dosyaları temizleyin, uygun bir VM’yi başka datastore’a taşıyın ya da depolama ekibinin prosedürüne göre alan genişletin. Aktif VM’ye ait VMDK, delta, .vmsn veya .vmsd dosyalarını yer açmak için silmeyin.

Yeterli alan sağlandıktan sonra vSphere Client üzerinden yalnızca ilgili snapshot için Delete seçeneğini tekrar deneyin. Delete All, seçili VM’nin tüm snapshotlarını kaldırır; snapshot ağacı doğrulanmadan kullanmayın.

3. Çakışan yedekleme veya replikasyon işini temiz biçimde sonlandırın

Yedekleme yazılımı VMware snapshotlarını kullanıyorsa işin gerçekten tamamlanıp tamamlanmadığını kendi konsolundan kontrol edin. Takılı kalan bir işi önce ürünün belgelenmiş durdurma/temizleme yöntemiyle sonlandırın. İşlem tamamlandıktan sonra vSphere görevlerini ve snapshot ağacını yeniden kontrol edin. Yalnızca görev çakışması doğrulandıysa silme işlemini tekrar başlatın.

4. Kilit veya storage hatasını kaynakta giderin

Kilit sahibi başka bir ESXi host, yedekleme proxy’si veya açık bir yönetim işlemi olabilir. Önce ilgili işin, hostun ve VM’nin çalışma durumunu belirleyin. Storage erişim hatalarında HBA, ağ depolama yolu, multipath durumu ve datastore erişilebilirliği; depolama ekibiyle birlikte incelenmelidir. Sorun çözülmeden yapılan tekrar denemeleri yeni delta büyümesine veya daha uzun kesintiye neden olabilir.

5. Yalnızca doğrulanmış yönetim katmanı sorununda ajan müdahalesi yapın

Loglar depolama hatası göstermiyor, ancak görevler sürekli zaman aşımına uğruyor veya vCenter ile host durumu tutarsız görünüyorsa ESXi yönetim ajanları değerlendirilebilir. Bu işlem aktif yönetim oturumlarını ve izleme/otomasyon bağlantılarını etkileyebilir. Üretim ortamında bakım penceresi, konsol erişimi ve geri dönüş planı olmadan uygulamayın.

vSphere Client üzerinden host seçilerek Configure > Services bölümünden ilgili yönetim servislerinin durumu incelenebilir. Ajan yeniden başlatma kararı, ortam sürümü ve kurum prosedürüne göre verilmelidir. Sorunun dosya kilidi veya storage arızası olduğu kanıtlanmışsa ajan yeniden başlatmak çözüm değildir.

Çözümün doğrulanması

İşlem başarılı olduktan sonra yalnızca “Completed” görev kaydına güvenmeyin. Aşağıdaki kontrolleri birlikte yapın:

• vSphere Client’ta VM’nin snapshot ağacının beklenen durumda olduğunu doğrulayın.
• ESXi üzerinde vim-cmd vmsvc/snapshot.get VMID komutunu yeniden çalıştırın.
• VM’nin açılışını, disk erişimini ve kritik uygulama servislerini kontrol edin.
• Datastore boş alanının stabil olduğunu izleyin; silme sonrasında alanın geri kazanılması storage yapısına göre kısa süre alabilir.
• Yeni hostd.log ve vmkernel.log kayıtlarında tekrar eden I/O, kilit veya snapshot hatası bulunmadığını inceleyin.

Tekrarını önleme

• Snapshotlar için süre ve sahiplik politikası belirleyin; geçici snapshotların günlerce unutulmasını önleyin.
• Datastore kapasitesi için eşik uyarıları oluşturun; snapshot işlemlerini kritik boş alan seviyesinde başlatmayın.
• Yedekleme, replikasyon ve storage vMotion işlerini mümkün olduğunca aynı zaman aralığına yığmayın.
• Yedekleme işlerinin snapshot temizleme sonucunu düzenli olarak raporlayın.
• ESXi, vCenter ve yedekleme yazılımı sürümlerinin destek matrisini ve bilinen sorunlarını bakım süreçlerinde kontrol edin.

Sonuç: VMware snapshot silinemiyor hatasında doğru sıra önemlidir

VMware snapshot silinemiyor hatası için en güvenli yol, dosyaları elle silmek değil; hata metnini, görev çakışmasını, datastore kapasitesini, kilit durumunu ve ESXi loglarını sırayla doğrulamaktır. Alan ve çakışan iş sorunları düzeltildikten sonra kontrollü yeniden deneme çoğu durumda yeterlidir. Kilit, disk zinciri veya storage erişim bulgularında ise müdahale kaynağa odaklanmalı; gerekirse bakım penceresinde VMware ve depolama uzmanlarıyla ilerlenmelidir.

Sık sorulan sorular

Snapshot silme işlemi neden uzun sürer?

VMware, delta diskte biriken değişiklikleri disk zincirine işler. Snapshot boyutu, VM’nin anlık yazma yükü ve datastore gecikmesi süreyi doğrudan etkiler. Görev ilerliyorsa zorla durdurmayın.

Snapshot dosyalarını datastore tarayıcısından silebilir miyim?

Hayır. VMDK, delta VMDK, .vmsn ve .vmsd dosyalarını elle silmek disk zincirini bozabilir ve VM’nin açılmamasına veya veri kaybına neden olabilir.

Delete ile Delete All arasındaki fark nedir?

Delete seçili snapshotı kaldırır ve değişikliklerini üst diske işler. Delete All, ilgili sanal makinedeki tüm snapshotları kaldırır. İkisi de disk I/O üreten işlemlerdir; snapshot ağacı doğrulanmadan Delete All kullanılmamalıdır.

VM kapatılırsa snapshot silme hatası kesin çözülür mü?

Hayır. Kapatma, yoğun yazma yükünü azaltabilir; ancak datastore alanı, dosya kilidi veya storage erişim sorunu devam ediyorsa hata sürecektir.

“File is locked” hatasında ESXi hostunu yeniden başlatmalı mıyım?

Önce kilit sahibini ve aktif görevleri belirleyin. Plansız host yeniden başlatma, aynı hosttaki diğer iş yüklerini etkileyebilir. Yalnızca onaylı bakım prosedürü ve geri dönüş planı kapsamında değerlendirilmelidir.