☰

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

tag-icon • tag-icon mysql lvm ext4 data-recovery
Восстановление таблиц MySQL из удаленной виртуальной машины Proxmox

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

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

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

  1. Откат метаданных LVM на vm130 на момент удаления. В результате вывода команды "lvs" я вижу том /dev/pve/vm-130-disk-0, но он неактивен и не может быть активирован из-за ошибки: device-mapper: reload ioctl on (253:7) failed: No data available При восстановлении мне пришлось использовать "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 разделов, но никто не знает тестовых строк из ВМ 103. Протестировано с помощью bgrep. Обратите внимание, что эти разделы не покрывают весь физический диск.

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

  4. Восстановление таблиц mysql с помощью 'undrop-for-innodb', просматривающего весь диск /dev/sda3. Получил 12 ГБ страниц для разных баз данных, включая DB, которую я ищу. Но dictionary/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\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/есть-ли-способ-восстановить-удаленную-базу-данных-MySQL

Внутри /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

Восстановление таблиц mysql с помощью 'undrop-for-innodb', просматривающего весь диск /dev/sda3. Получил 12 ГБ страниц для разных баз данных, включая DB, которую я ищу. Но dictionary/SYS_TABLES.sql выдает огромные идентификаторы таблиц, такие как 5643947289462206311 и странные символы \0! в имени таблицы:

Вам нужно SYS_TABLES/, SYS_INDEXESчтобы найти индекс по имени таблицы. Похоже, ваши SYS_* повреждены (или, возможно, stream_parserошибочно найдены страницы, которые не принадлежат).

Итак, таблиц SYS_* нет, но, надеюсь, ваши данные где-то на этих 12G страницах. Что делать? Попробуйте grep. Например, если вы знаете, что таблица должна иметь строку, [email protected]попробуйте найти индексы, которые ее содержат, а затем проверьте с помощью , c_parserдействительно ли это та таблица, которую вы ищете.

Это очень ручной, сложный и трудоемкий процесс. В противном случае я бы попытался восстановить базу данных, а затем рассмотрел бы ваш процесс резервного копирования в постмортеме.

решение2

Я думаю, сначала нужно восстановить LVM. А уже потом думать, как восстановить файл базы данных MySQL в файловой системе.

Похожий вопрос: Есть ли способ восстановить файловые системы ext4 с удаленного логического тома LVM?

Связанный контент