☰

从已删除的 Proxmox VM 中恢复 MySQL 表

tag-icon • tag-icon mysql lvm ext4 data-recovery
从已删除的 Proxmox VM 中恢复 MySQL 表

拥有独立的 Proxmox 节点，其中有 LVM 精简版和 VM 130 卷 /dev/pve/vm-130-disk-0。VM 130 被意外删除。Mysql 数据库随 VM 丢失。我们在一天内发现它后，此节点上的所有 VM 都停止了，以预先写入 /dev/pve。新备份也被删除，没有恢复的机会。删除后没有创建新的 VM。

如何从丢失的卷（以前称为 /dev/pve/vm-130-disk-0）恢复数据库表？

我尝试过的（没有成功）：

  1. 将 vm130 上的 LVM 元数据回滚到删除时刻。根据命令“lvs”的输出，我可以看到卷 /dev/pve/vm-130-disk-0，但它处于非活动状态，无法激活，因为出现错误：device-mapper：重新加载 ioctl on (253:7) 失败：没有可用数据在恢复时，我被迫使用“lvconvert --repair”，这会损坏 LVM，如下所示https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 链接中的解决方法有助于激活 pve/data，但不能激活 /dev/pve/vm-130-disk-0。

  2. testdisk 在物理磁盘 /dev/sda3 上查找 VM 分区。找到了 18 个分区，但没有人知道 VM 103 的测试字符串。使用 bgrep 进行测试。请注意，这些分区不涵盖整个物理磁盘。

  3. 使用 bgrep 搜索 VM 130 中的 /dev/sda3 文本字符串。在 testdisk 创建的 VM 分区之外的磁盘上找到两个不同的字符串。

  4. 使用“undrop-for-innodb”恢复 mysql 表，搜索整个磁盘 /dev/sda3。获得不同数据库的 12 GB 页面，包括我正在寻找的 DB。但 dictionary/SYS_TABLES.sql 生成巨大的表 ID，如 5643947289462206311，并在表名中产生奇怪的符号 \0!：

    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!\0database_name\0INSERT INTO tbl_log_\n SET log_id “ 5643947289462206311 NULL NULL NULL 1600742439 “” 741488441

    此外，dictionary/SYS_INDEXES.sql 无法使用这些巨大的表 ID 找到任何内容。第一个答案中有很好的操作方法：https://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database

在 /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详细信息：

# 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

我将非常感激任何建议和想法。谢谢！

答案1

使用“undrop-for-innodb”恢复 mysql 表，搜索整个磁盘 /dev/sda3。获得不同数据库的 12 GB 页面，包括我正在寻找的 DB。但 dictionary/SYS_TABLES.sql 生成巨大的表 ID，如 5643947289462206311，并在表名中产生奇怪的符号 \0!：

您需要SYS_TABLES/SYS_INDEXES才能按表名查找索引。看来您的 SYS_* 已损坏（或者可能stream_parser错误地找到了不属于的页面）。

因此，没有 SYS_* 表，但希望您的数据在这些 12G 页面中的某个位置。该怎么办？试试grep。例如，如果您知道某个表必须有一个字符串，[email protected]请尝试查找包含该字符串的索引，然后检查c_parser它是否确实是您要查找的表。

这是一个非常手动、复杂且耗时的过程。否则，我会尝试恢复数据库，然后在事后检查备份过程。

答案2

我认为首先你应该恢复 LVM。然后再考虑如何在文件系统中恢复 mysql db 文件。

类似问题： 有没有办法从已删除的 LVM 逻辑卷恢复 ext4 文件系统？

相关内容