Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Файловые системы, диски / Linux)
Изначальное сообщение		[ Отслеживать ]

"Достать mysql-базу из удаленной VM Proxmox"	+1 +/–
Сообщение от brt (ok), 24-Янв-20, 16:04
Есть отдельно стоящая нода 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 available 2. Искать 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 Буду благодарен за любые советы и идеи. Спасибо!
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Достать mysql-базу из удаленной VM Proxmox"	+/–
Сообщение от ACCA (ok), 28-Янв-20, 20:46
Что значит "при активации /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:". То есть ты можешь каким-то образом примонтировать этот диск?
Ответить | Правка | Наверх | Cообщить модератору

	2. "Достать mysql-базу из удаленной VM Proxmox"	+/–
	Сообщение от brt (ok), 29-Янв-20, 15:24
	Прошу прощения за сумбурность - от объема задачи уже каша в голове. > 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.
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Достать mysql-базу из удаленной VM Proxmox"	+/–
	Сообщение от ACCA (ok), 29-Янв-20, 22:07
	Посмотри здесь - https://blog.monotok.org/lvm-transaction-id-mismatch-and-met.../
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Достать mysql-базу из удаленной VM Proxmox"	+/–
	Сообщение от brt (ok), 31-Янв-20, 21:03
	Ещё раз спасибо за подсказку! Для 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 в данном случае невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема