Sanal Makine Disk Kurtarma: VMware VMDK, Hyper-V VHDX ve Snapshot Zinciri

Hızlı cevap: Sanal makineniz açılmıyorsa ve disk dosyası (VMware'de VMDK, Hyper-V'de VHDX) bozulduysa, içindeki verinin gittiğini düşünmeyin. Sanal disk kurtarma katmanlı bir iştir: önce dış imaj dosyasının yapısı ya da datastore onarılır, sonra VM içindeki dosya sistemi yeniden çatılır. En sık nedenler kırık snapshot zinciri, eksik descriptor ve hasarlı VMFS datastore'dur. İlk müdahalede VM'i tekrar başlatmaya çalışmayın. Acil hat: +90 536 662 38 09.

Sanal disk neden iki katmanlı bir kurtarmadır?

Fiziksel bir diskte tek bir dosya sistemi vardır. Sanal makinelerde ise iki ayrı dünya iç içe geçer. Dışta, ana sistemin (host) gördüğü bir disk imaj dosyası vardır: VMware'de .vmdk, Hyper-V'de .vhdx. İçeride ise bu dosyanın içinde, sanal makinenin kendi işletim sisteminin dosya sistemi (NTFS, ext4, ReFS gibi) bulunur.

Bu yüzden sanal disk kurtarma her zaman iki katmanlıdır. Önce dış imaj dosyasının ya da onun bulunduğu datastore'un sağlığı çözülmeli, dosyaya tutarlı biçimde erişilmelidir. Ancak ondan sonra içerideki dosya sistemine girip kullanıcının asıl verisine ulaşılabilir. Bir katman bozuksa, diğeri sağlam olsa bile veriye ulaşılamaz.

En sık karşılaşılan bozulma türleri

Kırık snapshot zinciri

Sanal makinelerde anlık görüntü (snapshot) almak, o anki diski dondurup değişiklikleri ayrı bir dosyaya (delta ya da differencing disk) yazmaktır. VMware'de bunlar delta vmdk, Hyper-V'de avhdx dosyalarıdır. Bu dosyalar bir zincir oluşturur: temel disk, üzerine snapshot 1, onun üzerine snapshot 2. Zincirdeki tek bir halka silinir, taşınır ya da bozulursa bütün zincir okunamaz hale gelir. En sık veri kaybı nedenlerinden biri budur, çünkü kullanıcılar bazen snapshot dosyalarının "geçici" olduğunu sanıp silerler.

Eksik veya bozuk descriptor

VMware VMDK genellikle iki parçadan oluşur: küçük bir metin descriptor dosyası ve asıl veriyi tutan flat dosya. Descriptor, diskin boyutu, türü ve zinciri gibi bilgileri taşır. Bu küçük dosya bozulur ya da kaybolursa, sistem terabaytlarca asıl veriyi nasıl yorumlayacağını bilemez. Çoğu zaman descriptor yeniden oluşturulabilir ve disk tekrar okunur hale gelir.

Hasarlı VMFS datastore

VMware ESXi, sanal disk dosyalarını VMFS adında özel bir dosya sisteminde tutar. Datastore'un üzerinde durduğu LUN ya da RAID dizisi bozulursa, VMFS meta verisi hasar görür ve içindeki tüm VM'ler erişilemez olur. Bu durumda kurtarma datastore düzeyinde başlar: VMFS yapısı yeniden çatılır, sonra VMDK dosyaları çıkarılır.

Thin provision boşlukları

Thin provisioning, sanal diske ihtiyaç oldukça yer ayırır, böylece dosya gerçek kullanımdan küçük görünür. Disk bozulduğunda hangi blokların gerçekten yazıldığını, hangilerinin boş olduğunu çözmek gerekir. Thin ve thick provision arasındaki fark, kurtarmada blok haritasının nasıl yorumlanacağını belirler.

Bozulma türleri ve kurtarma yaklaşımı

Bozulma Platform Kök katman Yaklaşım
Kırık snapshot zinciri VMware / Hyper-V Delta / avhdx Zincir yeniden kurulur, en uygun nokta seçilir
Eksik descriptor VMware VMDK üst veri Descriptor yeniden oluşturulur
Hasarlı datastore VMware ESXi VMFS Datastore çatılır, sonra VMDK çıkarılır
Thin provision boşluğu VMware / Hyper-V Blok haritası Yazılı bloklar ayrıştırılır
RAID/disk arızası Tüm platformlar Fiziksel dizi Önce dizi imajı, sonra üst katmanlar

İlk müdahale: neyi yapmayın?

Sanal disk vakalarında en sık yapılan hata, VM'i tekrar tekrar başlatmaya çalışmaktır. Bozuk bir snapshot zinciriyle VM açmaya zorlamak, host'un delta dosyalarına yazmasına ve durumu daha karmaşık hale getirmesine yol açar. Bir snapshot dosyasını silmek, taşımak ya da yeniden adlandırmak da zinciri kalıcı bozabilir.

Yapın: VM'i kapalı tutun, tüm vmdk, vhdx, delta ve avhdx dosyalarını olduğu gibi koruyun, datastore'a yeni VM oluşturmayın. Fiziksel bir RAID üzerinde çöküş varsa diziye dokunmayın, ilk müdahale için RAID 5 çöktü kurtarma süreci yazısına bakın.

Yapmayın: Snapshot dosyalarını silmeyin, "consolidate" ya da "merge" işlemlerini bilinçsizce çalıştırmayın, datastore'u yeniden formatlamayın.

Sunucu rolleriyle ilişki

Sanal makineler çoğunlukla kritik sunucu rolleri taşır. İçeride bir Exchange ya da Active Directory varsa, dış imaj onarıldıktan sonra veritabanı düzeyinde ayrı bir kurtarma gerekebilir. Bu durumu Exchange ve Active Directory sunucu kurtarma yazımızda ayrıntılı ele aldık. Çünkü sanal disk açıldıktan sonra içindeki EDB ya da NTDS.dit hâlâ dirty shutdown durumunda olabilir.

DSET sanal makine kurtarma yaklaşımı

2003'ten beri Ankara Hacettepe Teknokent Beytepe laboratuvarımızda sanal disk kurtarıyoruz. Önce datastore ya da imaj dosyalarının birebir kopyasını alır, tüm çalışmayı kopya üzerinde yaparız. Snapshot zincirini yeniden kurar, descriptor'ı onarır ve VM içindeki dosya sistemine ulaşırız. Başarı oranımız yüzde 99,4. İlk teşhis ücretsizdir, veri çıkmazsa ücret almıyoruz.

Sık Sorulan Sorular (SSS)

Snapshot dosyalarını yanlışlıkla sildim, VM açılmıyor. Kurtulur mu?

Çoğu zaman evet. Snapshot dosyaları silinmiş olsa bile temel disk genelde sağlamdır ve delta dosyalarının kalıntıları çoğu durumda kurtarılabilir. En kötü ihtimalle snapshot öncesi duruma dönülür. Hemen VM'i kapatın ve dosyalara dokunmayın.

VMDK descriptor dosyam kayboldu, flat dosya duruyor. Yeterli mi?

Genellikle yeterlidir. Asıl veri flat dosyada durur, descriptor sadece nasıl yorumlanacağını söyleyen küçük bir tanım dosyasıdır. Diskin boyutu ve türü doğru belirlenerek descriptor yeniden oluşturulabilir.

Datastore (VMFS) bozuldu, tüm VM'ler kayboldu. Hepsi gider mi?

Hayır. Datastore'un altındaki LUN ya da dizi imaja alınıp VMFS yapısı yeniden çatıldığında, içindeki VMDK dosyaları çoğunlukla çıkarılabilir. Önemli olan diziye yeni yazma yapmamaktır.

Thin provision diskte kurtarma daha mı zor?

Biraz daha karmaşıktır çünkü hangi blokların gerçekten yazıldığını çözmek gerekir. Ancak doğru blok haritası çıkarıldığında thin diskler de başarıyla kurtarılır.

Sanal diski açtınız ama içindeki Windows açılmıyor, ne oluyor?

Dış imaj sağlam olsa bile VM içindeki dosya sistemi ya da veritabanı bozuk olabilir. Bu ikinci katmandır ve ayrı bir kurtarma gerektirir. Örneğin içeride Exchange varsa veritabanı dirty shutdown durumunda olabilir.

Kaynaklar