☰

Recupere tablas MySQL de la máquina virtual Proxmox eliminada

tag-icon • tag-icon mysql lvm ext4 data-recovery
Recupere tablas MySQL de la máquina virtual Proxmox eliminada

Tenga el nodo Proxmox independiente con LVM delgado y el volumen VM 130 /dev/pve/vm-130-disk-0 en su interior. La VM 130 se eliminó accidentalmente. La base de datos MySQL se perdió con la VM. Después de que lo descubrimos en un día, todas las máquinas virtuales en este nodo se detuvieron para evitar la escritura en /dev/pve. La copia de seguridad nueva también se eliminó sin posibilidad de recuperación. Después de eliminar, no se crearon nuevas máquinas virtuales.

¿Cómo puedo recuperar tablas de bases de datos de un volumen perdido (anteriormente conocido como /dev/pve/vm-130-disk-0)?

Lo que probé (sin suerte):

  1. Revertir los metadatos de LVM en vm130 hasta el momento de eliminación. Como resultado del resultado del comando "lvs", puedo ver el volumen /dev/pve/vm-130-disk-0, pero está inactivo y no se puede activar debido a un error: device-mapper: reload ioctl on (253:7) falló : No hay datos disponibles Durante la restauración me vi obligado a usar "lvconvert --repair" que dañó LVM como aquíhttps://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 La solución alternativa desde el enlace ayuda a activar pve/data, pero no /dev/pve/vm-130-disk-0.

  2. testdisk para encontrar particiones de VM en el disco físico /dev/sda3. Se encontraron 18 particiones, pero nadie conocía las cadenas de prueba de VM 103. Probado con bgrep. Tenga en cuenta que estas particiones no cubren todo el disco físico.

  3. Buscando con bgrep sobre cadenas de texto /dev/sda3 de VM 130. Cadenas encontradas en dos ubicaciones diferentes en el disco fuera de las particiones de VM fundadas por testdisk.

  4. Recuperación de tablas mysql con búsqueda 'undrop-for-innodb' en todo el disco /dev/sda3. Obtuve páginas de 12 GB para diferentes bases de datos, incluida la base de datos que estoy buscando. ¡Pero el diccionario/SYS_TABLES.sql produce ID de tabla enormes como 5643947289462206311 y símbolos extraños \0! en el nombre de la tabla:

    2020203D2020 4E414D455F434F SYS_TABLES "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0std\n\0\0!\0!\0 !\0database_name\0INSERT INTO tbl_log_\n SET log_id " 5643947289462206311 NULL NULL NULL 1600742439 "" 741488441

    Además, Dictionary/SYS_INDEXES.sql no puede encontrar nada utilizando estos ID de tabla enormes. Buen tutorial en la primera respuesta aquí:https://dba.stackexchange.com/questions/23251/hay-una-manera-de-recuperar-una-base-de-datos-mysql-caída

Dentro de /dev/pve/vm-130-disk-0:

# fdisk -l

     Disk /dev/sda: 32 GiB, 34359738368 bytes, 67108864 sectors
     Units: sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 512 bytes
     I/O size (minimum/optimal): 512 bytes / 512 bytes
     Disklabel type: dos
     Disk identifier: 0x65ab60ca

     Device     Boot    Start      End  Sectors  Size Id Type
     /dev/sda1  *        2048 64286719 64284672 30.7G 83 Linux
     /dev/sda2       64288766 67106815  2818050  1.4G  5 Extended
     /dev/sda5       64288768 67106815  2818048  1.4G 82 Linux swap / Solaris

     Above /dev/sda1 is ext4 with mysql database files.

mysql
     - mysql-server-5.5               5.5.47-0+deb8u1                  amd64
     - tables stored in innoDB format.
     - tables stored in separate files (my.cnf):
            innodb_file_per_table = 1
     - binary log forced enabled, but it rotated very othen:
            expire_logs_days    = 7

Detalles de Proxmox:

# uname -a
    Linux wz020 4.15.18-12-pve #1 SMP PVE 4.15.18-35 (Wed, 13 Mar 2019 08:24:42 +0100) x86_64 GNU/Linux
# pveversion
    pve-manager/5.4-3/0a6eaa62 (running kernel: 4.15.18-12-pve)
# pvs
    PV         VG  Fmt  Attr PSize PFree
    /dev/sda3  pve lvm2 a--  1.64t 6.00g
# vgs
    VG                           #PV #LV #SN Attr   VSize VFree
    pve                            1  26   0 wz--n- 1.64t 6.00g

Estaría agradecido por cualquier consejo e idea. ¡Gracias!

Respuesta1

Recuperación de tablas mysql con búsqueda 'undrop-for-innodb' en todo el disco /dev/sda3. Obtuve páginas de 12 GB para diferentes bases de datos, incluida la base de datos que estoy buscando. ¡Pero el diccionario/SYS_TABLES.sql produce ID de tabla enormes como 5643947289462206311 y símbolos extraños \0! en el nombre de la tabla:

Necesita SYS_TABLES/ SYS_INDEXESpara encontrar el índice por nombre de tabla. Parece que sus SYS_* están dañados (o tal vez stream_parserse encontraron por error páginas que no pertenecen).

Por lo tanto, no hay tablas SYS_*, pero es de esperar que sus datos se encuentren en algún lugar de estas páginas de 12 GB. ¿Qué hacer? Intentar grep. Por ejemplo, si sabe que una tabla debe tener una cadena, [email protected]intente encontrar índices que la contengan y luego verifique c_parsersi realmente es la tabla que está buscando.

Es un proceso muy manual, complicado y que requiere mucho tiempo. De lo contrario, intentaría recuperar la base de datos y luego revisaría el proceso de copia de seguridad en una autopsia.

Respuesta2

Creo que al principio deberías restaurar LVM. Y solo entonces piense en cómo restaurar el archivo db mysql en el sistema de archivos.

Pregunta similar: ¿Alguna forma de recuperar sistemas de archivos ext4 de un volumen lógico LVM eliminado?

información relacionada