Disclaimer: A nota é para fins de entretemento. A densidade específica de información útil nel é baixa. Foi escrito "para min".
Introdución lírica
O vertedoiro de ficheiros da nosa organización execútase nunha máquina virtual VMware ESXi 6 con Windows Server 2016. E isto non é só un vertedoiro de lixo. Este é un servidor de intercambio de ficheiros entre divisións estruturais: hai colaboración, documentación do proxecto e cartafoles de escáneres de rede. En xeral, toda a vida de produción está aquí.
E este recipiente de toda a vida de produción comezou a colgar. Ademais, o convidado podía aforcarse tranquilamente sen afectar aos demais. Podería derrubar todo o host e, en consecuencia, todas as outras máquinas convidadas. Podería aforcarme e colgar os servizos do cliente de vSphere: é dicir, os procesos dos outros convidados están vivos, as máquinas funcionan correctamente e responden, pero non hai un lavador de ficheiros e o cliente de vSphere non se aferra ao host. En xeral, non se puido identificar ningún sistema. As conxelacións poden producirse durante o día durante unha carga baixa. Poderían facelo pola noite sen carga. Podería pola noite durante a copia de seguridade diferencial e a carga media. Podería os fins de semana durante copias de seguridade completas e carga elevada. E houbo unha clara degradación da situación. Ao principio era unha vez ao ano, despois unha vez cada seis meses. Ao final da miña paciencia - dúas veces por semana.
Tiven un problema de memoria. Pero non me deixaron parar o lixo nin os fins de semana e executar Memtest. Estabamos agardando as vacacións de maio. Durante as vacacións de maio, fixen o Memtest e... non se atoparon erros.
Quedei abraiado e decidín ir de vacacións. Mentres estaba de vacacións, non houbo nin un só colgado no vertedoiro. E cando volvín traballar o luns o primeiro día, había un montón de lixo. Aguantei unha copia de seguridade completa e colguei xusto despois de rematar. A benvida tan cálida das vacacións levoume á decisión de arrastrar fisicamente os discos coa máquina convidada a outro host.
E, aínda que hai tempo que se sabe que non se pode facer nada serio o primeiro día despois dunhas vacacións, aínda que eu estaba a prepararme para non traballar todo o camiño ata o traballo, a miña indignación por outra conxelación golpeou tanto o meu humor como o meu xuros fóra da miña cabeza...
Os discos físicos movéronse a outro host. Conexión quente. Na configuración de almacenamento da pestana Drive aparecen discos. Na pestana Almacéns de datos Non hai almacenamento nestes discos. refrescar - non aparecer. Ben, por suposto, o primeiro impulso - Engadir almacenamento. O Asistente de Engadir explica o que admite. Por suposto, tamén admite VMFS. Non o dubidei. Unha ollada rápida ás mensaxes do asistente en cada paso: Seguinte, Seguinte, Seguinte, Finalizar. O ollo nin sequera chegou a captar o pequeno círculo amarelo cun signo de exclamación no fondo da ventá dun dos pasos do mestre.
Ao final do asistente, apareceu o novo Datastore na lista... e xunto con el os Datastores dos discos físicos restantes.
Paso a navegar polo Datastore recén engadido e está... baleiro. Por suposto, volvín caer no asombro. Son as 8 da mañá, os primeiros 15 minutos no traballo despois das vacacións, aínda non metín o azucre no meu café. E aquí está. O primeiro pensamento foi que tirei o disco incorrecto do host "nativo". Mirei para ver se o almacén de datos necesario estaba presente no host "nativo": non, non estaba presente. O segundo pensamento foi: "¡Joder!" Non estou seguro, pero paréceme que o terceiro, o cuarto e polo menos o quinto pensamento foi o mesmo.
Para disipar dúbidas, instalei rapidamente un novo ESXi para probalo, collín o disco esquerdo e, xa lendo, percorrín os pasos do asistente. Si. Cando engades un Datastore mediante o asistente, pérdense todos os datos do disco sen que se poida recuperar a operación e restaurar os datos. Máis tarde lin nun dos foros unha valoración deste deseño por parte dun mestre: merda de merda. E aceptei de verdade.
A partir do sexto, os pensamentos fluíron nunha dirección máis construtiva. OK. A inicialización leva uns segundos incluso para un disco de 3 Tb. Polo tanto, este é un formato de alto nivel. Isto significa que a táboa de particións foi simplemente reescrita. Así que os datos seguen aí. Entón, agora buscaremos un pouco de formato e listo.
Arranco a máquina desde a imaxe de arranque de Strelec... E descubro que os programas de recuperación de particións o saben todo, excepto VMFS. Por exemplo, coñecen o deseño da partición de Synology, pero non VMFS.
Buscar a través de programas non é tranquilizador: no mellor dos casos, GetDataBack e R.Saver atopan particións NTFS cunha estrutura de directorios en directo e nomes de ficheiros en directo. Pero isto non me convén. Necesito dous ficheiros vmdk: co disco do sistema e co disco lixo.
E entón entendo que parece que agora instalarei Windows e lanzarei desde unha copia de seguridade de ficheiros. E ao mesmo tempo lembro que alí tiña unha raíz DFS. E tamén un sistema de dereitos de acceso ás carpetas do departamento que é absolutamente salvaxe en alcance e ramificacións. Non é unha opción. A única opción aceptable é restaurar o estado do sistema e do disco cos datos e todos os dereitos.
De novo Google, foros, KB'shki e outra vez o choro de Yaroslavna: VMware ESXi non ofrece un mecanismo de recuperación de datos. Todos os fíos de discusión teñen dous finais: alguén foi recuperado usando o caro DiskInternals VMFS Recovery, ou alguén foi axudado por un especialista en software que promove activamente os seus servizos. vmfs-ferramentas и dd. A opción de mercar unha licenza DiskInternals VMFS Recovery por $ 700 non é unha opción. Permitir que un estranxeiro do "territorio dun inimigo potencial" acceda aos datos corporativos tampouco é unha opción. Pero buscouse en Google que as particións VMFS tamén se poden ler polo Explorador de UFS.
Recuperación de VMFS de DiskInternals
A versión de proba foi descargada e instalada. O programa viu correctamente a partición VMFS baleira:
No modo Recuperar (escaneo rápido) Tamén atopei un Datastore en mal estado con cartafoles de máquinas virtuais con discos dentro:
A vista previa mostrou que os ficheiros están activos:
O montaxe da partición no sistema tivo éxito, pero por algún motivo descoñecido, os tres cartafoles contiñan a mesma máquina virtual. Por suposto, segundo a lei, a mesquindade non é o que se esixe.
Tres liñas de vergoñaO intento de bloquear sen vergoña o software acabou nun fracaso. Pero UFS Explorer pechouse.
Teño unha actitude moi negativa cara ao roubo de software. De ningún xeito animo o uso de medios para evitar a protección contra o uso sen licenza.
Estaba nunha situación catastrófica e non estaba nada orgulloso das medidas ás que recorrera.
Explorador UFS
Unha exploración do disco mostrou a presenza de 7 nodos. O número de nós "sorprendentemente" coincidiu co número de ficheiros *-flat.vmdk detectados por VMFS Recovery:
Unha comparación dos tamaños dos ficheiros e dos nodos tamén mostrou unha coincidencia ata o byte. Ao mesmo tempo, restauráronse os nomes dos ficheiros *-flat.vmdk e, en consecuencia, a súa pertenza a máquinas virtuais.
En xeral, os discos vmdk desde o punto de vista ESXi consisten en dous ficheiros: un ficheiro de datos (<nome da máquina>-flat.vmdk) e un ficheiro de deseño de disco "físico" (<nome da máquina>.vmdk). Se cargas un ficheiro *-flat.vmdk ao Datastore desde unha máquina local, ESXi non o recoñecerá como un ficheiro de disco válido. A VMware Knowledge Base ten un artigo sobre como crear manualmente un ficheiro descritor de disco: , pero non tiven que facelo, simplemente copiei o contido dos ficheiros correspondentes da área de vista previa do contido do ficheiro en DiskInternals VMFS Recovery:
Despois de 4 horas de descarga dun nodo de 2,5 TB de UFS Explorer e 20 horas de carga no almacén de datos do hipervisor, os ficheiros de disco bloqueados conectáronse á máquina virtual recentemente creada. Os discos colleron. Non se observou ningunha perda de datos.
Fonte: www.habr.com