Восстановление удаленных файлов из образа виртуального диска
Окончательный результат :После сеанса удаленной отладки в чате, включая отключение питания его вращающегося жесткого диска, стало ясно, что вращается не его жесткий диск, а вентилятор его карты nvidia.
Проблема была решена после установки драйвера nVidia .
Расширение :jbd2 означает фоновую задачу на основе ядра -, выполняющую побочную -работу с одной из ваших linux файловых систем, она, конечно же, ничего не делает с вашими разделами win. Подробнее об этом можно прочитать здесь .
Это явно экстраординарный случай -если вы не используете Ubuntu, она не должна вращать ваш диск. Есть какой-то фоновый процесс, который может и не нужен (или нужен, но тогда хороший вопрос, что он делает ).
Однако, к счастью, есть как простой, так и более сложный способ решения этой проблемы.
- Процессы, выполняющие -интенсивные операции ввода-вывода, обычно находятся на
top. Итак, введите:topи проверьте, что находится сверху. Найдите процессы, имеющие состояниеR(=running )в столбцеS(tate ). Также вы можете использоватьps uxa|grep Rкак решение чисто командной строки -для той же задачи. Хотяtopупорядочивает процессы по их использованию процессора , а не по их операциям ввода-вывода , в большинстве случаев также процессы с интенсивным вводом-выводом выходят на первое место в списке.top, как побочный -эффект. - Существует инструмент с именем blkiomon . Его параметризация крайне не -тривиальна, но с его помощью вы можете получить гораздо более точную информацию о том, кто крутит ваши диски и почему.
Наиболее вероятными причинами вашей проблемы являются следующие:
- Какой-то веб-сайт творит гадости на редко посещаемой вкладке Chrome.
- У вас не слишком много оперативной памяти, и вы используете какое-то приложение, которое использует много. В таком случае,причина крутится своп.
- Если это ваш Chrome (, что может быть также из-за того, что (1 )), вы можете рассмотреть возможность перехода на Firefox с отключенным электролизом . Это самый быстрый способ иметь полезный браузер с небольшим объемом оперативной памяти. Типичная потребность в оперативной памяти -для e10s -бесплатного 32-разрядного -firefox составляет менее 1 ГБ.
К комментариям:
Какие разделы смонтированы и где, вы можете проверить с помощью команды mount. К сожалению, он наполнен дерьмом уже несколько лет, но до конца вы можете посмотреть список. Найдите такие строки:
/dev/sda7 on /media/archive type ext4 (rw,relatime,nobarrier,errors=remount-ro,commit=6935,data=ordered)
Это означает, что ваш /dev/sda7смонтирован в директорию /media/archive. Sda7 — это 7-й раздел вашего первого жесткого диска.
Расширение:Как видно из выходных данных fdisk, ваш SSD — это ваш/dev/sdb1.
Если кому-то нужно решение для файловой системы ext3/4. Вот. Проверьте таблицу fs
# fdisk -lu server.img
Disk server.img: 53.7 GB, 53687091200 bytes, 104857600 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
Disk label type: dos
Disk identifier: 0x000bef15
Device Boot Start End Blocks Id System
server.img1 * 2048 2099199 1048576 83 Linux
server.img2 2099200 104857599 51379200 8e Linux LVM
Целевой раздел начинается с сектора 2099200 Размер 512 *2099200 = 1074790400
# losetup -o 1074790400 /dev/loop0 server.img
# fsck -fv /dev/loop0
fsck from util-linux 2.23.2
# lvmdiskscan
/dev/loop0 [ 49.00 GiB] LVM physical volume
/dev/cl/root [ 430.71 GiB]
/dev/sda1 [ 1.00 GiB]
/dev/cl/swap [ 4.00 GiB]
/dev/sda2 [ 464.71 GiB] LVM physical volume
2 disks
1 partition
0 LVM physical volume whole disks
1 LVM physical volumes
Проверить группы томов.
# vgscan
Reading volume groups from cache.
Found volume group "cl" using metadata type lvm2
Found volume group "cl" using metadata type lvm2
# vgdisplay
--- Volume group ---
VG Name cl
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 3
Max PV 0
Cur PV 1
Act PV 1
VG Size 464.71 GiB
PE Size 4.00 MiB
Total PE 118965
Alloc PE / Size 118965 / 464.71 GiB
Free PE / Size 0 / 0
VG UUID qXzwwe-OLg7-Xm25-LImC-fBb9-ohLh-RMqtxn
--- Volume group ---
VG Name cl
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 49.00 GiB
PE Size 4.00 MiB
Total PE 12543
Alloc PE / Size 12543 / 49.00 GiB
Free PE / Size 0 / 0
VG UUID tMnvy0-3LWI-SWX3-SuHr-Cxfy-ueE7-7jeYZc
Наши группы томов имеют одинаковые имена. Переименуйте целевую группу томов.
# vgrename -v tMnvy0-3LWI-SWX3-SuHr-Cxfy-ueE7-7jeYZc cl_new
# vgscan
Reading volume groups from cache.
Found volume group "cl" using metadata type lvm2
Found volume group "cl_new" using metadata type lvm2
# lvscan
ACTIVE '/dev/cl/root' [430.71 GiB] inherit
ACTIVE '/dev/cl/home' [30.00 GiB] inherit
ACTIVE '/dev/cl/swap' [4.00 GiB] inherit
inactive '/dev/cl_new/root' [44.00 GiB] inherit
inactive '/dev/cl_new/swap' [5.00 GiB] inherit
Активировать логический том
# lvchange -ay /dev/cl_new/root
# lvscan
ACTIVE '/dev/cl/root' [430.71 GiB] inherit
ACTIVE '/dev/cl/home' [30.00 GiB] inherit
ACTIVE '/dev/cl/swap' [4.00 GiB] inherit
ACTIVE '/dev/cl_new/root' [44.00 GiB] inherit
inactive '/dev/cl_new/swap' [5.00 GiB] inherit
Используйте какой-либо инструмент для восстановления файла (extundelete, ext3magic, ext4magic и т. д.)
# extundelete /dev/cl_new/root --restore-all
Удачи! И не используйте rm -rf / с sudo:)
ПС. У меня есть XFS на моих виртуальных дисках, и это не удалось.
extundelete :Неверный магический номер в блоке super -при попытке открыть файловую систему /dev/cl _new/root