Восстановить таблицы MySQL с удаленной виртуальной машины Proxmox

Установите автономный узел Proxmox с тонким LVM и томом VM 130 / dev / pve / vm-130-disk-0 внутри него. ВМ 130 удалили случайно. База данных mysql была потеряна с виртуальной машиной. После того, как мы обнаружили это через день, все виртуальные машины на этом узле были остановлены, чтобы предотвратить запись в / dev / pve. Свежая резервная копия тоже была удалена без возможности восстановления. После удаления новые ВМ не создавались.

Как я могу восстановить таблицы базы данных из потерянного тома (ранее известного как / dev / pve / vm-130-disk-0)?

Что я пробовал (не повезло):

1. Откат метаданных LVM на vm130 до момента удаления. В результате в выводе команды "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 / data, но не / dev / pve / vm-130-disk-0.

2. testdisk для поиска разделов ВМ на физическом диске / dev / sda3. Было найдено 18 разделов, но никто не знал тестовых строк от VM 103. Проверено с помощью bgrep. Обратите внимание, что разделение на части охватывает не весь физический диск.

3. Поиск с помощью bgrep по текстовым строкам / dev / sda3 из VM 130. Строки найдены в двух разных местах на диске вне разделов VM, созданных testdisk.

4. Восстановление таблиц mysql с помощью undrop-for-innodb, поиск по всему диску / dev / sda3. Получил 12 ГБ страниц для разных баз данных, включая БД, которую я ищу. Но словарь / SYS_TABLES.sql создает огромные идентификаторы таблиц, например 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 NULL 1600742439" "741488441

   Кроме того, 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

Буду благодарен за любые советы и идеи. Спасибо!