從已刪除的 Proxmox VM 中恢復 MySQL 表

擁有獨立的 Proxmox 節點，其中包含 LVM Thin 和 VM 130 卷 /dev/pve/vm-130-disk-0。VM 130 被意外刪除。Mysql 數據庫隨 VM 失去。在我們發現它一天后，該節點上的所有虛擬機都已停止以防止寫入 /dev/pve。新備份也被刪除，沒有恢復的機會。刪除後沒有創建新的虛擬機。

如何從失去的捲（以前稱為 /dev/pve/vm-130-disk-0）中恢復數據庫表？

我嘗試過的（沒有運氣）：

1. 將 vm130 上的 LVM 元數據回滾到刪除時刻。由於命令“lvs”的輸出，我可以看到卷 /dev/pve/vm-130-disk-0，但它處於非活動狀態並且無法啟動，因為出現錯誤：device-mapper: reload ioctl on (253:7) failed ：沒有可用數據恢復時我被迫使用“lvconvert –repair”損壞了LVM，就像這裡https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201 連結的解決方法有助於啟動pve/數據，但不是 /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”搜尋整個磁碟 /dev/sda3 來恢復 mysql 表。為不同的數據庫獲得了 12 GB 的頁面，包括我正在尋找的數據庫。但是字典/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\0std\n\0\0!\0!\0 !\0database_name\0INSERT INTO tbl_log_\n SET log_id " 5643947289462206311 NULL NULL 1600742439 "” 741488441

此外，使用這些巨大的表 ID，dictionary/SYS_INDEXES.sql 什麼也找不到。很好的方法在這裡的第一個答案：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

我將不勝感激任何建議和想法。謝謝！

使用“undrop-for-innodb”搜尋整個磁碟 /dev/sda3 來恢復 mysql 表。為不同的數據庫獲得了 12 GB 的頁面，包括我正在尋找的數據庫。但是字典/SYS_TABLES.sql 會產生巨大的表 ID，例如 5643947289462206311 和奇怪的符號 \0！在表名中：

您需要SYS_TABLES/SYS_INDEXES按表名查找索引。看起來您的 SYS_* 已損壞（或者可能stream_parser錯誤地找到了不屬於的頁面）。

所以，沒有 SYS_* 表，但希望你的數據在這 12G 的頁面中的某個地方。該怎麼辦？試試grep。例如，如果您知道一個表必須有一個字元串foo@bar.com，請嘗試查找包含它的索引，然後檢查c_parser它是否真的是您要查找的表。

這是一個非常手動、複雜且耗時的過程。我會嘗試以其他方式恢復數據庫，然後在事後檢查您的備份過程。

引用自：https://serverfault.com/questions/1000278