Descargo de responsabilidad: La nota tiene un carácter recreativo. La densidad de información útil en ella es baja. Fue escrita "para mí".
Introducción lírica
La papelera de archivos en nuestra organización funciona en una máquina virtual VMware ESXi 6 sobre Windows Server 2016. Y no es solo una basura. Es un servidor de intercambio de archivos entre divisiones: aquí se lleva a cabo el trabajo colaborativo, la documentación de proyectos y las carpetas de escáneres de red. En resumen, aquí está toda la vida productiva.
Y ahora, este recipiente de toda la vida productiva ha comenzado a fallar. De hecho, un huésped podía quedar colgado silenciosamente por sí mismo, sin afectar a los demás. Podía colapsar al host entero y, por lo tanto, a todas las demás máquinas virtuales. Podía fallar solo y bloquear los servicios de cliente de vSphere: es decir, los procesos de los demás huéspedes estaban vivos, las máquinas funcionaban correctamente y respondían, pero la papelera de archivos no y el cliente de vSphere no se conectaba al host. En resumen, no se logró identificar ningún sistema. Las caídas podían ocurrir durante el día con baja carga. Podían suceder de noche con carga nula. Podían suceder de noche durante una copia de seguridad diferencial y carga media. Podían suceder los fines de semana durante una copia de seguridad completa y alta carga. Y se observó una clara degradación de la situación. Al principio, esto ocurría una vez al año, luego una vez cada seis meses. Hacia el final de mi paciencia, sucedió dos veces por semana.
Yo culpaba a la memoria RAM. Pero no me dejaban detener la papelera ni siquiera los fines de semana y ejecutar Memtest. Esperaban a las fiestas de mayo. Durante las fiestas de mayo, ejecuté Memtest y... no se encontraron errores.
Me quedé asombrado y decidí tomar vacaciones. Mientras estaba de vacaciones, la papelera no tuvo ninguna caída. Y cuando volví el lunes, el primer día de trabajo, la papelera estaba caída. Soportó una copia de seguridad completa y justo al final colapsó. Este cálido recibimiento de regreso de vacaciones me impulsó a tomar la decisión de trasladar físicamente los discos de la máquina virtual a otro host.
Y, aunque es bien sabido que no se debe hacer nada serio el primer día después de las vacaciones, aunque durante todo el camino al trabajo me estaba preparando para no trabajar, mi indignación por otra caída me sacó de la cabeza tanto la disposición como las promesas...
Los discos físicos fueron trasladados a otro host. Conexión en caliente. En la configuración de almacenamiento en la pestaña Discos aparecen discos. En la pestaña Datastores almacenamientos en estos discos — no hay ninguno. Actualizar — no aparecen. Y, por supuesto, la primera reacción es— Agregar Almacenamiento. El asistente para agregar dice que lo soporta. Por supuesto, lo soporta y VMFS. No tenía dudas al respecto. Una rápida revisión de los mensajes del asistente en cada paso: Siguiente, Siguiente, Siguiente, Finalizar. La mirada ni siquiera se posó en el pequeño círculo amarillo con un signo de exclamación en la parte inferior de la ventana de uno de los pasos del asistente.
Al finalizar el asistente, el nuevo Datastore apareció en la lista… y junto a él, los Datastores de los demás discos físicos.
Voy a navegar por el Datastore que acabo de agregar, y está… vacío. Por supuesto, volví a quedarme atónito. Son las 8 de la mañana, mis primeros 15 minutos de trabajo después de las vacaciones, ni siquiera he revuelto el azúcar en el café. Y sucede esto. El primer pensamiento fue — no saqué el disco correcto del host 'nativo'. Miré si el Datastore buscado estaba presente en el host 'nativo': no, no está. El segundo pensamiento fue: '¡mierda!'. No estoy seguro, pero creo que el tercero, cuarto y al menos el quinto pensamiento fueron igual de intensos.
Para disipar dudas, rápidamente instalé una nueva versión de prueba de ESXi, tomé un disco no original y, ya leyendo atentamente, pasé por los pasos del asistente. Sí. Al agregar un Datastore a través del asistente, se pierde toda la información en el disco sin posibilidad de deshacer la operación y restaurar los datos. Más tarde, leí en uno de los foros una evaluación de este diseño del asistente: shitsome crap. Y estuve completamente de acuerdo.
A partir del sexto — los pensamientos fluyeron en una dirección más constructiva. Está bien. La inicialización lleva segundos incluso para un disco de 3Tb. Entonces, es un formateo de alto nivel. Significa que simplemente se sobrescribió la tabla de particiones. Significa que los datos aún están ahí. Ahora buscaremos algún unformat y voila.
Arranco la máquina desde la imagen de arranque de Strelec… Y descubro que los programas de recuperación de particiones saben todo, excepto sobre VMFS. Conocen la partición de Synology, por ejemplo, pero sobre VMFS — no.
El barrido de programas no es alentador: en el mejor de los casos, GetDataBack y R.Saver encuentran particiones NTFS con estructuras de directorios activas y nombres de archivos vivos. Pero eso no me satisface. Necesito dos archivos vmdk: con el disco del sistema y el disco de archivos basura.
Y aquí me doy cuenta de que, parece, tendré que instalar Windows y restaurar desde una copia de seguridad de archivos. Al mismo tiempo, recuerdo que tenía una raíz DFS allí. Además, hay un sistema completamente salvaje en cuanto a volumen y complejidad de permisos de acceso a las carpetas de los departamentos. No es una opción. La única opción aceptable en tiempo es restaurar el estado del sistema y del disco con los datos y todos los permisos.
De nuevo buscando en Google, foros, KB's y nuevamente el llanto de Yaroslava: VMware ESXi no prevé un mecanismo de recuperación de datos. Todas las ramas de discusión tienen dos finales: alguien se recuperó con la costosa DiskInternals VMFS Recovery o alguien fue ayudado por un especialista en servicios que promueve activamente sus servicios de vmfs-tools y dd. La opción de comprar la licencia de DiskInternals VMFS Recovery por $700 no es una opción. Permitir que una persona ajena desde "el territorio de un potencial adversario" acceda a datos corporativos tampoco es una opción. Sin embargo, se encontró que UFS Explorer también puede leer particiones VMFS.
DiskInternals VMFS Recovery
Se descargó e instaló la versión de prueba. El programa vio con éxito la partición VMFS vacía:
En modo Undelete (Fast Scan) también encontró el Datastore perdido con carpetas máquinas virtuales con discos dentro:
La vista previa mostró que los archivos estaban vivos:
El montaje de la partición en el sistema fue exitoso, pero por razones inexplicables en las tres carpetas había la misma máquina virtual. Por supuesto, por ley de Murphy, no era la que se necesitaba.
Tres líneas de vergüenzaEl intento de piratear descaradamente el software terminó en fracaso. Pero se logró piratear UFS Explorer.
Soy extremadamente negativo respecto al robo de software. De ninguna manera insto a utilizar medios para eludir la protección contra el uso no licenciado.
Me encontraba en una situación catastrófica y no estaba orgulloso de las medidas que tomé.
UFS Explorer
El escaneo del disco mostró la presencia de 7 nodos. La cantidad de nodos coincidió "asombrosamente" con la cantidad de archivos *-flat.vmdk que encontró VMFS Recovery:
La comparación de tamaños de archivos y tamaños de nodos también mostró coincidencia hasta el byte. Al mismo tiempo, se restauraron los nombres de los archivos *-flat.vmdk y, por lo tanto, su pertenencia a las máquinas virtuales.
En general, los discos vmdk desde la perspectiva de ESXi consisten en dos archivos: el archivo de datos (<nombre de la máquina>-flat.vmdk) y el archivo de particionado "físico" del disco (<nombre de la máquina>.vmdk). Si se sube el archivo *-flat.vmdk desde una máquina local al Datastore, ESXi no lo reconocerá como un archivo de disco válido. En la base de conocimientos de VMware hay un artículo sobre cómo crear manualmente un archivo de descriptor de disco: , pero no tuve que hacer eso, simplemente copié y pegué el contenido de los archivos correspondientes desde el área de vista previa de contenido del archivo en DiskInternals VMFS Recovery:
Tras 4 horas de extracción de 2.5TB del nodo de UFS Explorer y 20 horas de carga en el Datastore del hipervisor, los archivos de disco destruidos se conectaron a la máquina virtual recién creada. Los discos fueron reconocidos. No se notaron pérdidas de datos.
Fuente: habr.com
