Есть отдельно стоящая нода Proxmox с LVM thin и диском виртуальной машины 130 - /dev/pve/vm-130-disk-0.
VM удалили, через сутки обнаружили это и остановили остальные VM, чтобы не писали в /dev/pve.
Как водится, внутри VM - mysql и очень нужная база данных.
Актуального бекапа VM и базы mysql нет.Подскажите, как найти и восстановить базу mysql?
Что пробовал без успеха:1. Восстановить состояние метаданных LVM на момент до удаления VM, в итоге lvs стал показывать искомый volume /dev/pve/vm-130-disk-0, в неактивном состоянии.
В процессе восстановления пришлось использовать lvconvert --repair, который сломал LVM _https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201
Предложенные workaround с пересозданием tmeta не помогает, при активации /dev/pve/vm-130-disk-0 возникает ошибка:
device-mapper: reload ioctl on (253:7) failed: No data available2. Искать testdisk-ом по физическому диску /dev/sda3 начала root-партиции внутри VM. Найденые 18 партиций не содержат известных текстовых фрагментов из VM 130.
3. Искать bgrep по всему физическому диску /dev/sda3 текстовые фрагменты из VM 130. Фрагменты обнаруживаются в двух местах физического диска,
возможно VM восстанавливали несколько раз. Всё найденное за границами партиций найденных testdisk.
4. Восстанавливать только таблицы undrop-for-innodb поиском по диску /dev/sda3. Выгрузилось 12 GB страниц разных mysql-баз, включая искомую, но сильно смущает как гигантские номера таблиц при использовании dictionary/SYS_TABLES.sql и как то, что dictionary/SYS_INDEXES.sql ничего по этим номерам не находит, так и общий формат вывода утилиты:
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
заметно отличающийся от варианта разработчика из первого ответа здесь:
_https://dba.stackexchange.com/questions/23251/is-there-a-way-to-recover-a-dropped-mysql-database
Внутри /dev/pve/vm-130-disk-0:
# dpkg -l |grep mysql-server-
mysql-server-5.5 5.5.47-0+deb8u1 amd64
# 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
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
Буду благодарен за любые советы и идеи.
Спасибо!
Что значит "при активации /dev/pve/vm-130-disk-0" ?Там несколько шагов в workaround:
thin_dump /dev/mapper/vg02-pool0_tmeta > lvm_meta_dum
lvcreate -n pool0meta2 -L 12G vg02
thin_restore -i lvm_meta_dump -o /dev/mapper/vg02-pool0meta2
lvconvert --thinpool vg02/pool0 --poolmetadata vg02/pool0meta2
Подозрительно выглядит
device-mapper: reload ioctl on (253:7) failed: No data availableПохоже на баг https://bugzilla.redhat.com/show_bug.cgi?id=1512854
Намекают, что есть thin-provisioning-tools поновее.Непонятно, откуда взялось "Внутри /dev/pve/vm-130-disk-0:". То есть ты можешь каким-то образом примонтировать этот диск?
Прошу прощения за сумбурность - от объема задачи уже каша в голове.> thin-provisioning-tools поновее
Спасибо, почему-то мне в голову не пришло.
Под активацией имеется ввиду: # lvchange -ay /dev/pve/vm-130-disk-0
С порчей meta удалось разобраться - возникало из-за того что device mapper не всегда отключал meta автоматически.
Про reload ioctl on (253:7) failed: No data available - чуть ниже.
Итого, вопрос по LVM можно сузить до следующего:Восстановление метаданных LVM до момента удаления 130 и активация:
# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0 # LVM самостоятельно активирует все зависимости, если сможет:
Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311.# lvs -a
LV VG Attr LSize Pool Origin Data% Meta%
data pve twi---tz-- 1.57t
[data_tdata] pve Twi-a----- 1.57t
[data_tmeta] pve ewi-a----- 16.00g
root pve -wi-a----- 10.00g
vm-130-disk-0 pve Vwi---tz-- 32.00g data
vm-137-disk-0 pve Vwi---tz-- 22.00g dataЕсли вручную изменить transaction_id с 311 на 324 в /etc/lvm/archive/pve_00336-2034680334.vg
и повторить восстановление, то активируется и pool data и неудалённая vm-137-disk-0, но удалённая vm-130-disk-0 не активируется:# vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve
# vgimport pve
# lvchange -ay /dev/pve/vm-130-disk-0 # LVM самостоятельно активирует все зависимости, если сможет:
device-mapper: reload ioctl on (254:19) failed: No data available
При этом в debug: pve-vm--130--disk--0: Skipping NODE_DEL [trust_udev]# lvs -a
LV VG Attr LSize Pool Origin Data% Meta%
data pve twi-aotz-- 1.57t 5.86 0.44
[data_tdata] pve Twi-a----- 1.57t
[data_tmeta] pve ewi-a----- 16.00g
root pve -wi-a----- 10.00g
vm-130-disk-0 pve Vwi---tz-- 32.00g data
vm-137-disk-0 pve Vwi-a-tz-- 22.00g data 67.91Похоже, чтобы увидеть список volumes по lvs нужна корректная transaction_id в meta - 311.
А для активации volume нужна корректная transaction_id в data-tpool, где сейчас 324.Т.о вопрос сводится к:
Как исправить Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311 ?
Все найденные в Интернет решения сводятся к "измените transaction_id в lvm backup и выполните vgcfgrestore",
но у людей зеркальная ситуация: у них в data-tpool меньшая версия чем в meta.
Посмотри здесь - https://blog.monotok.org/lvm-transaction-id-mismatch-and-met.../
Ещё раз спасибо за подсказку!Для Thin volumes в архивных файлах /etc/lvm/archive/*.vg нет physical extents, а есть только device_ids. Сопоставление между device_id и physical extents на блочном устройстве хранится в метаданных LVM и может быть выгружено из неактивного пула:
vgimport pve
lvchange --yes -ay pve/data_tmeta
thin_dump /dev/mapper/pve-data_tmeta -o thin_dump_pve-data_tmeta.xml
lvchange -an pve/data_tmetaТ.к. lvremove вместе с thin volume заодно удаляет это сопоставление, то восстановление volume в данном случае невозможно.