Bagaimana saya memutar kembali sistem sebulan yang lalu dan mendapatkan semuanya kembali? Pengalaman menggunakan ESXi. Atau bagaimana tidak melakukannya

Halo semuanya. Bagi seseorang, ini mungkin sebuah cerita instruktif tentang bagaimana hal itu tidak layak dilakukan dan mengapa beberapa pekerjaan teknis penting pada suatu pagi (dalam suatu sistem di mana Anda sedikit memahami) dapat menyebabkan keruntuhan besar dan downtime selama dua hari.


gambar


Catatan singkat adalah kisah administrator sistem amatir yang baru saja mulai terjun ke dunia virtualisasi. Kisah tentang bagaimana snapshots tidak membantu, tetapi mengganggu dan membuat kemunduran sistem selama sebulan, dan kemudian dengan downtime dalam 2 hari saya mengeluarkan semua file dari sana dan mengembalikan sistem.


Latar belakang


Setelah dua tahun duduk di sistem nix , dan khususnya di server ubuntu (16,04 LTS), saya memutuskan untuk mencoba virtualisasi. Seorang teman menyarankan ESXi sebagai solusi gratis untuk server kecil (kasus saya: 1 prosesor + hanya 8 GB RAM). Proses pemindahan menjadi rumit oleh fakta bahwa Anda harus terlebih dahulu menaikkan workstation vmware dengan vmware converter di windows-computer, mentransfer sistem yang sudah selesai di sana, kemudian mengangkatnya di server esxi dan setelah konverter yang akrab mentransfer sistem ke esxi. Ini adalah perjalanan yang panjang dan menyakitkan. Kesalahan utama selama transfer, yang saya buat dan yang masih muncul pada saya, adalah bahwa saya menggunakan disk yang tipis. Yaitu, berada di server ubuntu yang bersih dengan disk yang diformat dalam exfat-4, saya memiliki tempat 223,8 GB di ssd. Pindah ke esxi dan memformat disk menjadi format yang tidak dapat dimengerti untuk apa pun, saya kehilangan hanya 300 MB, tetapi karena mereka saya tidak dapat membuat disk tebal, yang saya (kemudian ternyata) sangat membutuhkannya.


Mulai


Saya biasa memecah kayu bakar dengan server ubuntu (ketika saya baru saja "mempelajarinya"), memutar kembali dan menginstal ulang sistem sekali sebulan atau dua. Sekarang saya melanggar kayu bakar dengan ESXi. Saya pikir tidak perlu untuk menggambarkan masalah disk tipis (singkatnya, setelah memperluas ruang mereka tidak "menyempit" ke arah yang berlawanan. Mereka juga dapat melampaui jumlah fisik memori pada disk). Pertama, saya menggunakan swap pada drive SSD yang sama tanpa mengaturnya dengan benar di ESXi. Dia memakan memori, menulis beberapa file sementara di sana, dan sementara itu semakin tipis.
Kedua, untuk beberapa alasan saya melakukan snapshot. Pada saat itu saya dibimbing oleh fakta bahwa "yah, nyaman, cepat dan semua itu." Masih tidak curiga jenis cack dan bom apa yang mereka tanam untukku. Ketiga, saya tidak mengikuti jumlah memori yang menurun dengan cepat pada disk.


gambar


Dasi


Bel pertama adalah pemberhentian mobil utama pada 17 Juli. Pemberitahuan telah tiba di surat tentang jatuhnya tuan rumah. Pergi ke esxi untuk mengambilnya (yah, tiba-tiba sesuatu bisa terjadi), gadis virtual memberi saya berita yang menyenangkan (sayangnya tidak ada tangkapan layar, sayangnya). Menceritakan kembali jendela pop-up freeware adalah sesuatu seperti โ€œMaaf, ruang disk sudah habis. Mesin virtual Anda dihentikan. Bersihkan tempat itu dan Anda dapat terus menggunakan VM. Ulangi Batalkan. Pada saat itu, masalah diselesaikan dengan menghapus VM kedua, yang memakan waktu sekitar 16GB. Tapi ini adalah solusi sementara, karena setiap hari, 5GB masih menghilang di suatu tempat, meskipun sistem tidak memiliki peningkatan pada file-file ini.


Akibatnya, pada 19 Juli malam, pada hari Kamis yang dingin, saya pertama kali menulis di pemanggang tentang masalah ini. Tidak ada jawaban. Saya pikir ini karena tag esxi tidak populer. Setelah google gagal, setelah - penghapusan snapshot. Pada saat itu, 5 gigabytes menghilang, ruang bebas menjadi lebih besar, tetapi tidak begitu banyak untuk melupakan masalah ini.


gambar


Setelah, dengan sedikit otak, saya mulai mempelajari hierarki foto. Yang terakhir, 000003, menempati ruang 12GB pada waktu itu. Dalam pengaturan VM, itu terdaftar sebagai file disk aktif dari mana mesin boot. Tanpa berpikir dua kali, saya menghapus file hard disk 1 disk dengan disk snapshot aktif dan memasukkan disk induk dari seluruh mesin virtual di tempatnya.


gambar


Sistem boot (sorakan), dan dengan itu file untuk 30 Juni. Tanggal modifikasi terakhir dari semua file pada disk induk. Saya menduga pada hari itulah saya membuat snapshot pertama. Logikanya, tidak ada lagi tempat. Di ruang kosong, masih sekitar 5GB, dan file-file hilang.


Pikiran pertama logis: apa yang saya lakukan, semua file menguap hingga 19 Juli. Kemudian saya melihat bahwa file snapshot tidak terhapus. Namun, ketika saya mencoba memuatnya sebagai disk utama, ESXi bersumpah pada disk induk yang diubah, yang seharusnya tidak menjadi "disk virtual induk telah dimodifikasi sejak anak dibuat" Kesalahan kekal saya selama dua hari berikutnya.


Googling


Waktu sudah mendekati jam dua pagi, dan aku membuang semua usaha sia-sia untuk mendapatkan setidaknya beberapa informasi dari * -0000 yang malang ini? -. Vmdk file snapshot.


Jumat pagi dimulai dengan google aktif yang sangat aktif seperti "cara mendapatkan file dari vmdk". Artikel, pembaca Linux (program windows) dan semua yang sering ditemui. Saya mentransfer 223 gigabyte ini dari server ke windows-laptop pada saluran 100Mbit, yang sangat menyakitkan. Saya mencoba me-mount disk SSD dari format vmware pada sistem linux, menggulung vmware-tools di atasnya, dia bersumpah pada ketidakcocokan versi (yang didukung terakhir adalah 5, tapi saya punya 6,5). Upaya untuk membuka melalui windows dan java juga sia-sia.


Dan bahkan setelah saya dapat mengakses (menggunakan program pembaca Linux di windows) file * -flat.vmdk, saya menerima file hanya sampai 30 Juni. Semua upaya lebih lanjut untuk me-mount file snapshot tidak menghasilkan apa-apa, program dikutuk pada disk yang tidak valid dan menolak untuk bekerja lebih lanjut.


Output ditemukan


Jumat sudah berakhir, saya kelelahan, dan juga kesal karena file tidak dapat dikembalikan. Tetapi hari Sabtu mulai berhasil. Di kesalahan Google (mengapa saya tidak segera melakukannya tidak diketahui) "Disk virtual induk telah dimodifikasi sejak anak dibuat" di baris pertama Google memberikan tautan ke halaman vmware. Banyak karakter menakutkan, garis merah dan semua itu langsung ketakutan. Saya membuka tautan dan meninggalkannya dengan harapan saya akan menemukan sesuatu yang lebih dimengerti.


Dan itu ditemukan. https://communities.vmware.com/thread/323730 Forum VmWare berbahasa Rusia dan masalah serupa bertemu saya di Internet. Ini mungkin bukan kasus yang sama dengan saya, tetapi setelah menggulir ke bawah dan membaca komentar, saya mencoba melakukan ini.


Dalam editor teks, menghubungkan ke esxi melalui sftp, saya membuka file dengan pengaturan disk induk. .vmdk (bukan -flat.vmdk) Saya mengenali CID disk, dan kemudian naik ke * -00001.vmdk, melakukan seperti yang dijelaskan oleh orang dengan nama panggilan apavlyuchenko di forum.


Dalam snapshot pertama, bidang CID dan parentCID harus menunjukkan CID dari disk induk. Dan kemudian dalam file .vmx di kolom
scsi0: 1.present = "false"
scsi0: 1.fileName = " .vmdk"
scsi0: 1.deviceType = "scsi-hardDisk"
ubah parameter FALSE ke TRUE dan .vmdk menjadi -00001.vmdk.


Dan memang, setelah itu mobilnya menyala dan tidak bersumpah atas kesalahan itu. Dan lihatlah! File muncul sebelum membuat snapshot kedua!


Di forum, seorang teman menjelaskan cara memulihkan file hanya dari satu snapshot. Tetapi kasus saya sulit (tampaknya, karena penyakit saya, yang disebut "tusuk semuanya dengan tangan Anda pada mesin yang bekerja"). Dan saya tidak punya satu snapshot, tapi tiga. Yang logis, itu perlu untuk terus mengubah file.


Jadi, tindakan saya.


Buka disk induk. Temukan CID-nya. Selanjutnya, salin CID disk induk ke baris parentCID disk -00001.vmdk (snapshot pertama). Di sana kita melihat CID dari snapshot ini dan menyalinnya ke baris parentCID drive -00002.vmdk (snapshot kedua). Di sana kita melihat CID dari snapshot ini dan menyalinnya ke baris parentCID drive -00003.vmdk (snapshot ketiga), well, setelah itu kita naik ke .vmx dan tentukan nama file snapshot pada baris fileName (dalam kasus saya * -0003.vmdk)


Hasilnya adalah sebagai berikut.


* .vmdk
CID = 387edddf
parentCID = ffffffff


* -00001.vmdk
CID = 0284jf712 (saya mengambil semua CID dari cetak tebal)
parentCID = 387edddf


* -00002.vmdk
CID = 732fhhtud
parentCID = 0284jf712


* -00003.vmdk
CID = 3747jfj4ff
parentCID = 732fhhtud


.vmx
scsi0: 1.present = "true"
scsi0: 1.fileName = " -00003.vmdk"
scsi0: 1.deviceType = "scsi-hardDisk"


Saya menyalakan VM, saya melihat bahwa data dipulihkan. Sepertinya melepaskan. Saya menyalin semuanya ke server lain, menghentikan mesin (sudah berteriak tentang kerusakan disk dan beberapa masalah kritis lainnya), mengembalikan pengaturan * .vmx kembali dan menyalin file kembali ke mesin yang berfungsi. Hore.


Kesimpulan


Kisah ini mengajarkan saya beberapa kebenaran emas yang tidak dapat dipahami sebelumnya.


Pertama, backup semuanya selalu dan di mana saja dan tidak ke disk di dalam mesin virtual, seperti yang saya lakukan sebelumnya. Perlu memiliki satu, atau bahkan dua drive cadangan, sehingga tidak ada downtime dua hari seperti itu. (Apakah file hilang? Kami memutar kembali, menyalin file dari cadangan, dan yang sederhana - bukan 48 jam, tetapi 2 jam dari kepolisian) Kedua, tidak melakukan apa pun pada kepala saya yang berat di suatu pagi (jika saya pergi tidur, saya akan datang dengan kepala yang bersih pada hari Jumat) ke jalan keluar lain, tetapi tidak merusak kayu bakar pada jam kedua malam itu) Ketiga, jangan membuat perubahan penting pada mesin yang bekerja. Dash dari mesin virtual kedua, buat snapshot di sana, lalu jadikan induk-drive yang utama dan lihat apa yang terjadi setelah itu - begitulah caranya. Dan keempat, lakukan lebih banyak backup. Bukan hanya VM, tetapi esxi sendiri secara keseluruhan.


Sumber daya PS yang akhirnya membantu saya:


Forum yang sama dengan apavlyuchenko yang luar biasa (kita tidak terbiasa, kalau itu)


Halaman tentang basis pengetahuan dari vmvara dengan deskripsi masalah saya dan cara untuk menyelesaikannya


Gambar yang saya gunakan


jika ada yang tertarik, dalam komentar saya dapat meninggalkan sumber daya yang artikelnya tidak membantu saya


Ps


Sayangnya, masalah hilangnya tempat itu masih relevan. Jika Anda memiliki pemikiran atau keinginan untuk membantu saya mengatasi hal ini, silakan komentar. Kita bisa membicarakannya di sana. Atau jika Anda tahu cara lain untuk memulihkan file dari snapshot disk dan juga ingin membagikannya, maka saya akan tertarik untuk membacanya. Terima kasih

Source: https://habr.com/ru/post/id418049/


All Articles