https://slinkov.ru/openforum/vsluhforumID1/97520.html Есть отдельно стоящая нода Proxmox с LVM thin и диском виртуальной машины 130 - /dev/pve/vm-130-disk-0.<br>VM удалили, через сутки обнаружили это и остановили остальные VM, чтобы не писали в /dev/pve.<br>Как водится, внутри VM - mysql и очень нужная база данных.<br>Актуального бекапа VM и базы mysql нет.<br><br>Подскажите, как найти и восстановить базу mysql?<br><br><br>Что пробовал без успеха:<br><br>1. Восстановить состояние метаданных LVM на момент до удаления VM, в итоге lvs стал показывать искомый volume /dev/pve/vm-130-disk-0, в неактивном состоянии.<br> В процессе восстановления пришлось использовать lvconvert --repair, который сломал LVM _https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1625201<br> Предложенные workaround с пересозданием tmeta не помогает, при активации /dev/pve/vm-130-disk-0 возникает ошибка:<br> device-mapper: reload ioctl on (253:7) failed: No data available<br><br>2. Искать testdisk-ом по физическому диску /dev/sda3 начала root-партиции внутри VM. Найденые 18 партиций не содержат известных текстовых ф https://slinkov.ru/openforum/vsluhforumID1/97520.html#4 Fri, 31 Jan 2020 18:03:46 GMT Ещё раз спасибо за подсказку!<br><br>Для Thin volumes в архивных файлах /etc/lvm/archive/*.vg нет physical extents, а есть только device_ids. Сопоставление между device_id и physical extents на блочном устройстве хранится в метаданных LVM и может быть выгружено из неактивного пула:<br><br>vgimport pve<br>lvchange --yes -ay pve/data_tmeta<br>thin_dump /dev/mapper/pve-data_tmeta -o thin_dump_pve-data_tmeta.xml<br>lvchange -an pve/data_tmeta<br><br>Т.к. lvremove вместе с thin volume заодно удаляет это сопоставление, то восстановление volume в данном случае невозможно.<br> https://slinkov.ru/openforum/vsluhforumID1/97520.html#3 Wed, 29 Jan 2020 19:07:41 GMT Посмотри здесь - https://blog.monotok.org/lvm-transaction-id-mismatch-and-metadata-resize-error/<br> https://slinkov.ru/openforum/vsluhforumID1/97520.html#2 Wed, 29 Jan 2020 12:24:39 GMT Прошу прощения за сумбурность - от объема задачи уже каша в голове.<br><br>&gt; thin-provisioning-tools поновее<br><br>Спасибо, почему-то мне в голову не пришло.<br><br>Под активацией имеется ввиду: # lvchange -ay /dev/pve/vm-130-disk-0<br>С порчей meta удалось разобраться - возникало из-за того что device mapper не всегда отключал meta автоматически.<br>Про reload ioctl on (253:7) failed: No data available - чуть ниже.<br><br><br>Итого, вопрос по LVM можно сузить до следующего:<br><br>Восстановление метаданных LVM до момента удаления 130 и активация:<br># vgcfgrestore --force --file /etc/lvm/archive/pve_00336-2034680334.vg pve<br># vgimport pve<br># lvchange -ay /dev/pve/vm-130-disk-0 # LVM самостоятельно активирует все зависимости, если сможет:<br> Thin pool pve-data-tpool (254:6) transaction_id is 324, while expected 311.<br><br># lvs -a<br> LV VG Attr LSize Pool Origin Data% Meta%<br> data pve twi---tz-- 1.57t https://slinkov.ru/openforum/vsluhforumID1/97520.html#1 Tue, 28 Jan 2020 17:46:30 GMT Что значит "при активации /dev/pve/vm-130-disk-0" ?<br><br>Там несколько шагов в workaround:<br><br> thin_dump /dev/mapper/vg02-pool0_tmeta &gt; lvm_meta_dum<br> lvcreate -n pool0meta2 -L 12G vg02<br> thin_restore -i lvm_meta_dump -o /dev/mapper/vg02-pool0meta2<br> lvconvert --thinpool vg02/pool0 --poolmetadata vg02/pool0meta2<br><br><br>Подозрительно выглядит<br> device-mapper: reload ioctl on (253:7) failed: No data available<br><br>Похоже на баг https://bugzilla.redhat.com/show_bug.cgi?id=1512854<br>Намекают, что есть thin-provisioning-tools поновее.<br><br>Непонятно, откуда взялось "Внутри /dev/pve/vm-130-disk-0:". То есть ты можешь каким-то образом примонтировать этот диск?<br>