Sanallaştırma altyapılarında yedekleme mekanizmasının güvenilir şekilde çalışması sistem sürekliliği açısından en kritik başlıklardan biridir. Özellikle HPE SimpliVity gibi hyperconverged yapılarda backup işlemleri klasik yedekleme ürünlerinden farklı olarak altyapının kendi veri verimliliği, metadata yönetimi ve VM farkındalığı ile entegre şekilde çalışır.
Bu nedenle oluşan bir backup hatası sadece yüzeyde görülen snapshot probleminden ibaret olmayabilir çoğu zaman arka planda inventory, datastore eşleşmesi, lokasyon kaydı ya da metadata bütünlüğü ile ilgili daha derin bir tutarsızlık bulunur.
Bu makalemde HPE SimpliVity ortamlarında zaman zaman karşılaşılan “VM Backup Snapshot Failure” ve buna eşlik eden “Snapshot Failed to Execute” hatasını teknik yönleriyle ele alacağız.
Sorunun nasıl ortaya çıktığını, hangi semptomlarla kendini gösterdiğini, nasıl doğrulanacağını ve neden özellikle taşınmış sanal makinelerde daha sık görüldüğünü inceleyeceğiz. Ayrıca yalnızca geçici yorumlar değil sahada uygulanabilir ve kalıcı sonuç veren çözüm adımlarını da detaylı biçimde açıklayacağız.
Sorunun Genel Çerçevesi
Bu problem genellikle tüm sanal makineleri etkileyen yaygın bir altyapı arızası şeklinde değil belirli bir veya birkaç VM üzerinde izole şekilde görülür.
Ortamda birçok yedekleme başarılı çalışırken yalnızca belli VM’ler üzerinde manuel backup ya da policy tabanlı backup görevleri hata verir. Bu durum ilk etapta yöneticiyi yanıltabilir. Çünkü sistem genel olarak sağlıklı görünür, datastore erişimleri vardır, vCenter erişimi vardır, OVC çalışmaktadır diğer VM’ler için backup alınabilmektedir. Ancak belirli VM üzerinde işlem başladığında görev ya uzun süre bekler ya da snapshot aşamasında hata vererek sonlanır.
Bu tür olaylarda SimpliVity tarafında görülen en yaygın hata mesajı şudur:
Snapshot failed to executeSimplivty VM Backup Snapshot FailureBazı durumlarda bu ifadeye ek hata kodları veya görev çıktıları da eşlik edebilir. Ancak hata mesajı her ne kadar snapshot oluşturulamadığını söylüyor olsa da asıl sebep doğrudan VMware snapshot mekanizmasının bozulması olmayabilir.
Birçok vakada root cause taşınmış VM’lere ait kayıtların SimpliVity veritabanında veya ilişkili metadata yapılarında doğru güncellenmemesidir.
SimpliVity yedekleme mimarisi yalnızca “anlık snapshot al ve sakla” mantığıyla çalışmaz. Arka planda VM’nin hangi datacenter’da bulunduğu, hangi datastore üzerinde yer aldığı, hangi node ile ilişkili olduğu ve backup hedefinin hangi lokasyon olarak işlendiği gibi çeşitli referanslar kullanılır.
Bu nedenle VM’nin fiziksel veya mantıksal konumu değiştiğinde yani örneğin:
- farklı bir datastore’a taşındığında,
- farklı bir datacenter altına geçirildiğinde,
- storage migration yapıldığında,
- VM yeniden register edildiğinde,
- eski lokasyonda aynı VM adına ait klasör veya disk kalıntıları bırakıldığında,
SimpliVity tarafında bu değişikliklerin tamamının tutarlı şekilde yansıması gerekir.
Sorun tam da burada oluşur. Bazen vCenter tarafında VM yeni konumunda gayet düzgün görünür sanal makine açılır, çalışır, diskleri erişilebilirdir, hatta normal operasyonlarda hiçbir anormallik hissedilmez. Fakat backup tetiklendiğinde SimpliVity geçmişte kayıt altında tuttuğu eski datastore veya eski datacenter bilgisini hâlâ kullanıyor olabilir. Bu durumda backup görevi mevcut çalışan VM ile geçmişten kalan metadata arasında çelişkiye düşer. Sonuç olarak snapshot operasyonu doğru nesne üzerinde veya doğru lokasyonda başlatılamaz ve görev başarısız olur.
Kısacası burada yaşanan temel problem VM’nin gerçek çalışma lokasyonu ile SimpliVity’nin backup ilişkileri arasında bir konumsal tutarsızlık oluşmasıdır.
Sorunun En Sık Görüldüğü Senaryolar
Bu hata rastlantısal değildir. Çoğu zaman belirli operasyonlardan sonra ortaya çıkar. Sahada en çok şu işlemler sonrasında gözlenir:
1. Storage vMotion veya datastore taşıma işlemleri
VM bir datastore’dan diğerine taşınmıştır ancak eski datastore üzerinde klasör yapısı ya da bazı artık dosyalar kalmıştır. SimpliVity backup motoru, hâlâ eski path’e dair referans taşıyabilir.
2. Datacenter veya cluster değişikliği
vCenter içerisindeki mantıksal organizasyon değiştirilmiş, VM farklı datacenter ya da cluster altına alınmıştır.
Fakat backup geçmişi eski lokasyonu referans göstermeye devam etmektedir.
3. Remove/Add işlemleri
VM zaman içinde inventory’den kaldırılıp yeniden eklenmiş olabilir. Eğer bu işlem kontrollü yapılmadıysa SimpliVity ile vCenter arasındaki nesne eşleşmesinde tutarsızlık oluşabilir.
4. Eski datastore’da lingering files kalması
Özellikle eski konumda aynı VM adına ait bir klasör kalmışsa, sistem zaman zaman bu klasörü gerçek nesne ile ilişkilendirmeye çalışabilir. Bu da backup sırasında yanlış datastore eşleşmesine neden olur.
5. Geçmiş backup metadata’sının eski lokasyonu göstermesi
Backup geçmişi, yeni durumu değil, VM’nin eski bulunduğu datacenter ve datastore’u kaydetmiş olabilir. Bu durum manuel testler sırasında açık şekilde ortaya çıkar.
Belirtiler ve Operasyonel Gözlemler
Bu hata oluştuğunda yönetici tarafında genellikle şu belirtiler görülür:
- Belirli bir VM için manuel backup başarısız olur.
- Aynı VM üzerinde tanımlı policy backup görevleri de art arda fail eder.
- OVC recent tasks kısmında job uzun süre In Progress görünür.
- Ardından görev hata vererek sonlanır.
- Hata mesajı olarak “Snapshot failed to execute” görüntülenir.
- View Backups ekranında ilgili backup kaydının datacenter ve datastore bilgisi, VM’nin fiilen bulunduğu yerle uyuşmaz.
- Bazen diğer VM’lerin backup’ları sorunsuz devam ettiği için problem yalnızca tekil bir VM arızası gibi algılanır.
Bu noktada önemli olan şudur eğer hata yalnızca tek VM’de veya birkaç taşınmış VM’de görülüyorsa genel storage, genel permission ya da genel SimpliVity servis arızası ihtimali azalır.
İnceleme doğrudan ilgili VM’nin lokasyon kaydı, geçmiş backup ilişkisi ve datastore izleri üzerine yoğunlaştırılmalıdır.
Problemin Teknik Olarak Doğrulanması
Bu tür vakalarda doğru doğrulama süreci çok önemlidir. Çünkü yalnızca hata mesajına bakarak karar verilirse gereksiz yere snapshot altyapısı, vSphere yetkileri veya OVC servisleri üzerinde zaman kaybedilebilir. Asıl yapılması gereken, SimpliVity’nin bu VM’yi hangi lokasyonda sandığını tespit etmektir.
1. Önce mevcut durumu haritalayın
İlk olarak ilgili sanal makinenin şu anki gerçek konumunu net biçimde çıkarın:
- VM hangi datacenter altında?
- Hangi cluster veya host ile ilişkili?
- VM’nin home files hangi datastore’da?
- VMDK dosyaları hangi path altında?
- VMX dosyası tam olarak nerede?
Bu bilgiler vSphere Client üzerinden tek tek doğrulanmalıdır. Özellikle Edit Settings altında sanal disk path’leri kontrol edilmelidir. Çünkü bazen VM ana klasörü bir yerde, disklerin bir kısmı başka datastore’da olabilir. Bu gibi hibrit senaryolarda yanlış yorum yapılması kolaydır.
2. Manuel backup testi yapın
Ardından problemli VM üzerinde bir manuel backup başlatın. Hedef olarak:
- local
veya - VM’nin bulunduğu yerel datacenter
seçilmelidir.
Buradaki amaç backup’ın başarılı olması değil, backup görevi sonrasında oluşan kayıtların hangi lokasyonu işaret ettiğini görmek ve SimpliVity’nin o VM için hangi metadata’yı kullandığını anlamaktır.
3. View Backups ekranını inceleyin
Backup denemesi başarısız olduktan sonra ilgili VM’ye sağ tıklanıp View Backups ekranı açılmalıdır. Burada özellikle en son manuel backup kaydı incelenir.
Kontrol edilmesi gereken sütunlar:
- Datacenter
- Datastore
- Backup destination
- Zaman bilgisi
- Son durum
Eğer burada backup kaydı, VM’nin şu anki lokasyonu yerine eski bir datacenter veya eski bir datastore gösteriyorsa sorun net şekilde doğrulanmış olur.
4. Tipik örnek
Örneğin sanal makine gerçekte localDC içinde yer alıyor olsun. Diskleri de Datastore-A üzerinde bulunuyor olsun. Ancak failed backup kaydı içinde:
- Datacenter = remoteDC
- Datastore = Datastore-Old
görülüyorsa bu, backup altyapısının eski lokasyon bilgisini kullanmaya devam ettiğini gösterir. Yani backup işlemi mantıksal olarak yanlış ortam üzerinde kurgulanmaktadır.
Bu da snapshot oluşturma zincirinin doğru bağlanamamasına neden olur.
Neden “Snapshot Failed to Execute” Hatası Alınır?
Burada şu önemli teknik noktayı vurgulamak gerekir Hata mesajı snapshot seviyesinde görünse de sorun doğrudan snapshot motorunun bozulması değildir. Snapshot oluşturma çağrısı, VM nesnesi ve ilgili storage ilişkileri ile birlikte çalışır. Eğer backup sistemi yanlış datastore veya eski datacenter kaydıyla ilerlemeye çalışıyorsa snapshot operasyonu doğru nesne bağlamında tamamlanamaz.
Başka bir ifadeyle;
- VM çalışıyor olabilir,
- datastore erişimi normal olabilir,
- vCenter sağlıklı olabilir,
- host tarafında problem olmayabilir,
ancak SimpliVity backup iş akışı yanlış metadata yüzünden doğru path’i ve doğru lokasyon ilişkisini çözemediği için snapshot çağrısı başarısız olur.
Bu nedenle bu hata çoğu zaman snapshot katmanında değil, snapshot öncesi referans çözümleme katmanında oluşan bozulmanın sonucudur.
Eski Datastore Üzerindeki Klasörlerin Önemi
Bu tür olaylarda en kritik teknik detaylardan biri VM’nin geçmişte bulunduğu datastore üzerinde kalan klasörlerdir. Özellikle aşağıdaki kalıntılar problem oluşturabilir:
- eski VM klasörü,
- eski .vmdk dosyaları,
- kullanılmayan .vmx,
- snapshot artıkları,
- yetim log veya config dosyaları.
Bu dosyalar aktif olarak kullanılmıyor bile olsa backup geçmişi ya da datastore taraması sırasında sistemin yanlış eşleşme yapmasına neden olabilir.
SimpliVity geçmişte backup aldığı VM ile datastore üzerindeki eski klasörü ilişkilendirmeye devam ediyor olabilir. Sonuçta gerçek VM artık başka yerde olsa da backup mantığı hâlâ eski yerde bir karşılık arar.
Bu yüzden çözümde yalnızca yeni lokasyonu değil eski lokasyonun temizlenmesini veya etkisiz hale getirilmesini de ele almak gerekir.
Geçici Çözüm Neden Yeterli Değildir?
Bu sorun için pratikte anlamlı bir workaround yoktur. Şu tür denemeler çoğu zaman kalıcı sonuç vermez:
- backup job’ını tekrar çalıştırmak,
- policy’yi silip yeniden oluşturmak,
- OVC task’larını beklemek,
- vCenter oturumunu yenilemek,
- VM üzerinde yeni snapshot denemek,
- backup hedefini tekrar seçmek.
Çünkü kök neden ortadan kaldırılmadığı sürece SimpliVity yine aynı yanlış metadata ile işlem yapacaktır. Dolayısıyla problem ancak inventory eşleşmesini yenileyerek ve eski datastore referansını etkisizleştirerek giderilebilir.
Kalıcı Çözümün Mantığı
Kalıcı çözüm aslında üç temel hedefe dayanır:
- Backup motorunun yanlış referans verdiği eski datastore izlerini ortadan kaldırmak
- vCenter inventory kaydını tazelemek
- VM’yi doğru ve güncel .vmx dosyası üzerinden yeniden tanıtmak
Bu üç işlem birlikte yapıldığında SimpliVity backup akışı ilgili VM’yi tekrar doğru nesne ve doğru lokasyon ile ilişkilendirir.
Adım Adım Kalıcı Çözüm
Aşağıdaki işlem sırası dikkatli ve kontrollü biçimde uygulanmalıdır. Üretim ortamlarında değişiklik öncesi servis etkisi değerlendirilmeli mümkünse bakım penceresi kullanılmalıdır.
Adım 1: Hatalı görünen datacenter ve datastore’u tespit ediniz.
Önce failed backup kaydında görünen beklenmeyen lokasyonu netleştirin. Hangi datacenter adı görünüyor? Hangi datastore adı yazıyor? Bu bilgi çözümün başlangıç noktasıdır.
Örneğin gerçek lokasyon localDC iken failed backup remoteDC ve DS-OLD gösteriyorsa, inceleme remoteDC / DS-OLD tarafında yapılmalıdır.
Adım 2: Eski datastore içeriğini datastore browser üzerinden açınız.
Hatalı görünen datastore üzerinde datastore browser ile gezinerek ilgili VM adına ait klasör arayın. Çoğu durumda burada problemli VM’ye ait eski klasör bulunur.
Bu klasör aşağıdakileri içerebilir:
- eski vmdk,
- config dosyaları,
- log dosyaları,
- önceki taşıma işleminden kalan kalıntılar.
Bu klasörün varlığı, sistemin neden eski lokasyonu referans göstermeye devam ettiğine dair güçlü bir işarettir.
Adım 3: Gerçek aktif lokasyonu tekrar teyit ediniz.
Burada en kritik güvenlik kontrolü yapılmalıdır. Eski datastore üzerindeki klasörün artık aktif kullanılmadığından yüzde yüz emin olun.
Bunun için:
- VM settings içinden disk path’lerini kontrol edin
- VM home folder konumunu kontrol edin
- aktif .vmx dosyasının bulunduğu path’i doğrulayın
- çalışan sanal disklerin hangi datastore’da olduğunu teyit edin
Bu kontrol yapılmadan klasöre müdahale edilmemelidir. Çünkü yanlış klasör üzerinde işlem yapılması servis kaybına neden olabilir.
Adım 4: Eski datastore’daki klasörü silmek yerine yeniden adlandırınız.
Klasörün artık aktif kullanılmadığı doğrulandıktan sonra, datastore browser üzerinden bu eski klasörü rename edin.
Doğrudan silmek yerine yeniden adlandırmanın avantajı şudur:
- yanlış referansı kırar,
- geri dönüş için emniyet sağlar,
- yanlış eşleşmenin devam etmesini önler,
- gerektiğinde sonradan tekrar gözden geçirme imkânı verir.
Örneğin klasör adının sonuna _old, _stale, _renamed gibi bir ifade eklenebilir.
Adım 5: Doğru .vmx yolunu not alınız.
Bir sonraki aşamada VM envanterden kaldırılacağı için, doğru .vmx dosyasının tam yolunu mutlaka kaydedin. Bu adım atlanırsa re-register sırasında yanlış dosya seçilebilir.
Not alınması gerekenler:
- doğru datastore adı,
- VM klasör adı,
- .vmx dosya adı,
- gerekiyorsa VMDK dizin yapısı.
Adım 6: VM’yi kontrollü şekilde kapatınız.
Inventory işlemleri öncesinde sanal makine düzgün biçimde shutdown edilmelidir. Mümkün olduğunca guest OS içinden temiz kapanış tercih edilmelidir.
Bu adım metadata ve dosya tutarlılığı açısından önemlidir.
Adım 7: Remove from Inventory uygulayınız.
VM kapandıktan sonra vCenter üzerinden sağ tıklayıp Remove from Inventory seçin.
Burada çok önemli bir nokta vardır:
Bu işlem dosyaları silmez. Sadece vCenter’ın o VM’ye ait envanter kaydını kaldırır. Yani Delete from Disk ile karıştırılmamalıdır.
Amaç, bozulmuş ya da eski referans taşıyan inventory bağını sıfırlamaktır.
Adım 8: Doğru datastore’dan yeniden Add to Inventory yapınız.
Ardından doğru datastore’a gidin, aktif VM klasörü içindeki doğru .vmx dosyasını bulun ve Add to Inventory ile sanal makineyi yeniden kayıt altına alın.
Bu işlem vCenter’ın VM’yi güncel lokasyonu üzerinden tekrar tanımasını sağlar. Aynı zamanda geçmişte kalan yanlış nesne eşleşmelerinin önemli bölümünü ortadan kaldırır.
Adım 9: VM’yi açın ve sağlık kontrolü yapınız.
VM tekrar envantere eklendikten sonra açılmalı ve temel kontroller yapılmalıdır:
- guest OS açılıyor mu,
- diskler düzgün mount ediliyor mu,
- uygulama servisleri sağlıklı mı,
- ağ erişimi normal mi.
Bu kontrol, inventory işleminin doğru nesne üzerinde yapıldığını garanti eder.
Adım 10: Yeni manuel backup testi başlatınız.
Son olarak aynı VM için yeniden manuel backup başlatın. Yine hedef olarak local veya bulunduğu yerel datacenter seçilmelidir.
Bu aşamada işlem doğru şekilde ilerliyorsa:
- backup görevi takılmadan çalışır,
- snapshot başarıyla oluşturulur,
- View Backups ekranında doğru datacenter ve datastore görünür.
Bu sonuç sorunun metadata ve inventory kaynaklı olduğunu doğrulamış olur.
Bu prosedürün başarılı olmasının sebebi, problemi iki ayrı düzlemde aynı anda çözmesidir.
İlk olarak eski datastore üzerindeki yanıltıcı klasör etkisiz hale getirilir. Böylece backup sürecinin yanlış lokasyonla ilişki kurma ihtimali azalır.
İkinci olarak VM’nin envanter kaydı sıfırdan oluşturulur. Bu da vCenter ile SimpliVity arasındaki nesne eşlemesini temizler ve güncel lokasyonun yeniden temel referans haline gelmesini sağlar.
Yani çözüm yalnızca dosya temizliği değildir; aynı zamanda kimlik ve lokasyon yenileme işlemidir.
Sorun Devam Ederse Ne Yapılmalı?
Yukarıdaki düzeltme işlemlerine rağmen sorun sürüyorsa, artık daha derin bir SimpliVity metadata veya ürün taraflı kayıt uyuşmazlığı söz konusu olabilir. Bu durumda destek sürecine geçmeden önce şu teknik veriler toplanmalıdır:
- problemli VM adı,
- mevcut datacenter adı,
- mevcut datastore adı,
- failed backup zaman bilgisi,
- OVC recent tasks ekran çıktısı,
- View Backups ekran görüntüsü,
- aktif .vmx path’i,
- disk path bilgileri,
- VM’nin geçmiş relocation bilgisi,
- eski datastore’da kalan klasörlerin ekran görüntüsü,
- son başarılı backup’ın hangi lokasyonda göründüğü.
Bu veriler HPE desteğinin problemi daha hızlı anlamasına yardımcı olur.
