☰

MySQL-Tabellen von entfernter Proxmox-VM wiederherstellen

tag-icon • tag-icon mysql lvm ext4 data-recovery
MySQL-Tabellen von entfernter Proxmox-VM wiederherstellen

Habe den eigenständigen Proxmox-Knoten mit LVM Thin und VM 130-Volume /dev/pve/vm-130-disk-0 darin. VM 130 wurde versehentlich gelöscht. Die Mysql-Datenbank ging mit der VM verloren. Nachdem wir es an einem Tag entdeckt hatten, wurden alle VMs auf diesem Knoten gestoppt, um das Schreiben auf /dev/pve zu verhindern. Das neue Backup wurde ebenfalls gelöscht, ohne Chance auf Wiederherstellung. Nach dem Löschen wurden keine neuen VMs erstellt.

Wie kann ich Datenbanktabellen von einem verlorenen Volume (früher bekannt als /dev/pve/vm-130-disk-0) wiederherstellen?

Was ich versucht habe (ohne Erfolg):

  1. Rollback der LVM-Metadaten auf vm130 bis zum Löschzeitpunkt. Als Ergebnis der Ausgabe des Befehls „lvs“ kann ich das Volume /dev/pve/vm-130-disk-0 sehen, aber es ist inaktiv und kann aufgrund eines Fehlers nicht aktiviert werden: device-mapper: reload ioctl on (253:7) failed: No data available Beim Wiederherstellen war ich gezwungen, „lvconvert --repair“ zu verwenden, was LVM wie hier beschädigt hat.https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 Der Workaround vom Link hilft beim Aktivieren von pve/data, aber nicht von /dev/pve/vm-130-disk-0.

  2. Testdisk zum Suchen von VM-Partitionen auf der physischen Festplatte /dev/sda3. Es wurden 18 Partitionen gefunden, aber niemand kannte Testzeichenfolgen von VM 103. Getestet mit bgrep. Beachten Sie, dass diese Partitionen nicht die gesamte physische Festplatte abdecken.

  3. Suche mit bgrep über /dev/sda3-Textzeichenfolgen von VM 130. Zeichenfolgen wurden an zwei verschiedenen Stellen auf der Festplatte außerhalb der von Testdisk ermittelten VM-Partitionen gefunden.

  4. Wiederherstellung von MySQL-Tabellen mit „undrop-for-innodb“, Suche auf der gesamten Festplatte /dev/sda3. Habe 12 GB große Seiten für verschiedene Datenbanken, einschließlich der von mir gesuchten Datenbank. Aber dictionary/SYS_TABLES.sql erzeugt riesige Tabellen-IDs wie 5643947289462206311 und seltsame Symbole \0! im Tabellennamen:

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

    Außerdem kann dictionary/SYS_INDEXES.sql mit diesen riesigen Tabellen-IDs nichts finden. Gute Anleitung in der ersten Antwort hier:https://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database

In /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

Proxmox-Details:

# 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

Ich bin für jeden Rat und jede Idee dankbar. Danke!

Antwort1

Wiederherstellung von MySQL-Tabellen mit „undrop-for-innodb“, Suche auf der gesamten Festplatte /dev/sda3. Habe 12 GB große Seiten für verschiedene Datenbanken, einschließlich der von mir gesuchten Datenbank. Aber dictionary/SYS_TABLES.sql erzeugt riesige Tabellen-IDs wie 5643947289462206311 und seltsame Symbole \0! im Tabellennamen:

Sie müssen SYS_TABLES/ verwenden SYS_INDEXES, um den Index nach Tabellennamen zu finden. Es sieht so aus, als ob Ihr SYS_* beschädigt ist (oder vielleicht stream_parserversehentlich Seiten gefunden hat, die nicht dazugehören).

Also keine SYS_*-Tabellen, aber hoffentlich sind Ihre Daten irgendwo auf diesen 12 GB großen Seiten. Was tun? Versuchen Sie es mit grep. Wenn Sie beispielsweise wissen, dass eine Tabelle eine Zeichenfolge enthalten muss, [email protected]versuchen Sie, Indizes zu finden, die diese enthalten, und prüfen Sie dann mit , c_parserob es sich wirklich um die Tabelle handelt, nach der Sie suchen.

Es ist ein sehr manueller, komplizierter und zeitaufwändiger Prozess. Ich würde versuchen, die Datenbank auf andere Weise wiederherzustellen und dann Ihren Backup-Prozess in einer Post-Mortem-Analyse zu überprüfen.

Antwort2

Ich denke, Sie sollten zuerst LVM wiederherstellen. Und erst dann darüber nachdenken, wie Sie die MySQL-Datenbankdatei im Dateisystem wiederherstellen.

Ähnliche Frage: Gibt es eine Möglichkeit, Ext4-Dateisysteme von einem gelöschten logischen LVM-Volume wiederherzustellen?

verwandte Informationen