Восстановление файловой системы LVM
Да, посмотрите, например, как загрузить VM с FS хоста:
Добавьте модули на 9 пунктов к хосту initramfs (это - самый легкий путь хотя не самое чистое, чтобы иметь initrd с необходимыми модулями):
printf '%s\n' 9p 9pnet 9pnet_virtio | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u
qemu -kernel "/boot/vmlinuz-$(uname -r)" \
-initrd "/boot/initrd.img-$(uname -r)" \
-fsdev local,id=r,path=/,security_model=none \
-device virtio-9p-pci,fsdev=r,mount_tag=r \
-nographic \
-append 'root=r ro rootfstype=9p rootflags=trans=virtio console=ttyS0 init=/bin/sh'
При выполнении его как обычный пользователь существуют файлы, к которым это не сможет получить доступ, но необходимо смочь получить приглашение оболочки, и это не нанесет ущерба:
[ 0.000000] Linux version 3.10-3-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.3 (Debian 4.7.3-7) ) #1 SMP Debian 3.10.11-1 (2013-09-10)
[ 0.000000] Command line: root=r rootfstype=9p rootflags=trans=virtio console=ttyS0 init=/bin/sh
[...]
Loading, please wait...
[ 0.564122] systemd-udevd[52]: starting version 204
[...]
Begin: Loading essential drivers ... [ 1.007951] FS-Cache: Loaded
[ 1.009958] 9p: Installing v9fs 9p2000 file system support
[ 1.012880] FS-Cache: Netfs '9p' registered for caching
done.
Begin: Running /scripts/init-premount ... done.
[...]
sh-4.2# ls /
bin home lib32 media opt safe tmp vmlinuz.old
boot initrd.img lib64 mnt proc sbin usr
dev initrd.img.old libx32 old root srv var
etc lib lost+found old-tmp run sys vmlinuz
sh-4.2# poweroff -f
[ 56.958724] ACPI: Preparing to enter system sleep state S5
[ 56.960332] Power down.
Вы не можете исправить LVM, увеличив размер до исходного размера, если только вам не повезло и LV не имел никакой фрагментации из-за предыдущих изменений размера. Скорее всего, новый LV будет иметь первые 20G или около того вашей исходной файловой системы, но оставшиеся 780G (или что-то еще) представляют собой яичницу-болтунью (неправильные данные, неправильное смещение, неправильный порядок).
И это при условии, что вы используете жесткий диск. Если бы это был SSD, с issue_discards = 1 в вашем lvm.conf , данные просто исчезли бы, поэтому я никогда не использую эту опцию.
Вы должны проверить / etc / lvm / {archive, backup} / на наличие старых версий ваших метаданных. В каждом файле указано, когда он был создан, например:
description = "Created *before* executing 'lvremove HDD/mdtest1'"
Вы ищете тот, который говорит Создан до lvresize 850 с отсутствующим G . А затем vgcfgrestore метаданные LVM с использованием этой резервной копии, и, надеюсь, тогда они вернутся в рабочее состояние.
Если у вас нет таких файлов в / etc / lvm , либо из-за того, что вы сделали это с Live CD, на котором эти данные были потеряны, либо из-за повреждения корневого LV, все становится немного сложнее сложно, поскольку вы должны надеяться, что метаданные LVM на диске будут содержать этот бит истории в своем кольцевом буфере.
Примерный способ увидеть, что там, возможно, находится:
dd if=/dev/pvdevice bs=1M count=1 | strings -w -n 16
Если бы вы не сдули старый ext4, возможно, была бы некоторая надежда на то, что fsck сделает некоторые исправления и найдет некоторые неповрежденные структуры каталогов.
На самом деле, возможно, все еще есть надежда на это, используя альтернативный суперблок, который был в той части диска, которую вы не испортили с mkfs. Или, если ваша старая FS имела другое количество резервных суперблоков, чем ваша текущая пустая FS, возможно, есть некоторые из них, которые не были перезаписаны.
e2fsck -b some-offset
Это применимо только в том случае, если ваша LV отображена на те же самые байты, что и старая (о которой говорил Фростшульц в своем ответе).
Можно восстановить несколько типов файлов, которые можно выбрать из бинарного потока. (Так как у вас нет метаданных, сопоставляющих имена файлов с диапазонами байт.) Некоторые файлы имеют распознаваемый заголовок, и можно определить, где находится конец файла. Пока ваши файлы фрагментированы, есть некоторая надежда на восстановление некоторых безымянных файлов.
Foremost - инструмент для этого. Он утверждает, что находит jpg, gif, png, bmp, avi, exe, mpg, wav, riff, wmv, mov, pdf, ole, doc, zip, rar, htm и cpp файлы.