Yasal Uyarı: Not eğlence amaçlıdır. İçindeki yararlı bilgilerin spesifik yoğunluğu düşüktür. "Kendim için" yazıldı.
lirik giriş
Kuruluşumuzdaki dosya dökümü, Windows Server 6 çalıştıran VMware ESXi 2016 sanal makine üzerinde çalışmaktadır. Ve bu sadece bir çöp dökümü değildir. Bu, yapısal bölümler arasında bir dosya alışverişi sunucusudur: işbirliği, proje dokümantasyonu ve ağ tarayıcılarından gelen klasörler vardır. Genel olarak tüm üretim ömrü buradadır.
Ve tüm üretim ömrünün bu konteyneri asılmaya başladı. Üstelik misafir, diğerlerini etkilemeden sessizce kendini asabiliyordu. Tüm sunucuyu ve buna bağlı olarak diğer tüm konuk makineleri devre dışı bırakabilirdi. Kendimi asabilir ve vSphere istemci hizmetlerini kapatabilirim: yani diğer misafirlerin işlemleri canlı, makineler düzgün çalışıyor ve yanıt veriyor, ancak dosya yıkayıcı yok ve vSphere İstemcisi ana bilgisayara yapışmıyor. Genel olarak herhangi bir sistem tanımlanamadı. Gün içinde düşük yükte donmalar meydana gelebilir. Bunu geceleri, yük yokken de yapabiliyorlardı. Geceleri diferansiyel yedekleme ve ortalama yük sırasında olabilir. Tam yedeklemeler ve yüksek yük sırasında hafta sonları olabilir. Ve durumun açık bir şekilde bozulması vardı. İlk başta yılda bir, sonra altı ayda bir yapılıyordu. Sabrımın sonunda - haftada iki kez.
Hafıza sorunum vardı. Ancak hafta sonları bile çöp yığınını durdurmama ve Memtest'i çalıştırmama izin vermediler. Mayıs tatilini bekliyorduk. Mayıs tatillerinde Memtest'i çalıştırdım ve... hiçbir hata bulunamadı.
Şaşırdım ve tatile çıkmaya karar verdim. Ben tatildeyken çöplükte tek bir takılma bile yaşanmadı. Pazartesi günü ilk gün işe döndüğümde bir çöp yığını vardı. Tam bir yedeklemeye katlandım ve bittikten hemen sonra telefonu kapattım. Tatilden böylesine sıcak bir karşılama, beni diskleri konuk makineyle fiziksel olarak başka bir ana bilgisayara sürükleme kararına itti.
Tatilden sonraki ilk gün ciddi bir şey yapamayacağınız uzun zamandır bilinse de, işe gidene kadar çalışmamaya kendimi hazırlamış olsam da, bir kez daha donma karşısında hissettiğim öfke hem ruh halimi hem de ruh halimi bozdu. yeminler aklımdan çıkıyor...
Fiziksel diskler başka bir ana bilgisayara taşındı. Sıcak bağlantı. Sekmedeki depolama ayarlarında sürücüler diskler görünür. Sekmede veri depoları Bu disklerde depolama alanı yoktur. Yenile - görünmüyor. Tabii ki ilk dürtü - Depolama Ekle. Ekleme Sihirbazı neyi desteklediğini açıklar. Elbette VMFS'yi de destekliyor. Bundan şüphe etmedim. Her adımdaki sihirbazın mesajlarına hızlı bir bakış: Sonraki, Sonraki, Sonraki, Bitir. Ustanın merdivenlerinden birinin penceresinin altındaki ünlem işaretli küçük sarı daireye göz yaklaşmadı bile.
Sihirbazın sonunda, listede yeni Veri Deposu belirdi... ve onunla birlikte kalan fiziksel disklerdeki Veri Depoları da belirdi.
Yeni eklenen Datastore'da gezinmeye devam ediyorum ve burası... boş. Tabii yine hayrete düştüm. Saat sabahın 8'i, tatil sonrası işteki ilk 15 dakikam, henüz kahvemin şekerini karıştırmadım bile. Ve işte burada. İlk düşüncem "yerel" ana bilgisayardan yanlış diski çektiğimdi. Gerekli Veri Deposunun "yerel" ana bilgisayarda mevcut olup olmadığına baktım: hayır, mevcut değildi. İkinci düşünce şuydu: “siktir!” Emin değilim ama bana öyle geliyor ki üçüncü, dördüncü ve en azından beşinci düşünce aynıydı.
Şüpheleri ortadan kaldırmak için test için hızlı bir şekilde yeni bir ESXi kurdum, sol diski aldım ve zaten okuyarak sihirbazın adımlarını geçtim. Evet. Sihirbazı kullanarak bir Veri Deposu eklediğinizde, işlemi geri alma ve verileri geri yükleme yeteneği olmadan diskteki tüm veriler kaybolur. Daha sonra forumlardan birinde bu tasarımın bir usta tarafından değerlendirildiğini okudum: boktan bir saçmalık. Ve gerçekten kabul ettim.
Altıncıdan başlayarak düşünceler daha yapıcı bir yöne aktı. TAMAM. Başlatma, 3 TB'lık bir disk için bile birkaç saniye sürer. Yani bu yüksek düzeyli biçimlendirmedir. Bu, bölüm tablosunun basitçe yeniden yazıldığı anlamına gelir. Yani veriler hala orada. Şimdi biraz biçimsiz arayacağız ve işte.
Makineyi Strelec önyükleme görüntüsünden başlatıyorum... Ve bölüm kurtarma programlarının VMFS dışında her şeyi bildiğini öğrendim. Örneğin, Synology'nin bölüm düzenini biliyorlar ancak VMFS'yi bilmiyorlar.
Programlar arasında arama yapmak güven verici değildir: En iyi ihtimalle GetDataBack ve R.Saver, canlı dizin yapısına ve canlı dosya adlarına sahip NTFS bölümlerini bulur. Ama bu bana uymuyor. İki vmdk dosyasına ihtiyacım var: sistem diski ve çöp dosyası diski ile.
Ve sonra, artık Windows'u yükleyip bir dosya yedeğinden çıkaracağım gibi göründüğünü anlıyorum. Ve aynı zamanda orada bir DFS köküm olduğunu da hatırlıyorum. Ayrıca kapsam ve sonuçlar açısından kesinlikle çılgınca olan departman klasörlerine erişim hakları sistemi. Bir seçenek değil. Zaman içinde kabul edilebilir tek seçenek, sistemin ve diskin durumunu veriler ve tüm haklarla birlikte geri yüklemektir.
Yine Google, forumlar, KB'shki ve yine Yaroslavna'nın ağlaması: VMware ESXi bir veri kurtarma mekanizması sağlamıyor. Tüm tartışma konularının iki sonu vardır: birisi pahalı DiskInternals VMFS Recovery kullanılarak kurtarılmıştır veya birisi, hizmetlerini aktif olarak tanıtan bir yazılım uzmanından yardım almıştır. vmfs-araçları и dd. DiskInternals VMFS Kurtarma lisansını 700 ABD dolarına satın alma seçeneği bir seçenek değildir. "Potansiyel bir düşmanın topraklarından" dışarıdan birinin kurumsal verilere erişmesine izin vermek de bir seçenek değil. Ancak VMFS bölümlerinin UFS Explorer tarafından da okunabileceği Google'da araştırıldı.
DiskInternals VMFS Kurtarma
Deneme sürümü indirildi ve kuruldu. Program boş VMFS bölümünü başarıyla gördü:
kip Silmeyi Geri Al (Hızlı Tarama) Ayrıca içinde diskler bulunan sanal makine klasörlerinin bulunduğu eski püskü bir Veri Deposu da buldum:
Önizleme, dosyaların canlı olduğunu gösterdi:
Bölümün sisteme eklenmesi başarılı oldu, ancak bilinmeyen bir nedenden dolayı üç klasörün tümü aynı sanal makineyi içeriyordu. Elbette kanuna göre vahşet gerekli değildir.
Üç satır utançYazılımı utanmadan kilitleme girişimi başarısızlıkla sonuçlandı. Ancak UFS Explorer kilitlendi.
Yazılım hırsızlığına karşı son derece olumsuz bir tutumum var. Hiçbir şekilde lisanssız kullanıma karşı korumayı atlayacak yöntemlerin kullanılmasını teşvik etmiyorum.
Felaket bir durumdaydım ve başvurduğum önlemlerden hiç gurur duymuyordum.
UFS Gezgini
Bir disk taraması 7 düğümün varlığını gösterdi. Düğümlerin sayısı "şaşırtıcı bir şekilde" VMFS Recovery tarafından tespit edilen *-flat.vmdk dosyalarının sayısıyla çakıştı:
Dosya boyutları ve düğüm boyutlarının karşılaştırılması da bayta kadar bir eşleşme gösterdi. Aynı zamanda *-flat.vmdk dosyalarının adları ve buna bağlı olarak sanal makinelere aitlikleri de geri yüklendi.
Genel olarak, ESXi bakış açısından vmdk diskleri iki dosyadan oluşur: bir veri dosyası (<makine adı>-flat.vmdk) ve bir "fiziksel" disk düzeni dosyası (<makine adı>.vmdk). *-flat.vmdk dosyasını yerel bir makineden Datastore'a yüklerseniz, ESXi bunu geçerli bir disk dosyası olarak tanımayacaktır. VMware Bilgi Bankası'nda bir disk tanımlayıcı dosyasının manuel olarak nasıl oluşturulacağı hakkında bir makale bulunmaktadır: , ancak bunu yapmak zorunda değildim, ilgili dosyaların içeriğini DiskInternals VMFS Recovery'deki dosya içeriği önizleme alanından kopyaladım:
UFS Explorer'dan 4 TB'lik bir düğümün 2,5 saatlik boşaltılmasından ve hipervizörün Veri Deposuna 20 saatlik yüklemenin ardından, çöken disk dosyaları yeni oluşturulan sanal makineye bağlandı. Diskler toplandı. Herhangi bir veri kaybı gözlenmedi.
Kaynak: habr.com