Как восстановить зашифрованные данные на жестком диске с помощью System Rescue CD по локальной сети

Как восстановить зашифрованные данные на жестком диске с помощью System Rescue CD по локальной сети

Я хотел бы узнать, как лучше всего клонировать мой жесткий диск, чтобы я мог просто вставить клонированный диск в свой ПК и без проблем загрузиться с него, как я это делаю сейчас с существующим диском.

У меня есть жесткий диск с Debian, который, судя по данным SMART, выходит из строя. У меня есть резервные копии, и я могу переустановить ОС на новом диске; однако, на данный момент моим первым предпочтением было бы клонирование диска, и в настоящее время у меня нет другого выбора, кроме как использовать System Rescue CD 5.0.3 с загрузочного CD.

На диске не так уж много места — вероятно, менее 10 ГБ занятого пространства с очень небольшим количеством данных, поэтому меня не слишком волнует время, поскольку я не ожидаю, что это займет необычайно много времени.

Если я правильно помню, при установке Debian я настраивал его как зашифрованный диск, поэтому, как мне кажется, /dev/sda отображается как незашифрованный загрузочный раздел, а все остальное зашифровано, а в этом «остальном» у меня есть небольшой корневой раздел размером 10 ГБ внутри зашифрованной области, а остальное в настоящее время не используется.

Я также имею дело со старыми дисками PATA — нет доступных дисков SATA — а на материнской плате компьютера имеется один разъем PATA, к которому подключен ленточный кабель PATA с приводом CD-ROM для загрузки и почти вышедшим из строя жестким диском, поэтому нет места для подключения второго диска PATA для локального переноса данных.

Чтобы обойти эту проблему, у меня есть второй компьютер с таким же единственным разъемом PATA на материнской плате, к которому я подключил еще один привод CD-ROM для загрузки и целевой жесткий диск.

Я загрузил оба компьютера с привода CD-ROM, чтобы запустить System Rescue CD 5.0.3, и обдумываю варианты клонирования неисправного диска как можно лучше.

Компьютеры доступны по локальной сети, и я подключаюсь к обоим из них удаленно по SSH через терминал без графического интерфейса.

Я не совсем уверен в размерах исходного диска и целевого диска. Возможно, исходный диск имеет большую емкость, чем целевой диск, поэтому в идеале я хотел бы перенести только используемое пространство, а не проходить через весь пустой диск.

Я думал использовать ddrescue, как описаноздесь; однако он описывает только локальную передачу данных.

ОБНОВЛЯТЬ:Я смотрю, как установщик Debian настроил исходный диск. Похоже, у меня три раздела, и только последний из них зашифрован:

src # fdisk -l /dev/sda
Disk /dev/sda: 37.3 GiB, 40027029504 bytes, 78177792 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: 0x332e4146

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1  *       2048   247807   245760  120M 83 Linux
/dev/sda2        247808  8060927  7813120  3.7G 82 Linux swap / Solaris
/dev/sda3       8060928 78176255 70115328 33.4G 83 Linux

src# cryptsetup --verbose isLuks /dev/sda1 
Device /dev/sda1 is not a valid LUKS device.
Command failed with code 22: Invalid argument
src# cryptsetup --verbose isLuks /dev/sda2
Device /dev/sda2 is not a valid LUKS device.
Command failed with code 22: Invalid argument
src# cryptsetup --verbose isLuks /dev/sda3
Command successful.

Думаю, я также пытаюсь выполнить перенос между дисками одинаковой емкости: с диска PATA объемом 40 ГБ на другой диск PATA объемом 40 ГБ.

Вот пункт назначения:

dest# fdisk -l /dev/sda
Disk /dev/sda: 37.3 GiB, 40027029504 bytes, 78177792 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

ОБНОВЛЯТЬ:Я рассматриваю возможность использования NBD для предоставления доступа к разделам исходного диска по локальной сети, чтобы можно было использовать ddrescue с целевого диска.

Вот что я попробовал сделать, чтобы раскрыть исходный диск...

src# nbd-server -d 8000 /dev/sda

...и смонтировать локально на целевом компьютере:

dest# nbd-client src 8000 /mnt/nbd-sda

К сожалению, при попытке сделать это возникает ошибка; я даже не могу смонтировать удаленное устройство:

Warning: the oldstyle protocol is no longer supported.
This method now uses the newstyle protocol with a default export
Error: Cannot open NBD: No such file or directory
Please ensure the 'nbd' module is loaded.
Exiting.

ОБНОВЛЯТЬ:Следующее, что я попробую, — это просто вручную пересоздать разделы на целевом диске.

Я начал с копирования MBR:

src# dd if=/dev/sda of=/tmp/sda-mbr.dat bs=512 count=1
dest# scp root@src:/tmp/sda-mbr.dat /tmp
dest# dd if=/tmp/sda-mbr.dat of=/dev/sda
dest# sync

Прежде чем продолжить, я подумал, что на этот раз будет полезно хотя бы создать раздел восстановления.

dest# fdisk /dev/sda

Я удаляю последний раздел и выделяю себе около 15 ГБ места для последнего раздела.

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: 0x332e4146

Device     Boot    Start      End  Sectors  Size Id Type
/dev/sda1  *        2048   247807   245760  120M 83 Linux
/dev/sda2         247808  8060927  7813120  3.7G 82 Linux swap / Solaris
/dev/sda3        8060928 45809663 37748736   18G 83 Linux
/dev/sda4       45809664 78177791 32368128 15.4G 83 Linux

Мне нужно создать такой же зашифрованный раздел на целевом устройстве, как /dev/sda3 на исходном устройстве; я могу сделать то же самое для этого раздела восстановления:

dest# cryptsetup luksFormat /dev/sda3 --verify-passphrase
dest# cryptsetup luksFormat /dev/sda4 --verify-passphrase

Далее откройте зашифрованный раздел восстановления:

dest# cryptsetup open /dev/sda4 sda4-opened
dest# mkdir /mnt/sda4-open
dest# mke2fs -j /dev/mapper/sda4-opened
dest# mount /dev/mapper/sda4-opened /mnt/sda4-open

По крайней мере теперь я могу удаленно смонтировать этот раздел восстановления и перенести данные на лучший диск.

Сначала я открыл зашифрованный раздел на исходном диске:

src# cryptsetup open /dev/sda3 sda3-opened
src# mkdir /mnt/sda3-open
src# mount /dev/mapper/sda3-opened /mnt/sda3-open

Теперь с помощью df я вижу, что использую здесь только 12 ГБ дискового пространства.

Давайте размонтируем, но оставим его отображенным:

src# umount /mnt/sda3-open
src# rmdir /mnt/sda3-open

Теперь я хотел смонтировать раздел восстановления на исходном диске:

src# mkdir /mnt/dest-sda4
src# sshfs root@dest:/mnt/sda4-open /mnt/dest-sda4

После монтирования я могу запустить ddrescue:

src# ddrescue -f -n /dev/sda1 /mnt/dest-sda4/sda1.ddrescue.img /mnt/dest-sda4/sda1.ddrescue.log

В результате был создан образ того же размера, что и исходный раздел, так что, похоже, неиспользуемое пространство не исключается.

Я пытаюсьfsarchiverвместо этого сейчас:

src# fsarchiver savefs /mnt/dest-sda4/sda1.fsarchiver.img.fsa /dev/sda1
Statistics for filesystem 0
* files successfully processed:....regfiles=314, directories=6, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0

Монтирование /dev/sda1 и запуск df показывает, что он использует только 33 МБ, а файл .fsa занимает всего 24 МБ, так что, возможно, он сжат. Это лучше, чем исходные 120 МБ.

Теперь давайте попробуем с корневым разделом sda3, чтобы посмотреть, как это будет работать:

src# fsarchiver savefs /mnt/dest-sda4/sda3.fsarchiver.img.fsa /dev/mapper/sda3-opened

Это, вероятно, займет некоторое время, поэтому я пока приберегу это обновление.

ОБНОВЛЯТЬ:Это прошло быстрее, чем я ожидал. Вот что я в итоге получил:

dest# ls -lh
total 7.7G
drwx------ 2 root root  16K Apr  8 01:49 lost+found
-rw-r--r-- 1 root root  24M Apr  8 02:04 sda1.fsarchiver.img.fsa
-rw-r--r-- 1 root root 7.7G Apr  8 02:43 sda3.fsarchiver.img.fsa

А вот еще более интересная часть, если взглянуть на вывод команды выше:

src# fsarchiver savefs /mnt/dest-sda4/sda3.fsarchiver.img.fsa /dev/mapper/sda3-opened
Statistics for filesystem 0
* files successfully processed:....regfiles=149025, directories=84796, symlinks=20559, hardlinks=127551, specials=1269
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0

Если я правильно понял, это обнадеживает, поскольку никаких проблем со считыванием данных с исходного диска не возникло.

Давайте кое-что проясним:

src# umount /mnt/dest-sda4
src# rmdir /mnt/dest-sda4

Далее я восстанавливаю архивные файлы обратно на /dev/sda1 и /dev/sda3 целевого диска, но сначала давайте посмотрим, что у нас есть на целевом диске, потому что я забыл, на каком этапе остановился при настройке.

Во-первых, есть ли какая-либо файловая система на /dev/sda1?

dest# mkdir /mnt/sda1
dest# mount /dev/sda1 /mnt/sda1
NTFS signature is missing.
Failed to mount '/dev/sda1': Invalid argument
The device '/dev/sda1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Ок. Я не ожидал файловой системы, но и не ожидал сообщения NTFS. Так что там ничего нет.

Восстановим образ первого раздела:

dest# fsarchiver restfs /mnt/sda4-open/sda1.fsarchiver.img.fsa id=0,dest=/dev/sda1
Statistics for filesystem 0
* files successfully processed:....regfiles=314, directories=6, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0

Давайте теперь монтировать:

dest# mount /dev/sda1 /mnt/sda1
dest# ls -l /mnt/sda1
...
dest$ df -h | grep sda1
...

Пока что все выглядит хорошо.

Давайте теперь займемся корневым разделом.

dest# cryptsetup open /dev/sda3 sda3-opened
dest# mkdir /mnt/sda3-open
dest# mount /dev/mapper/sda3-opened /mnt/sda3-open
NTFS signature is missing.
Failed to mount '/dev/mapper/sda3-opened': Invalid argument
The device '/dev/mapper/sda3-opened' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

То же, что и раньше — там ничего нет.

Восстановим образ раздела:

dest# fsarchiver restfs /mnt/sda4-open/sda3.fsarchiver.img.fsa id=0,dest=/dev/mapper/sda3-opened
Statistics for filesystem 0
* files successfully processed:....regfiles=149025, directories=84796, symlinks=20559, hardlinks=127551, specials=1269
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0

Давайте теперь монтировать:

dest# mount /dev/mapper/sda3-opened /mnt/sda3-open
dest# ls -l /mnt/sda3
...
dest$ df -h | grep sda3
...

Пока что все выглядит хорошо.

Я также запустил следующее на обоих устройствах:

# fsarchiver probe simple

Все выглядит так, как и ожидалось.

Одна вещь, которую я все еще упускаю, это то, что, по-моему, это испортит Grub. Кажется, я припоминаю что-то о том, что Stage 1 нормально загружался из MBR, но затем он не смог найти Stage 2 на разделе /boot, когда я пытался сделать что-то подобное в последний раз.

Эта страницапривело кэтот, в котором описывается, как восстановить Grub:

dest# mount -o bind /proc /mnt/sda3-open/proc
dest# mount -o bind /dev /mnt/sda3-open/dev
dest# mount -o bind /sys /mnt/sda3-open/sys
dest# chroot /mnt/sda3-open /bin/bash
(dest) chroot# mount /dev/sda1 /boot/
(dest) chroot# grub-install /dev/sda

Installing for i386-pc platform.
Installation finished. No error reported.

(dest) chroot# umount /boot
(dest) chroot# exit
dest# umount /mnt/sda3-open/{sys,dev,proc}

После перезагрузки это должно сработать, и диск должен загрузиться правильно; однако сейчас уже поздно, и я пока не хочу этим заниматься.

Также я пока не уверен, что это будет иметь счастливый конец. Команда grub-install выше указала, что она устанавливает i386, но я думаю, что мне нужна 64-битная версия.

Мне, возможно, придется переделать эту часть, перезагрузив System Rescue CD через rescue64. Я не уверен, что загрузка по умолчанию запустила 32-битную версию.

Опять же, с остальным я разберусь завтра.

ОБНОВЛЯТЬ:Хорошей новостью является то, что загрузкой по умолчанию для System Rescue CD была программа rescue64, так что с этим не возникло бы никаких проблем.

Оказывается, я совсем забыл про LVM, и UUID дисков явно не совпадают.

...
cryptsetup: lvm is not available
cryptsetup: lvm is not available
cryptsetup: lvm is not available
cryptsetup: lvm is not available
  ALERT! /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx does not exist.
        Check cryptopts=source= bootarg: cat /proc/cmdline
        or missing modules, devices: cat /proc/modules; ls /dev
-r Dropping to a shell. Will skip /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxx
xxxxxxxx if you can't fix.
modprobe: module ehci-orion not found in modules.dep


BusyBox vx.xx.x (Debian x:x.xx.x-x+xxxxxx) built-in shell (ash)
Enter 'help for a list of built-in commands.

/bin/sh: can't access tty: job control turned off
(initramfs)

Думаю, я мог бы с этим бороться, но не буду. Вместо этого я попробую то, что предложил dirkt, и клонирую полный /dev/sda--UUID и все такое, поскольку 40 ГБ — это всего лишь четыре раза по 10 ГБ, которые я перенес вчера вечером и не заняли много времени по локальной сети.

Я не смог сделать это вчера вечером, потому что не смог заставить работать NBD, поэтому я прибегнул к сохранению в файлы изображений. Я не могу этого сделать, если я делаю полный клон диска, поэтому давайте посмотрим, что лучше работает: каналы или именованные каналы.

Итак, вернемся к началу: оба компьютера теперь загружены с загрузочного компакт-диска System Rescue CD, оба доступны по сети через соответствующие им назначенные DHCP IP-адреса, и на обоих компьютерах с помощью команды установлен пароль root passwd.

Прежде чем проделать это с настоящими дисками, я хочу попрактиковаться с крошечным поддельным, поэтому начну с его настройки.

src# dd if=/dev/zero of=/root/tempsrc.dat bs=1M count=128
...
src# fdisk -l /root/tempsrc.dat
Disk /root/tempsrc.dat: 128 MiB, 134217728 bytes, 262144 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: 0x8b8647e7

Device             Boot  Start    End Sectors Size Id Type
/root/tempsrc.dat1 *      2048  34815   32768  16M 83 Linux
/root/tempsrc.dat2       34816 100351   65536  32M 82 Linux swap / Solaris
/root/tempsrc.dat3      100352 262143  161792  79M 83 Linux

src# mkdir /mnt/tempsrc
src# mkdir /mnt/tempsrc-mounted
src# losetup /dev/loop1 /root/tempsrc.dat -o $(expr 2048 \* 512)
src# mke2fs /dev/loop1
src# mount /dev/loop1 /mnt/tempsrc-mounted
src# echo 'This is partition 1' > /mnt/tempsrc-mounted/note1.txt
src# umount /mnt/tempsrc-mounted
src# losetup -d /dev/loop1
src# losetup /dev/loop1 /root/tempsrc.dat -o $(expr 100352 \* 512)
src# cryptsetup luksFormat /dev/loop1 --verify-passphrase
src# cryptsetup open /dev/loop1 loop1-opened
src# mke2fs -j /dev/mapper/loop1-opened
src# mount /dev/mapper/loop1-opened /mnt/tempsrc-mounted
src# echo 'This is partition 3' > /mnt/tempsrc-mounted/note3.txt
src# umount /mnt/tempsrc-mounted
src# cryptsetup close loop1-opened
src# losetup -d /dev/loop1
src# rmdir /mnt/tempsrc-mounted
src# rmdir /mnt/tempsrc

Я знаю. Больше с LVM дел не имел. Ну да ладно.

Теперь у меня есть /root/tempsrc.dat, содержащий образ диска, например, образ SD-карты, который я хочу перенести на удаленное устройство назначения. На первом разделе находится файл с именем note1.txt, а третий раздел зашифрован и имеет note3.txtс другим содержимым. Я хотел бы убедиться, что смогу добраться до всего этого после запуска fsarchiverи передачи.

Давайте подготовим что-нибудь по месту назначения:

dest# dd if=/dev/zero of=/root/tempdest.dat bs=1M count=128
dest# fdisk -l /root/tempdest.dat
Disk /root/tempdest.dat: 128 MiB, 134217728 bytes, 262144 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

Давайте также создадим для них петлевые устройства:

src# losetup /dev/loop1 /root/tempsrc.dat
dest# losetup /dev/loop2 /root/tempdest.dat

Теперь, когда я готовился выполнить перенос, я обнаружил, что fsarchiver не может справиться с этим, как было заявлено.здесьиздесь.

Я надеялся сделать что-то вроде следующего:

src# fsarchiver savefs /tmp/fifo1 /dev/loop1
dest# fsarchiver restfs /tmp/fifo2 id=0,dest=/dev/loop2

ОБНОВЛЯТЬ:Я заменил целевой диск объемом 40 ГБ на временный третий диск и включил целевой компьютер.

Начнем с настройки нового диска:

dest# mkdir /mnt/sda-open
dest# mount /dev/sda1 /mnt/sda-open

Повторная попытка передачи, но на этот раз работающая со всем /dev/sda сразу:

src# mkdir /mnt/dest-sda
src# sshfs root@dest:/mnt/sda-open /mnt/dest-sda
src# fsarchiver savefs /mnt/dest-sda/src-sda.fsarchiver.img.fsa /dev/sda
filesys.c#317,generic_mount(): partition [/dev/sda] cannot be mounted on [/tmp/fsa/20180408-222928-xxxxxxxx-00] as [vfat] with options []
oper_save.c#1032,filesystem_mount_partition(): cannot mount partition [/dev/sda]: filesystem may not be supported by either fsarchiver or the kernel.
removed /mnt/dest-sda/src-sda.fsarchiver.img.fsa

Ну, вот и вся идея. Думаю, не зря его называют архиватором "FS". Давайте попробуем partimage.

src# partimage --compress=1 save /dev/sda /mnt/dest-sda/src-sda.partimg.bz2

Это тоже не сработало; по-видимому, это касается файловых систем, а не дисков в целом.

Поскольку мы работаем с диском в целом, давайте посмотрим, сработает ли ddrescue сейчас.

src# ddrescue --no-scrape /dev/sda /mnt/dest-sda/src-sda.ddrescue.img /mnt/dest-sda/src-sda.ddrescue.img.log
GNU ddrescue 1.21
Press Ctrl-C to interrupt
     ipos:  785580 kB, non-trimmed:        0 B,  current rate:  12320 kB/s
     opos:  785580 kB, non-scraped:        0 B,  average rate:  10615 kB/s
non-tried:   39241 MB,     errsize:        0 B,      run time:      1m 14s
  rescued:  785580 kB,      errors:        0,  remaining time:          1h
percent rescued:   1.96%      time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)

Я начал это в 5:41 вечера для диска на 40 ГБ по, я думаю, 100 Мбит/с LAN. На данный момент вывод утверждает, что это будет сделано примерно через час.

решение1

Ну, похоже, я был на правильном пути с промежуточным приводом. Это не то, что я изначально собирался сделать, но это помогло мне обойти мою проблему.

Новый привод теперь является клоном оригинального привода и работает отлично.

Чтобы клонировать мой оригинальный диск с учетом имеющихся ограничений (в частности, необходимости использования System Rescue CD по локальной сети без Clonezilla), мне удалось сделать следующее.

Сначала я подключил временный жесткий диск объемом 160 ГБ к запасному ПК, как описано выше, и загрузил оба компьютера с помощью загрузочного диска System Rescue CD.

С моего srcПК я смонтировал жесткий диск на 160 ГБ на destПК локально, используя sshfs, а затем запустил, ddrescueкак описано выше, чтобы создать образ неисправного жесткого диска на жестком диске на 160 ГБ в виде файла образа. Этот диск на 40 ГБ был создан в файл образа на 40 ГБ, и на это ушло около часа по моей локальной сети на 100 Мбит/с.

Я сохраню этот образ, чтобы мне не пришлось делать это снова; с этого момента инкрементных резервных копий данных должно быть достаточно для восстановления после создания этого первоначального образа.

После завершения этого этапа я заменил неисправный диск емкостью 40 ГБ на новый диск той же емкости (40 ГБ) в хосте, srcне трогая его и даже не выключая dest.

Затем я снова включил систему srcс загруженным System Rescue CD, снова смонтировал каталог destи sshfsна этот раз восстановил систему из образа с помощью:

dest# ddrescue --force --no-scrape /mnt/dest-sda/src-sda.ddrescue.img /dev/sda /mnt/dest-sda/src-restore-sda.ddresue.img_2018-04-08.log

На это ушло еще около часа.

Поскольку это был образ всего диска, а не разделов, я смог просто извлечь компакт-диск и перезагрузиться src, и все стало как прежде.

Связанный контент