Restauramos máquinas virtuales del almacén de datos inicializado erróneamente. La historia de un sinsentido con final feliz

Descargo de responsabilidad: la nota es entretenida. La densidad específica de información útil en ella es pequeña. Fue escrito "para ti mismo".

Introducción lírica

El volcado de archivos en nuestra organización está girando en una máquina virtual VMware ESXi 6 en Windows Server 2016. Y esto no es solo un volcado. Este es un servidor de intercambio de archivos entre divisiones estructurales: hay colaboración, documentación de proyectos y carpetas de escáneres de red. En general, esta es toda la vida de producción.

Y este contenedor de toda la vida de producción comenzó a colgar. Además, el invitado podía ahorcarse en silencio, sin afectar al resto. Podría colgar detrás de sí mismo todo el host y, en consecuencia, todas las demás máquinas invitadas. Podría colgarme y colgar los servicios del cliente vSphere: es decir, los procesos de los otros invitados están vivos, las máquinas funcionan correctamente y responden, pero no hay corrupción de archivos y vSphere Client no se aferra al host. En general, no se pudo identificar ningún sistema. Los bloqueos pueden ocurrir durante el día durante una carga débil. Podría por la noche durante carga cero. Podría por la noche durante el respaldo diferencial y la carga media. Podría el fin de semana durante una copia de seguridad completa y alta carga. Y hubo una clara degradación de la situación. Al principio era una vez al año, luego una vez cada seis meses. Al final de mi paciencia, dos veces por semana.

Pequé por RAM. Pero no me dejaron detener la basura ni siquiera los fines de semana y ahuyentar a Memtest. Esperé las vacaciones de mayo. En las vacaciones de mayo, me fui de Memtest y ... no se encontraron errores.

Me sorprendió y decidí irme de vacaciones. Mientras estaba de vacaciones, el basurero no tenía una sola caída. Y cuando el lunes el primer día fue a trabajar, el basurero colgó. Mantuvo una copia de seguridad completa, y justo al final se colgó. Una reunión tan cálida de vacaciones me llevó a la decisión de arrastrar físicamente el disco de invitado a otro anfitrión.

Y, aunque se sabe desde hace mucho tiempo que el primer día después de unas vacaciones, no se puede hacer nada serio, aunque me preparé para trabajar todo el camino, mi indignación con el siguiente congelamiento me dejó sin palabras y votos ...

Los discos físicos se reorganizaron a otro host. Conexión en caliente. Los discos aparecen en la configuración de almacenamiento en la pestaña Unidades . En la pestaña Almacenes de datos, el almacenamiento en estas unidades no lo es. Actualizar : no aparece. Bueno, por supuesto, el primer impulso es Agregar almacenamiento . El Asistente para agregar le dice lo que admite. Por supuesto, también es compatible con VMFS. No tuve dudas Un vistazo rápido a los mensajes del asistente en cada paso: Siguiente, Siguiente, Siguiente, Finalizar. Su mirada ni siquiera se cerró para atrapar un pequeño círculo amarillo con un signo de exclamación en la parte inferior de la ventana de uno de los pasos del maestro.

Al final del asistente, apareció un nuevo almacén de datos en la lista ... y con él almacenes de datos de otros discos físicos.

Me dirijo a la navegación en el Almacén de datos recién agregado y ... está vacío. Por supuesto, nuevamente me sorprendió. 8 am en el reloj, los primeros 15 minutos en el trabajo después de las vacaciones, incluso el azúcar en el café aún no se ha agitado. Y aqui esta. Mi primer pensamiento fue que saqué el disco equivocado del host "nativo". Miré para ver si el almacén de datos requerido está presente en el host "nativo": no, no está presente. El segundo pensamiento fue: "¡mierda # b!". No estoy seguro, pero me parece que el tercer, cuarto y al menos quinto pensamiento fue el mismo.

Para disipar dudas, instalé rápidamente un ESXi nuevo en la muestra, tomé el disco izquierdo y, después de leerlo, seguí los pasos del asistente. Si Al agregar un almacén de datos utilizando el asistente, todos los datos en el disco se pierden sin la capacidad de revertir la operación y restaurar los datos. Más tarde, leí en uno de los foros una evaluación de tal diseño por parte del maestro: mierda horrible. Y ahora mismo estoy de acuerdo.

Comenzando con el sexto, los pensamientos fluyeron de una manera más constructiva. Esta bien La inicialización lleva unos segundos, incluso para un disco de 3Tb. Entonces este es un formato de alto nivel. Entonces, la tabla de particiones fue simplemente reescrita. Entonces los datos todavía están allí. Así que ahora busquemos un poco de formato y listo.

Cargo el auto desde la imagen de arranque de Strelec ... Y descubro que todos los programas de recuperación de particiones son conocidos, excepto VMFS. Por ejemplo, conocen el diseño de partición de Synology, pero VMFS no.

Enumerar programas no es reconfortante: en el mejor de los casos, GetDataBack y R.Saver encuentran particiones NTFS con estructuras de directorios en vivo y nombres de archivos en vivo. Pero eso no me conviene. Necesito dos archivos vmdk: con un disco del sistema y un contenedor de basura.

Y luego entiendo que, al parecer, ahora instalaré Windows y desplegaré la copia de seguridad del archivo. Y al mismo tiempo recuerdo que tenía una raíz DFS allí. Y también un sistema de derechos de acceso a las carpetas de unidades completamente voluminoso y ramificado. No es una opcion. La única opción de tiempo aceptable es restaurar el estado del sistema y el disco con datos y todos los derechos.

Nuevamente buscando en Google, foros, KB'shki y nuevamente llorando Yaroslavna: VMware ESXi no proporciona un mecanismo de recuperación de datos. Todos los hilos de discusión tienen dos finales: alguien se recuperó con la ayuda de DiskInternals VMFS Recovery no barato o alguien que promovió activamente sus servicios con la ayuda de vmfs-tools y dd ayudó. La opción de comprar una licencia de recuperación de DiskInternals VMFS por $ 700 no es una opción. La admisión de un extraño desde el "territorio de un posible adversario" a los datos corporativos tampoco es una opción. Pero se buscó en Google que las particiones VMFS pueden leer también UFS Explorer.

DiskInternals VMFS Recovery

La versión de prueba fue descargada e instalada. El programa vio con éxito una sección VMFS vacía:



En el modo Recuperar (Escaneo rápido) , también encontré un almacén de datos en mal estado con carpetas de máquinas virtuales con discos dentro:



La vista previa mostró que los archivos están en vivo:



El montaje de la partición en el sistema fue exitoso, pero por alguna razón, las tres carpetas tenían la misma máquina virtual. Por supuesto, la ley de la maldad no es lo que se requiere.

UFS Explorer

Escanear el disco mostró la presencia de 7 nodos. El número de nodos de una "manera sorprendente" coincidió con el número de archivos * -flat.vmdk detectados por VMFS Recovery:



La comparación de tamaños de archivo y tamaños de nodo también mostró una coincidencia hasta el byte. Al mismo tiempo, se restauraron los nombres de los archivos * -flat.vmdk y, en consecuencia, su pertenencia a máquinas virtuales.



En general, desde el punto de vista de ESXi, los discos vmdk consisten en dos archivos: un archivo de datos (<nombre del equipo> -flat.vmdk) y un archivo de partición del disco físico (<nombre del equipo> .vmdk). Si carga el archivo * -flat.vmdk desde la máquina local al Almacén de datos, ESXi no lo reconocerá como un archivo de disco válido. Hay un artículo en la base de conocimiento de VMware sobre cómo crear manualmente un archivo descriptor de disco: kb.vmware.com/s/article/1002511 , pero no tuve que hacerlo, simplemente copié el contenido de los archivos correspondientes del área de vista previa de contenido de archivos en DiskInternals VMFS Recovery :



Después de 4 horas de descargar un nodo de 2.5TB del Explorador UFS y 20 horas de carga en el hipervisor Datastore, los archivos de disco fallidos se conectaron a una máquina virtual recién creada. Ruedas recogidas. No se notó pérdida de datos.