Penolakan: Catatan ini untuk tujuan hiburan. Kepadatan spesifik informasi berguna di dalamnya rendah. Itu ditulis “untuk diriku sendiri.”
Pengenalan liris
File dump di organisasi kami berjalan pada mesin virtual VMware ESXi 6 yang menjalankan Windows Server 2016. Dan ini bukan hanya tempat pembuangan sampah. Ini adalah server pertukaran file antar divisi struktural: ada kolaborasi, dokumentasi proyek, dan folder dari pemindai jaringan. Secara umum, seluruh kehidupan produksi ada di sini.
Dan wadah seluruh kehidupan produksi ini mulai digantung. Apalagi tamu tersebut bisa dengan tenang gantung diri tanpa mempengaruhi orang lain. Dia bisa menjatuhkan seluruh host dan, karenanya, semua mesin tamu lainnya. Saya dapat gantung diri dan menggantung layanan klien vSphere: yaitu, proses tamu lain tetap hidup, mesin bekerja dengan baik dan merespons, tetapi tidak ada mesin cuci file dan Klien vSphere tidak melekat pada host. Secara umum, tidak ada sistem yang dapat diidentifikasi. Pembekuan dapat terjadi pada siang hari saat beban rendah. Mereka bisa melakukannya pada malam hari tanpa beban. Bisa di malam hari saat cadangan diferensial dan beban rata-rata. Bisa di akhir pekan saat full backup dan high load. Dan jelas terjadi penurunan situasi. Awalnya setahun sekali, lalu enam bulan sekali. Di akhir kesabaran saya - dua kali seminggu.
Saya mengalami masalah ingatan. Namun mereka tidak mengizinkan saya menghentikan tumpukan sampah bahkan di akhir pekan dan menjalankan Memtest. Kami sedang menunggu liburan bulan Mei. Selama liburan bulan Mei, saya menjalankan Memtest dan... tidak ada kesalahan yang ditemukan.
Saya kagum dan memutuskan untuk pergi berlibur. Saat saya sedang berlibur, tidak ada satu pun hangup di tempat pembuangan sampah. Dan ketika saya kembali bekerja pada hari pertama di hari Senin, ada tumpukan sampah. Saya melakukan pencadangan penuh dan langsung menutupnya setelah selesai. Sambutan hangat dari liburan mendorong saya mengambil keputusan untuk secara fisik menyeret disk dengan mesin tamu ke host lain.
Dan, meskipun sudah lama diketahui bahwa Anda tidak dapat melakukan sesuatu yang serius pada hari pertama setelah liburan, meskipun saya sedang mempersiapkan diri untuk tidak bekerja jauh-jauh ke tempat kerja, kemarahan saya terhadap kebekuan yang lain membuat suasana hati dan perasaan saya terguncang. sumpah keluar dari kepalaku...
Disk fisik telah dipindahkan ke host lain. Koneksi panas. Dalam pengaturan penyimpanan di tab Drive disk muncul. Di tab Datastore Tidak ada penyimpanan pada disk ini. menyegarkan - tidak muncul. Ya, tentu saja, dorongan pertama - Tambahkan Penyimpanan. Add Wizard menjelaskan apa yang didukungnya. Tentu saja juga mendukung VMFS. Saya tidak meragukannya. Sekilas pesan wizard di setiap langkah: Berikutnya, Berikutnya, Berikutnya, Selesai. Mata bahkan tidak bisa menangkap lingkaran kuning kecil dengan tanda seru di bagian bawah jendela salah satu langkah sang master.
Di akhir wizard, Datastore baru muncul di daftar... dan bersamaan dengan itu, Datastore dari disk fisik yang tersisa.
Saya melanjutkan untuk menavigasi Datastore yang baru ditambahkan, dan itu... kosong. Tentu saja saya kembali takjub. Sekarang jam 8 pagi, 15 menit pertama masuk kerja setelah liburan, aku bahkan belum mengaduk gula di kopiku. Dan ini dia. Pikiran pertama adalah saya menarik disk yang salah dari host “asli”. Saya melihat apakah Datastore yang diperlukan ada di host "asli": tidak, itu tidak ada. Pikiran kedua adalah: "persetan!" Saya tidak yakin, tetapi menurut saya pemikiran ketiga, keempat, dan setidaknya kelima adalah sama.
Untuk menghilangkan keraguan, saya segera menginstal ESXi baru untuk pengujian, mengambil disk kiri dan, setelah membacanya, mengikuti langkah-langkah wizard. Ya. Saat Anda menambahkan Datastore menggunakan wizard, semua data di disk akan hilang tanpa kemampuan untuk memutar kembali operasi dan memulihkan data. Kemudian saya membaca di salah satu forum penilaian desain ini oleh seorang master: omong kosong yang menyebalkan. Dan saya sangat setuju.
Mulai dari yang keenam, pemikiran mengalir ke arah yang lebih konstruktif. OKE. Inisialisasi membutuhkan waktu beberapa detik bahkan untuk disk 3Tb. Jadi ini adalah pemformatan tingkat tinggi. Ini berarti tabel partisi telah ditulis ulang. Jadi datanya masih ada. Jadi, sekarang kita akan mencari beberapa unformat dan voila.
Saya mem-boot mesin dari image boot Strelec... Dan saya menemukan bahwa program pemulihan partisi mengetahui segalanya kecuali VMFS. Misalnya, mereka mengetahui tata letak partisi Synology, tetapi tidak mengetahui VMFS.
Mencari melalui program tidak meyakinkan: yang terbaik, GetDataBack dan R.Saver menemukan partisi NTFS dengan struktur direktori langsung dan nama file langsung. Tapi ini tidak cocok untukku. Saya memerlukan dua file vmdk: dengan disk sistem dan disk file sampah.
Dan kemudian saya memahami bahwa sepertinya saya sekarang akan menginstal Windows dan meluncurkan cadangan file. Dan pada saat yang sama saya ingat bahwa saya memiliki root DFS di sana. Dan juga sistem hak akses ke folder departemen yang cakupan dan konsekuensinya sangat liar. Bukan suatu pilihan. Satu-satunya pilihan yang dapat diterima oleh waktu adalah memulihkan keadaan sistem dan disk dengan data dan semua hak.
Sekali lagi Google, forum, KB'shki dan lagi tangisan Yaroslavna: VMware ESXi tidak menyediakan mekanisme pemulihan data. Semua rangkaian diskusi memiliki dua akhir: seseorang dipulihkan menggunakan DiskInternals VMFS Recovery yang mahal, atau seseorang dibantu oleh spesialis perangkat lunak yang secara aktif mempromosikan layanannya vmfs-tools и dd. Pilihan untuk membeli lisensi DiskInternals VMFS Recovery seharga $700 bukanlah suatu pilihan. Mengizinkan orang luar dari “wilayah musuh potensial” untuk mengakses data perusahaan juga bukanlah suatu pilihan. Namun di googling ternyata partisi VMFS juga bisa dibaca oleh UFS Explorer.
Pemulihan VMFS DiskInternal
Versi uji coba telah diunduh dan diinstal. Program berhasil melihat partisi VMFS yang kosong:
mode Batalkan penghapusan (Pemindaian Cepat) Saya juga menemukan Datastore kumuh dengan folder mesin virtual dengan disk di dalamnya:
Pratinjau menunjukkan bahwa file tersebut masih hidup:
Pemasangan partisi ke dalam sistem berhasil, tetapi karena alasan yang tidak diketahui, ketiga folder tersebut berisi mesin virtual yang sama. Tentu saja, menurut hukum, kekejaman bukanlah hal yang diwajibkan.
Tiga baris rasa maluUpaya untuk mengunci perangkat lunak tanpa malu-malu berakhir dengan kegagalan. Tapi UFS Explorer terkunci.
Saya memiliki sikap yang sangat negatif terhadap pencurian perangkat lunak. Saya sama sekali tidak menganjurkan penggunaan cara untuk mengabaikan perlindungan terhadap penggunaan yang tidak berlisensi.
Saya berada dalam situasi bencana dan sama sekali tidak bangga dengan tindakan yang telah saya ambil.
Penjelajah UFS
Pemindaian disk menunjukkan keberadaan 7 node. Jumlah node “secara mengejutkan” bertepatan dengan jumlah file *-flat.vmdk yang terdeteksi oleh VMFS Recovery:
Perbandingan ukuran file dan ukuran node juga menunjukkan kecocokan hingga ke byte. Pada saat yang sama, nama file *-flat.vmdk dan, karenanya, kepemilikannya pada mesin virtual dipulihkan.
Secara umum, disk vmdk dari sudut pandang ESXi terdiri dari dua file: file data (<nama mesin>-flat.vmdk) dan file tata letak disk “fisik” (<nama mesin>.vmdk). Jika Anda mengunggah file *-flat.vmdk ke Datastore dari mesin lokal, ESXi tidak akan mengenalinya sebagai file disk yang valid. Basis Pengetahuan VMware memiliki artikel tentang cara membuat file deskriptor disk secara manual: , tapi saya tidak perlu melakukan ini, saya cukup menyalin konten file terkait dari area pratinjau konten file di DiskInternals VMFS Recovery:
Setelah 4 jam membongkar node 2,5 TB dari UFS Explorer dan 20 jam memuat ke Datastore hypervisor, file disk yang rusak terhubung ke mesin virtual yang baru dibuat. Disknya terangkat. Tidak ada kehilangan data yang diamati.
Sumber: www.habr.com