So stellen Sie verschlüsselte Daten der Festplatte mit der System Rescue-CD über LAN wieder her

599
jia103

Ich würde gerne wissen, wie Sie mit dem Klonen meiner Festplatte am besten so weit fortfahren können, dass ich das geklonte Laufwerk einfach in meinen PC einlegen und nahtlos von diesem booten kann, wie es derzeit bei dem vorhandenen Laufwerk der Fall ist.

Ich habe eine Festplatte mit Debian, die aufgrund ihrer SMART-Daten aussieht. Ich habe Sicherungen und kann das Betriebssystem auch auf einem neuen Laufwerk neu installieren. Meine erste Präferenz im Moment wäre jedoch das Klonen des Laufwerks. Derzeit habe ich keine andere Möglichkeit, als System Rescue CD 5.0.3 von einer startfähigen CD zu verwenden.

Das Laufwerk hat nicht viel zu bieten - wahrscheinlich weniger als 10 GB Speicherplatz mit sehr wenig Daten. Daher ist mir die Zeit nicht allzu wichtig, da ich nicht damit rechne, dass dies außerordentlich viel Zeit in Anspruch nimmt.

Wenn ich mich erinnere, habe ich bei der Installation von Debian die Optionen durchgearbeitet, um es als verschlüsseltes Laufwerk einzurichten. Ich glaube, dass / dev / sda als unverschlüsselte Bootpartition erscheint und der Rest verschlüsselt ist, und dann in diesem "Rest" haben eine kleine 10-GB-Root-Partition innerhalb des verschlüsselten Bereichs und der Rest wird derzeit nicht verwendet.

Ich beschäftige mich auch mit älteren PATA-Laufwerken - keine verfügbaren SATA-Laufwerke - und der Computer verfügt über einen PATA-Anschluss auf der Hauptplatine, an den ein PATA-Flachbandkabel mit dem CD-ROM-Laufwerk zum Starten und dem fast ausfallenden Festplattenlaufwerk angeschlossen ist Laufwerk, so dass kein Platz für das Anschließen eines zweiten PATA-Laufwerks für eine lokale Übertragung vorhanden ist.

Um dies zu umgehen, habe ich einen zweiten Computer mit demselben PATA-Anschluss auf dem Motherboard, an dem ich ein anderes CD-ROM-Laufwerk zum Booten und die Zielfestplatte angeschlossen habe.

Ich habe beide Computer über das CD-ROM-Laufwerk gebootet, um System Rescue CD 5.0.3 aufzurufen, und ich erwäge, wie ich das fehlerhafte Laufwerk so gut wie möglich klonen kann.

Die Computer sind über das LAN verfügbar, und ich verbinde mich über ein Terminal ohne grafische Schnittstelle über SSH mit beiden.

Ich bin nicht ganz sicher über die Größe des Quelllaufwerks und des Ziellaufwerks. Es ist möglich, dass das Quelllaufwerk eine größere Kapazität als das Ziellaufwerk hat. Daher würde ich im Idealfall nur den belegten Speicherplatz übertragen, anstatt das gesamte leere Laufwerk auszuführen.

Ich überlegte, wie hier beschrieben, mit ddrescue zu arbeiten . Es beschreibt jedoch nur die lokale Übertragung der Daten.

UPDATE: Ich schaue, wie das Debian-Installationsprogramm das Quelllaufwerk eingerichtet hat. Anscheinend habe ich drei Partitionen und nur die letzte ist verschlüsselt:

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. 

Ich glaube, ich versuche auch, zwischen Laufwerken gleicher Kapazität zu übertragen: ein 40-GB-PATA-Laufwerk auf ein anderes 40-GB-PATA-Laufwerk.

Hier ist das Ziel:

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 

UPDATE: Ich überlege, NBD zu verwenden, um die Partitionen des Quelllaufwerks über das LAN verfügbar zu machen, um ddrescue vom Ziel aus zu verwenden.

Hier ist, was ich bisher versucht habe, das Quelllaufwerk freizulegen ...

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

... und lokal auf dem Zielcomputer einhängen:

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

Leider erhalte ich eine Fehlermeldung, wenn ich das versuche. Ich kann das Remote-Gerät nicht einmal mounten:

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. 

UPDATE: Als nächstes versuche ich, die Partitionen auf dem Ziellaufwerk von Hand neu zu erstellen.

Ich begann mit dem Kopieren des MBR über:

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 

Bevor ich fortfuhr, dachte ich, es würde zumindest diesmal helfen, eine Wiederherstellungspartition zu erstellen.

dest# fdisk /dev/sda 

Ich lösche die letzte Partition und gebe mir etwa 15 GB Speicherplatz für eine letzte Partition.

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 

Ich muss am Ziel dieselbe verschlüsselte Partition erstellen wie / dev / sda3 an der Quelle; Ich könnte genauso gut für diese Wiederherstellungspartition tun:

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

Öffnen Sie als Nächstes die verschlüsselte Wiederherstellungspartition:

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 

Zumindest jetzt kann ich diese Wiederherstellungspartition remote mounten und die Daten auf das bessere Laufwerk übertragen.

Zuerst habe ich die verschlüsselte Partition auf dem Quelllaufwerk geöffnet:

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

Jetzt mit df kann ich sehen, dass ich hier nur 12 GB Festplattenspeicher benötige.

Lassen Sie uns aussteigen, aber behalten Sie die Zuordnung bei:

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

Jetzt wollte ich die Wiederherstellungspartition auf dem Quelllaufwerk einhängen:

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

Mit diesem montierten konnte ich jetzt ddrescue ausführen:

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

Dies erzeugte ein Image mit der gleichen Größe wie die ursprüngliche Partition. Es sieht also so aus, als würde dies nicht ungenutzten Speicherplatz ausschließen.

Ich versuche stattdessen jetzt 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 

Beim Mounten von / dev / sda1 und dem Ausführen von df wird nur 33 MB benötigt, und die .fsa-Datei ist nur 24 MB groß, daher ist sie möglicherweise komprimiert. Es ist besser als die ursprünglichen 120 MB.

Versuchen wir nun mit der Root-Partition sda3, wie das geht:

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

Dies wird wahrscheinlich eine Weile dauern, also speichere ich dieses Update vorerst.

UPDATE: Das ging schneller als ich erwartet hatte. Hier ist was ich bekommen habe:

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 

Hier ist der noch interessantere Teil mit Blick auf die Ausgabe des obigen Befehls:

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 

Wenn ich dies richtig lese, ist dies ermutigend, da es keine Schwierigkeiten gab, Daten vom Quelllaufwerk zu lesen.

Lassen Sie uns ein paar aufräumen:

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

Als nächstes stelle ich die archivierten Dateien wieder auf / dev / sda1 und / dev / sda3 des Ziels wieder her, aber schauen wir uns zuerst an, was wir auf dem Ziellaufwerk haben, weil ich vergessen habe, wo ich das Setup eingestellt habe.

Erstens: Gibt es ein Dateisystem auf / 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? 

OK. Ich habe kein Dateisystem erwartet, aber keine NTFS-Nachricht. Also nichts da.

Stellen wir das erste Partitions-Image wieder her:

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 

Lass uns jetzt montieren:

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

Die Dinge sehen bisher gut aus.

Lassen Sie uns jetzt die Root-Partition ausführen.

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? 

Gleich wie vorher - da ist nichts.

Stellen wir das Partitions-Image wieder her:

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 

Lass uns jetzt montieren:

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

Die Dinge sehen bisher gut aus.

Ich habe auf beiden auch folgendes ausgeführt:

# fsarchiver probe simple 

Die Dinge sehen wie erwartet aus.

Eine Sache, die ich noch vermisse, ist, dass ich glaube, das wird Grub durcheinander bringen. Ich erinnere mich an etwas über das Booten der ersten Stufe aus dem MBR, aber dann konnte sie Stufe 2 auf der / boot-Partition nicht finden, als ich das letzte Mal so etwas versucht hatte.

Diese Seite führte dazu, wie Grub repariert wird:

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/ 

Beim Neustart sollte dies funktionieren und das Laufwerk sollte ordnungsgemäß starten. Es ist jedoch jetzt spät, und ich möchte noch nicht darauf eingehen.

Ich bin auch noch nicht überzeugt, dass dies ein glückliches Ende haben wird. Der grub-install-Befehl oben besagt, dass er für i386 installiert wird, aber ich glaube, ich möchte 64-Bit.

Möglicherweise muss dieser Teil durch einen Neustart der System Rescue-CD über rescue64 erneut ausgeführt werden. Ich bin mir nicht sicher, ob der Standard-Start 32-Bit ausgeführt hat.

Ich werde mich morgen wieder um den Rest kümmern.

UPDATE: Die gute Nachricht ist also, dass der Standardstart für System Rescue CD rescue64 war, so dass kein Problem aufgetreten wäre.

Es stellte sich heraus, dass ich LVM vollständig vergessen habe, und die UUIDs des Laufwerks stimmen offensichtlich nicht überein.

... 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) 

Ich vermute, ich könnte damit kämpfen, aber ich werde mich nicht darum kümmern. Stattdessen werde ich versuchen, was dirkt vorgeschlagen hat, und die vollständigen / dev / sda - UUIDs und alles klonen - da 40 GB nur vier mal 10 GB sind, die ich gestern Abend übertragen habe und die nicht allzu lange gedauert habe LAN.

Ich konnte das letzte Nacht nicht tun, weil ich NBD nicht zum Laufen bringen konnte, also habe ich auf das Speichern von Bilddateien zurückgegriffen. Ich kann das nicht tun, wenn ich einen kompletten Disk-Klon mache. Schauen wir uns also an, ob Pipes oder Named Pipes besser funktionieren.

Zurück am Anfang haben beide Computer nun von der bootfähigen CD der System Rescue-CD gebootet. Beide sind über das Netzwerk über ihre jeweiligen DHCP-zugewiesenen IP-Adressen verfügbar, und beide haben ihr Root-Kennwort über den passwdBefehl festgelegt.

Bevor ich dies mit den echten Laufwerken mache, möchte ich mit einem winzigen gefälschten Laufwerk üben. Ich beginne damit, es einzurichten.

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 

Ich kenne. Ich habe mich nicht mehr mit LVM befasst. Naja.

Ich habe jetzt eine /root/tempsrc.dat, die ein Image einer Festplatte wie ein SD-Karten-Image enthält, das ich zum Remote-Ziel übertragen möchte. Auf der ersten Partition wird eine Datei aufgerufen note1.txt, und die dritte Partition ist verschlüsselt und hat einen note3.txtanderen Inhalt. Ich möchte sichergehen, dass ich all das erreichen kann, nachdem ich das ausgeführt fsarchiverund übertragen habe.

Lassen Sie uns am Ziel etwas vorbereiten:

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 

Erstellen wir auch Loopback-Geräte für diese:

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

Jetzt, als ich mich auf die Übergabe vorbereitete, stellte ich fest, dass fsarchiver nicht wie hier und hier beschrieben damit umgehen kann .

Ich hatte gehofft, etwas wie das Folgende zu machen:

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

UPDATE: Ich habe mein 40-GB-Ziellaufwerk durch ein temporäres drittes Laufwerk ersetzt und den Ziel-PC eingeschaltet.

Beginnen wir mit dem Einrichten dieses neuen Laufwerks:

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

Erneuter Transferversuch, außer dass diesmal die gesamte / dev / sda gleichzeitig ausgeführt wird:

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 

Nun, so viel zu dieser Idee. Ich nehme an, sie nennen es "FS" -Archiver aus einem bestimmten Grund. Versuchen wir es mit partimage.

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

Das hat auch nicht funktioniert; anscheinend handelt es sich dabei um Dateisysteme und nicht um Festplatten insgesamt.

Da wir auf der gesamten Festplatte arbeiten, wollen wir sehen, ob ddrescue jetzt funktioniert.

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) 

Ich habe dies um 17:41 Uhr für ein 40-GB-Laufwerk über ein 100-MBit / s-LAN gestartet. Im Moment ist die Ausgabe in etwa einer Stunde erledigt.

1
Gibt es einen Grund, warum Sie nicht einfach das komplette Laufwerk klonen können, anstatt sich MBR, Partitionen usw. anzusehen? Übrigens können Sie auch Ihre eigenen Fragen beantworten und die Antwort akzeptieren. dirkt vor 6 Jahren 0
Ich habe noch keine befriedigende Antwort erhalten. Dies sind nur Notizen zu dem, was ich bisher ausprobiert habe und nichts weiter. Nachdem ich darauf geschlafen habe, möchte ich jetzt genau das tun - das ganze Laufwerk klonen. Mein Anliegen war die Zeit, die zum Übertragen der meistens nicht verwendeten 40 GB über das LAN erforderlich ist, wenn weniger als 10 GB belegt sind und die übertragen werden müssen. Da jedoch die Übertragung von 10 GB nicht lange dauerte, denke ich, werde ich versuchen, die volle Festplatte zu wiederholen. jia103 vor 6 Jahren 0

1 Antwort auf die Frage

0
jia103

Nun, es scheint, dass ich mit dem Vermittlerantrieb auf dem richtigen Weg war. Dies war nicht das, was ich ursprünglich beabsichtigt hatte, aber es half mir, mein Problem zu überwinden.

Das neue Laufwerk ist jetzt ein Klon des ursprünglichen Laufwerks und summt gut mit.

Um mein ursprüngliches Laufwerk mit den aufgezeigten Einschränkungen zu klonen - insbesondere wenn eine System Rescue-CD ohne Clonezilla über das LAN ausgeführt werden muss - konnte ich dies wie folgt durchgehen.

Zunächst ließ ich die temporäre 160-GB-Festplatte wie oben beschrieben in einen Ersatz-PC einstecken und bootete beide Computer mit meiner startfähigen System Rescue-CD.

Von meinem srcPC aus habe ich die 160-GB-Festplatte destlokal auf dem PC installiert sshfsund dann ddrescuewie oben beschrieben ausgeführt, um die fehlerhafte Festplatte auf der 160-GB-Festplatte als Image-Datei abzubilden. Dieses 40-GB-Laufwerk wurde in eine 40-GB-Image-Datei aufgenommen, und es dauerte etwa eine Stunde, bis es über mein 100-Mbps-LAN abgeschlossen wurde.

Ich werde dieses Bild behalten, damit ich es nicht noch einmal tun muss. Ab diesem Zeitpunkt sollten die inkrementellen Sicherungen der Daten ausreichen, um wiederhergestellt zu werden, nachdem dieses ursprüngliche Image erfasst wurde.

Nachdem diese Phase abgeschlossen war, ließ ich das fehlerhafte 40-GB-Laufwerk durch das Ersatzlaufwerk ersetzen, das zufällig die gleiche 40-GB-Kapazität im srcHost hat, ohne dass es berührt oder gar ausgeschaltet wurde dest.

Dann habe ich mich srcmit der System Rescue-CD wieder hochgefahren, das destVerzeichnis sshfserneut eingebunden und dieses Mal aus meinem Image wiederhergestellt:

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 

Dies dauerte etwa eine weitere Stunde.

Da dies ein Image eines kompletten Laufwerks war - keine Partitionen -, konnte ich die CD einfach auswerfen und neu starten src, und alles war so wie es war.