Cláusula de exención de responsabilidades: La nota es para fines de entretenimiento. La densidad específica de información útil que contiene es baja. Fue escrito "para mí".
Introducción lírica
El volcado de archivos en nuestra organización se ejecuta en una máquina virtual VMware ESXi 6 que ejecuta Windows Server 2016. Y esto no es solo un volcado de basura. 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, toda la vida de producción está aquí.
Y este contenedor de toda su vida productiva empezó a colgarse. Además, el invitado podía ahorcarse tranquilamente sin afectar a los demás. Podría acabar con todo el host y, en consecuencia, con 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 un lavador de archivos y el cliente vSphere no se adhiere al host. En general, no se pudo identificar ningún sistema. Podrían ocurrir heladas durante el día con una carga baja. Podrían hacerlo de noche sin carga. Podría por la noche durante el respaldo diferencial y la carga promedio. Podría los fines de semana durante copias de seguridad completas y carga alta. Y hubo una clara degradación de la situación. Al principio era una vez al año y luego cada seis meses. Al final de mi paciencia, dos veces por semana.
Tuve un problema de memoria. Pero no me dejaron detener el montón de basura ni siquiera los fines de semana y ejecutar Memtest. Estábamos esperando las vacaciones de mayo. Durante las vacaciones de mayo, ejecuté Memtest y... no se encontraron errores.
Me quedé asombrado y decidí irme de vacaciones. Mientras estaba de vacaciones, no hubo ni un solo problema en el basurero. Y cuando volví a trabajar el primer día el lunes, había un montón de basura. Soporté una copia de seguridad completa y colgué justo después de terminar. Una bienvenida tan cálida de las vacaciones me impulsó a tomar la decisión de arrastrar físicamente los discos con la máquina invitada a otro host.
Y, aunque ya se sabe desde hace tiempo que no se puede hacer nada serio el primer día después de las vacaciones, aunque me estaba preparando para no trabajar durante todo el camino hasta el trabajo, mi indignación por el nuevo congelamiento me desanimó y me hizo sentir mal. votos fuera de mi cabeza...
Los discos físicos se han movido a otro host. Conexión caliente. En la configuración de almacenamiento en la pestaña Unidades Aparecen los discos. en la pestaña Almacenes de datos No hay almacenamiento en estos discos. Refrescar - no aparece. Bueno, por supuesto, el primer impulso. Agregar almacenamiento. El Asistente para agregar explica lo que admite. Por supuesto, también es compatible con VMFS. No lo dudé. Un vistazo rápido a los mensajes del asistente en cada paso: Siguiente, Siguiente, Siguiente, Finalizar. La vista ni siquiera estuvo cerca de captar el pequeño círculo amarillo con un signo de exclamación en la parte inferior de la ventana de uno de los escalones del maestro.
Al final del asistente, apareció en la lista el almacén de datos nuevo... y junto con él los almacenes de datos de los discos físicos restantes.
Continúo navegando por el almacén de datos recién agregado y está... vacío. Por supuesto, volví a caer en el asombro. Son las 8 de la mañana, los primeros 15 minutos en el trabajo después de las vacaciones, todavía ni siquiera le he removido el azúcar al café. Y aquí está. Lo primero que pensé fue que extraje el disco equivocado del host "nativo". Miré para ver si el almacén de datos requerido estaba presente en el host "nativo": no, no estaba presente. El segundo pensamiento fue: "¡joder!" No estoy seguro, pero me parece que el tercer, cuarto y al menos el quinto pensamiento fue el mismo.
Para disipar dudas, instalé rápidamente un ESXi nuevo para realizar pruebas, tomé el disco izquierdo y, después de leerlo, seguí los pasos del asistente. Sí. Cuando agrega un almacén de datos mediante el asistente, todos los datos del disco se pierden sin la posibilidad de revertir la operación y restaurar los datos. Más tarde leí en uno de los foros una valoración de este diseño hecha por un maestro: una mierda de mierda. Y realmente estuve de acuerdo.
A partir del sexto, los pensamientos fluyeron en una dirección más constructiva. DE ACUERDO. La inicialización tarda unos segundos incluso en un disco de 3 TB. Entonces este es un formateo de alto nivel. Esto significa que la tabla de particiones simplemente se reescribió. Entonces los datos todavía están ahí. Entonces, ahora buscaremos algún formato y listo.
Arranco la máquina desde la imagen de arranque de Strelec... Y descubro que los programas de recuperación de particiones lo saben todo excepto VMFS. Por ejemplo, conocen el diseño de partición de Synology, pero no VMFS.
Buscar entre programas no es tranquilizador: en el mejor de los casos, GetDataBack y R.Saver encuentran particiones NTFS con una estructura de directorios en vivo y nombres de archivos en vivo. Pero esto no me conviene. Necesito dos archivos vmdk: con el disco del sistema y el disco de la papelera.
Y luego entiendo que parece que ahora instalaré Windows y lo implementaré desde una 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 departamentales que es absolutamente salvaje en alcance y ramificaciones. No es una opción. La única opción aceptable en el tiempo es restaurar el estado del sistema y del disco con datos y todos los derechos.
Nuevamente Google, foros, KB'shki y nuevamente el llanto de Yaroslavna: VMware ESXi no proporciona un mecanismo de recuperación de datos. Todos los hilos de discusión tienen dos finales: alguien fue recuperado utilizando el costoso DiskInternals VMFS Recovery, o alguien recibió ayuda de un especialista en software que promociona activamente sus servicios. vmfs-herramientas и dd. La opción de comprar una licencia de DiskInternals VMFS Recovery por $700 no es una opción. Permitir que un extraño del “territorio de un enemigo potencial” acceda a los datos corporativos tampoco es una opción. Pero se buscó en Google que UFS Explorer también puede leer las particiones VMFS.
Recuperación de DiskInternals VMFS
La versión de prueba fue descargada e instalada. El programa vio con éxito la partición VMFS vacía:
el modo de 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 vivos:
El montaje de la partición en el sistema fue exitoso, pero por alguna razón desconocida, las tres carpetas contenían la misma máquina virtual. Por supuesto, según la ley, la mezquindad no es lo que se requiere.
Tres líneas de vergüenzaEl intento de bloquear descaradamente el software terminó en un fracaso. Pero UFS Explorer se bloqueó.
Tengo una actitud extremadamente negativa hacia el robo de software. De ninguna manera aliento el uso de medios para eludir la protección contra el uso no autorizado.
Me encontraba en una situación catastrófica y no estaba nada orgulloso de las medidas a las que había recurrido.
Explorador de UFS
Una exploración del disco mostró la presencia de 7 nodos. La cantidad de nodos coincidió “sorprendentemente” con la cantidad de archivos *-flat.vmdk detectados por VMFS Recovery:
Una comparación de tamaños de archivos y tamaños de nodos 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, los discos vmdk desde el punto de vista de ESXi constan de dos archivos: un archivo de datos (<nombre de la máquina>-flat.vmdk) y un archivo de diseño de disco "físico" (<nombre de la máquina>.vmdk). Si carga un archivo *-flat.vmdk al almacén de datos desde una máquina local, ESXi no lo reconocerá como un archivo de disco válido. La base de conocimientos de VMware tiene un artículo sobre cómo crear manualmente un archivo descriptor de disco: , pero no tuve que hacer esto, simplemente copié el contenido de los archivos correspondientes desde el área de vista previa del contenido del archivo en DiskInternals VMFS Recovery:
Después de 4 horas de descargar un nodo de 2,5 TB de UFS Explorer y 20 horas de carga en el almacén de datos del hipervisor, los archivos del disco bloqueado se conectaron a la máquina virtual recién creada. Los discos recogieron. No se observó pérdida de datos.
Fuente: habr.com