Veri Kurtarma
VMware ESXi Sunucularında Veri Kurtarma

VMware ESXi Veri Kurtarma Nedir?
VMware ESXi Veri Kurtarma; bare-metal hypervisor üzerinde çalışan VMFS (Virtual Machine File System) dosya sisteminde, bağlı ağ depolama birimlerinde (NFS, iSCSI LUN, Fibre Channel SAN) veya donanımsal depolama katmanlarında meydana gelen mantıksal ve fiziksel arızalar sonrasında erişilemez hale gelen Sanal Makine (VM) yapılarını, -flat.vmdk disk imajlarını, snapshot zincirlerini ve metadata verilerini yeniden kullanılabilir ve çalışır duruma getirme işlemidir. Bu süreç, komut satırı seviyesinde mantıksal müdahalelerden sektör düzeyinde adli bilişim (forensic) okumalarına kadar uzanan ileri düzey teknik adımları kapsar.
ESXi Veri Kaybı Anında İlk Yapılması Gereken 3 Kritik Hamle
- İlgili Datastore Üzerindeki Tüm Giriş/Çıkış (I/O) İşlemlerini Durdurun: Silinen veya bozulan verilerin bulunduğu VMFS birimine yeni veri yazılmasını engellemek amacıyla, o datastore üzerinde çalışan tüm sanal makineleri kapatın veya sunucuyu derhal bakım moduna (
Maintenance Mode) alın. - Körlemesine Snapshot Birleştirme (Consolidation) İşlemi Yapmayın: vSphere Client arayüzünde "Consolidation Required" uyarısı gördüğünüzde üst üste birleştirme butonuna basmayın. İşlem başarısız oluyorsa diski kilitleyen süreci (Locking Process) bulmadan zorlama yapmanız zincirin kalıcı olarak bozulmasına yol açabilir.
- SSH Erişimi Üzerinden Güvenlik Loglarını ve Sektör Haritasını Yedekleyin: Unmount veya Rescan işlemlerine girişmeden önce ESXi hostuna SSH ile bağlanarak
/var/log/vmkernel.logdosyasını, partition table çıktılarını ve LUN metadata haritasını harici bir sunucuya kaydedin.
IT Yöneticileri İçin Acil Müdahale Kontrol Listesi ve Karar Protokolü
Kriz anlarında yapılan en büyük hata, panik halinde rastgele komutlar çalıştırmak veya vSphere arayüzünden sürekli yeniden tarama (rescan) tetiklemektir. Veri kaybı gerçekleştiğinde aşağıdaki adım adım protokolü sırasıyla takip etmeniz hayati önem taşır.
1.Adım: Kriz Türünün Doğru Teşhisi
İlk olarak sorunun kaynağını belirlemelisiniz. Sorun sanal makine işletim sistemi seviyesinde mi, ESXi dosya sistemi (VMFS) seviyesinde mi, yoksa doğrudan depolama donanımında (RAID kartı, SAN Switch, Disk Arızası) mı meydana geldi?
- Sanal makine açılmıyor ancak datastore gözüküyorsa: Sorun dosya kilitleri (
Failed to lock the file), bozuk.vmdkheader dosyası veya snapshot uyuşmazlığıdır (Parent CID mismatch). - Datastore tamamen gözden kayboldu veya
Inaccessibledurumuna geçtiyse: Sorun LUN bağlantısı, GPT partition table bozulması veya RAID controller arızasıdır. - Sanal makine vCenter üzerinde
(Orphaned)olarak etiketlendi ise: Sorun.vmxkonfigürasyon dosyasının silinmesi veya vCenter veritabanı ile host arasındaki index uyuşmazlığıdır.
2.Adım: Veri Güvenliği ve İzolasyon
- Hatalı datastore üzerindeki sanal makineleri vMotion veya Storage vMotion ile başka yere taşımaya çalışmayın. Dosya taşıma işlemleri silinmiş veri sektörlerinin üzerine yazılmasına (Overwriting) neden olur.
- Donanımsal bir disk arızası şüphesi varsa (RAID dizisinde birden fazla diskin düşmesi veya Okuma/Yazma I/O hatalarının artması), sanal diskleri host üzerinden kopyalamaya çalışmak yerine depolama biriminin sektör sektör imajının alınmasını sağlayın.
3.Adım: Güvenli Müdahale Ortamının Hazırlanması
Müdahaleye başlamadan önce etkilenen datastore'a yazma yapan tüm işlemleri (yedekleme işleri, otomatik snapshot'lar, zamanlanmış görevler) durdurun ve yapılan her adımı kayıt altına alın. Komut satırından yapılacak her işlem, yalnızca alınmış imajın kopyası üzerinde ve deneyimli bir ekip tarafından yapılmalıdır.
ESXi Depolama Mimarisi ve Dosya Sistemi Analizi: VMFS5 ve VMFS6 Karşılaştırması
VMware ESXi ortamlarında veri kurtarma metodolojisini belirleyen en temel unsur, kullanılan VMFS (Virtual Machine File System) versiyonudur. VMFS5 ve VMFS6, silinen verilerin sektör düzeyinde saklanması ve otomatik alan geri kazanımı (UNMAP) konularında tamamen farklı mekanizmalara sahiptir.
VMFS5 Dosya Sisteminde Veri Kurtarma Dinamikleri
VMFS5, blok bazlı depolamada 1 MB sabit cluster boyutu (sub-block boyutu 8 KB) kullanır. VMFS5 ortamında bir sanal makine veya .vmdk dosyası silindiğinde, dosya sisteminin inode ve metadata tablosundaki göstericiler (pointers) serbest bırakılır. Ancak, veri sektörlerinin içeriği fiziksel disk üzerinde hemen sıfırlanmaz.
Bu durum, VMFS5 üzerinde silinen dosyaların kurtarılabilirlik oranını oldukça yükseltir. Eğer ilgili datastore üzerine yeni bir sanal makine kurulmazsa veya mevcut makineler disk boyutlarını genişletmezse, haftalar sonra bile -flat.vmdk dosyalarının ham verisi Hex Editor araçları ve imaj tarama yazılımları vasıtasıyla eksiksiz bir şekilde çıkarılabilir.
VMFS6 Dosya Sisteminde Veri Kurtarma Dinamikleri
VMFS6, vSphere 6.5 ile hayatımıza girmiş olup, 512e ve Native 4K disk desteği, geliştirilmiş blok tahsis algoritmaları ve en önemlisi Otomatik Alan Geri Kazanımı (Automatic Space Reclamation - UNMAP) özelliği ile birlikte gelir.
UNMAP mekanizması, sanal makine içinden veya vSphere seviyesinden bir dosya silindiğinde, arka planda ince istemci (Thin Provisioned) LUN alanlarını otomatik olarak serbest bırakmak için depolama dizisine (Storage Array) SCSI UNMAP komutları gönderir. Bu işlem, silinen sektörlerin depolama denetleyicisi seviyesinde "0" (zero) olarak işaretlenmesine yol açabilir.
Bu nedenle, VMFS6 kullanan bir datastore üzerinde yanlışlıkla dosya silindiğinde müdahale süresi çok daha kısıtlıdır. Otomatik UNMAP süreci tamamlanmadan önce datastore derhal unmount edilmeli ve arka plan temizleme süreçleri durdurulmalıdır.
Donanımsal RAID ve LUN Katmanındaki Mantıksal Dis bağlantıları
ESXi sunucular, fiziksel depolama alanlarını LVM (Logical Volume Manager) katmanı aracılığıyla işler. Depolama ağında (iSCSI, SAN) yaşanan anlık paket kayıpları veya RAID kartının önbellek (Write Cache) pilinin bitmesi sonucu oluşan veri kayıplarında, VMFS header alanındaki UUID bilgisi bozulabilir.
UUID bozulduğunda ESXi sunucusu ilgili LUN'u görse dahi üzerindeki VMFS dosya sistemini tanıyamaz ve birimi biçimlendirilmemiş (Unformatted/Raw) bir alan olarak algılar. Bu gibi durumlarda veriler fiziksel olarak diskte durmaktadır; yapılması gereken işlem VMFS Master Block alanının ve GPT Partition Table haritasının onarılmasıdır.
VMware ESXi Veri Kurtarma ve Onarım Yöntemleri
Storage Katmanının Tespiti ve GPT Partition Table Onarımı
ESXi yeniden başlatıldıktan sonra datastore'un görünmemesi çoğu zaman bölüm tablosunun (GPT) zarar görmesinden, LUN kimliğinin değişmesinden ya da RAID denetleyicisindeki bir sorundan kaynaklanır. Bu durumda veriler genellikle disk üzerinde durur; ancak bölüm tablosunu yeniden yazmaya ya da datastore'u yeniden oluşturmaya yönelik bir deneme yanlış başlangıç adresiyle yapılırsa VMFS meta verisinin üzerine yazabilir. Laboratuvarda önce disklerin ya da LUN'un birebir imajı alınır; bölüm yapısı ve VMFS imzaları bu imaj üzerinde tespit edilerek datastore erişilebilir hâle getirilir.
Dosya Kilitlerinin Kalıplarını Çözme ("Failed to Lock the File")
"Failed to lock the file" ve "Unable to access file since it is locked" hataları, sanal diskin başka bir host ya da yarım kalmış bir işlem (yedekleme, vMotion, snapshot) tarafından kilitli tutulduğunu gösterir. Çoğu zaman kilidi tutan işlem sonlandığında sorun kendiliğinden çözülür. Kilit VMFS meta verisindeki bir bozulmadan kaynaklanıyorsa kilit dosyalarını elle silmek ya da diski zorla açmak veri kaybına yol açabilir; hata beklenmedik bir kapanma veya depolama arızasının ardından ortaya çıktıysa diski değiştirmeden bize ulaşın.
Snapshot Zinciri Bozulmaları ve "Parent CID Mismatch" Onarımı
"The parent virtual disk has been modified since the child was created" hatası, snapshot zincirindeki disklerin birbirini tanımadığı anlamına gelir: her snapshot bağlı olduğu üst diskin kimliğini (CID) tutar ve bu kimlik uyuşmadığında sanal makine açılmaz. Neden genellikle yarım kalan bir snapshot birleştirme (consolidation), yedekleme yazılımının bıraktığı fazla snapshot ya da elle yapılan dosya taşımalarıdır. Zincirin hangi noktada koptuğu yanlış belirlenerek yapılan bir düzeltme en güncel verilerin bulunduğu snapshot'ın kaybolmasına neden olabilir; bu nedenle onarım zincirdeki tüm dosyaların kopyası üzerinde yapılmalıdır.
Kayıp veya Bozuk Descriptor (.vmdk) Dosyalarını Sıfırdan Oluşturma
Sanal makine klasöründeki birkaç KB boyutundaki .vmdk tanım (descriptor) dosyası silinir ya da bozulursa, yüzlerce GB'lık veri dosyası (-flat.vmdk) yerinde dursa bile ESXi diski tanıyamaz. Tanım dosyası diskin boyutu ve yapısıyla birebir uyumlu olacak şekilde yeniden oluşturulabilir; yanlış boyut ya da adaptör tipiyle oluşturulan bir tanım dosyası ise disk bağlandığında dosya sisteminin bozuk görünmesine yol açar. Veri dosyası sağlamsa bu genellikle kısa sürede çözülen bir arızadır.
Orphaned (Yetim) Sanal Makineler ve Metadata Bozulması Recovery İşlemleri
vCenter'da "orphaned" ya da "invalid" görünen sanal makineler, host'un yapılandırma dosyasına (.vmx) erişememesinden ya da envanter kaydının bozulmasından kaynaklanır. Makinenin dosyaları datastore'da duruyorsa çoğu zaman yeniden kaydedilerek erişilebilir; dosyalar eksikse ya da datastore erişilemiyorsa sorun depolama katmanındadır ve imaj üzerinden çalışılması gerekir.
İleri Düzey Veri Kurtarma Yöntemleri ve Adli Bilişim (Forensic) Analizleri
Mantıksal onarım adımlarının (vmkfstools, partedUtil) yetersiz kaldığı; VMFS dosya sistemi dizin yapısının ağır hasar gördüğü veya yanlışlıkla "Format Datastore" butonuna basıldığı durumlarda klasik işletim sistemi komutları yanıt vermez. Bu aşamada alt seviye adli bilişim (forensics) ve ham veri analiz yöntemleri uygulanmalıdır.
Bit-Stream Imager İle Blok Seviyesinde İmaj Alma
Hasarlı bir depolama biriminde canlı analiz yapmak risklidir; her işlem yıpranmış sektörleri daha da bozabilir. Bu nedenle ciddi arızalarda ilk adım, disklerin ya da LUN'un sektör sektör birebir imajını almaktır. Analiz ve onarım bu imaj üzerinde yapılır; orijinal diskler değişmeden kalır ve bir deneme başarısız olsa bile başa dönülebilir.
Hex Editor ve VMFS Descriptor Signature Taraması
VMFS dosya sisteminde her dosya türünün ve blok yapısının karakteristik bir Magic Number (imza) değeri bulunur. Örneğin, VMFS Master Block alanında 0x157F3001 imzası yer alırken, ELF binary dosyalarında veya NTFS/Linux dosya sistemlerinin boot sektörlerinde özel tanımlayıcı baytlar mevcuttur.
Gelişmiş Hex Editor yazılımları (X-Ways Forensics, EnCase, R-Studio Forensic) ham imaj üzerinde çalıştırılarak VMFS directory index tablosu bypass edilir. Yazılımlar, disk bloklarını baştan sona tarayarak VMDK header yapısını (KDMV imzası) arar. Bulunan bloklar birleştirilerek silinmiş sanal disklerin yapısı yeniden inşa edilir (Carving yöntemi).
Raw Disk Mapping (RDM) Yöntemi ile Veri Tahliyesi
Veri kurtarma yazılımlarını doğrudan ESXi hypervisor içerisine kurmak mümkün değildir. Kurtarma yazılımlarını çalıştırmak için ikincil bir Sanal Makine (Windows veya Linux tabanlı) oluşturulur. Hasarlı olan datastore veya ham disk alanı, bu sanal makineye Raw Disk Mapping (RDM) olarak "Physical Compatibility Mode" seçeneğiyle eklenir.
Bu sayede, konuk işletim sistemi (Guest OS) ESXi'ın dosya sistemi katmanını tamamen atlayarak doğrudan fiziksel diskin bloklarına erişir ve tarama işlemini gerçekleştirir.
Sıkça Sorulan Sorular
1. Silinen VMFS datastore'dan veri kurtarmak kesin olarak mümkün müdür?
Evet, büyük oranda mümkündür. VMFS dosya sisteminde bir dosya veya sanal makine silindiğinde, öncelikle ilgili dosyanın indis göstericileri (inodes) temizlenir. Verinin bulunduğu ham sektörlerin üzerine yeni bir veri yazılmadığı (overwritten) ve VMFS6 üzerinde otomatik UNMAP süreci disk alanını tamamen sıfırlamadığı sürece; Hex Editor, Carving araçları ve Bit-stream imaj analiz yöntemleriyle VMDK verileri yüksek başarı oranıyla kurtarılabilir.
2. VMware snapshot birleştirme (consolidation) hatası aldığımda ne yapmalıyım?
Birleştirmeyi tekrar tekrar denemeyin ve snapshot dosyalarını silmeyin. Datastore'da yeterli boş alan olup olmadığını ve yedekleme yazılımının snapshot'ı hâlâ kullanıp kullanmadığını kontrol edin; hata sürüyorsa zincirin kopyası alınmadan müdahale etmeyin ve bize ulaşın.
3. -flat.vmdk dosyası duruyor ama ana .vmdk kayıp, bu durum nasıl çözülür?
Veri dosyası sağlamsa tanım dosyası yeniden oluşturularak disk çoğu zaman kısa sürede erişilebilir hâle getirilir. Yanlış parametrelerle oluşturulan bir tanım dosyası diski bozuk gösterebileceği için bu işlem veri dosyasının kopyası üzerinde yapılmalıdır.
4. ESXi sunucuda RAID çökmesi sonrası datastore nasıl tekrar görünür hale getirilir?
RAID denetleyicisinde diziyi yeniden oluşturmayın, initialize etmeyin ve rebuild başlatmayın; bu işlemler VMFS'nin üzerine yazabilir. Disklerin sırasını etiketleyip sunucuyu kapatın. Dizinin parametreleri laboratuvarda disk imajları üzerinden belirlenir; datastore ve sanal makineler imaj üzerinden kurtarılır.
5. Veri kurtarma yazılımlarını doğrudan ESXi üzerine kurup çalıştırabilir miyim?
Hayır. VMware ESXi, kısıtlı bir Linux türevi (POSIX benzeri) bare-metal işletim sistemidir ve üzerinde standart üçüncü parti yazılımların (.exe, .deb, .rpm) çalışmasına izin veren bir grafik arayüz veya paket yöneticisi bulunmaz. Veri kurtarma yazılımları, ESXi üzerine kurulan yardımcı bir sanal makineye Raw Disk Mapping (RDM) yöntemiyle disk bağlanarak veya diskin başka bir ortama imajı aktarılarak çalıştırılmalıdır.
İlgili hizmet: Sanal makineniz bir Veeam yedeğinin içindeyse VBK dosyasından doğrudan VMDK çıkarıyoruz → Veeam yedek kurtarma.
Son güncelleme:
























