Ich möchte wissen, wie ich beim Klonen meiner Festplatte am besten vorgehe, sodass ich die geklonte Festplatte einfach in meinen PC einlegen und nahtlos davon booten kann, wie ich es derzeit mit der vorhandenen Festplatte tue.
Ich habe eine Festplatte mit Debian, die laut SMART-Daten anscheinend ausfällt. Ich habe Backups und kann das Betriebssystem auch auf einer neuen Festplatte neu installieren. Im Moment würde ich die Festplatte jedoch am liebsten klonen, und ich habe derzeit keine andere Wahl, als System Rescue CD 5.0.3 von einer bootfähigen CD zu verwenden.
Auf der Festplatte ist nicht viel gespeichert – wahrscheinlich weniger als 10 GB belegter Speicherplatz und sehr wenige Daten. Daher mache ich mir wegen der Zeit keine großen Sorgen, weil ich nicht damit rechne, dass es außergewöhnlich lange dauern wird.
Wenn ich mich recht erinnere, bin ich bei der Installation von Debian die Optionen durchgegangen, um es als verschlüsseltes Laufwerk einzurichten. Ich glaube daher, dass /dev/sda als unverschlüsselte Boot-Partition angezeigt wird und der Rest verschlüsselt ist. In diesem „Rest“ habe ich eine kleine 10 GB große Root-Partition innerhalb des verschlüsselten Bereichs und der Rest wird derzeit nicht verwendet.
Ich arbeite auch mit älteren PATA-Laufwerken – es sind keine SATA-Laufwerke verfügbar – und der Computer verfügt über einen PATA-Anschluss auf der Hauptplatine, an den ein PATA-Flachbandkabel mit dem CD-ROM-Laufwerk zum Booten und der fast ausgefallenen Festplatte angeschlossen ist. Es ist also kein Platz vorhanden, um ein zweites PATA-Laufwerk anzuschließen, um eine lokale Übertragung durchzuführen.
Um dies zu umgehen, habe ich einen zweiten Computer mit demselben einzelnen PATA-Anschluss auf der Hauptplatine, an den ich ein weiteres CD-ROM-Laufwerk zum Booten und die Zielfestplatte angeschlossen habe.
Ich habe beide Computer über das CD-ROM-Laufwerk gebootet, um die System Rescue CD 5.0.3 aufzurufen, und ich überlege, welche Möglichkeiten ich habe, um das fehlerhafte Laufwerk so gut wie möglich zu klonen.
Die Computer sind über das LAN verfügbar und ich verbinde mich mit beiden per SSH über ein Terminal ohne grafische Benutzeroberfläche remote.
Ich bin mir nicht ganz sicher, wie groß das Quelllaufwerk und das Ziellaufwerk sind. Es ist möglich, dass das Quelllaufwerk eine größere Kapazität hat als das Ziellaufwerk. Daher würde ich idealerweise nur den belegten Speicherplatz übertragen und nicht das gesamte leere Laufwerk durchforsten.
Ich habe überlegt, ddrescue wie beschrieben zu verwendenHier; es beschreibt jedoch nur die lokale Übertragung der Daten.
AKTUALISIEREN:Ich schaue mir an, wie das Debian-Installationsprogramm das Quelllaufwerk eingerichtet hat. Es scheint, dass ich drei Partitionen habe und nur die letzte verschlüsselt ist:
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 mit ähnlicher Kapazität zu übertragen: einem 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
AKTUALISIEREN:Ich denke darüber nach, NBD zu verwenden, um die Partitionen des Quelllaufwerks über das LAN verfügbar zu machen, um ddrescue vom Ziel aus zu verwenden.
Folgendes habe ich bisher versucht, um das Quelllaufwerk freizugeben …
src# nbd-server -d 8000 /dev/sda
...und lokal auf dem Zielcomputer mounten:
dest# nbd-client src 8000 /mnt/nbd-sda
Leider erhalte ich bei diesem Versuch eine Fehlermeldung. 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.
AKTUALISIEREN:Als Nächstes versuche ich, die Partitionen auf dem Ziellaufwerk einfach manuell neu zu erstellen.
Ich begann mit dem Kopieren des 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
Bevor ich fortfuhr, dachte ich, dass es dieses Mal zumindest hilfreich sein würde, eine Wiederherstellungspartition zu erstellen.
dest# fdisk /dev/sda
Ich lösche die letzte Partition und gebe mir etwa 15 GB Speicherplatz für eine endgültige 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 auf dem Ziel dieselbe verschlüsselte Partition erstellen wie /dev/sda3 auf der Quelle. Das Gleiche kann ich auch 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 kann ich diese Wiederherstellungspartition jetzt 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 Speicherplatz verwende.
Lassen Sie es aushängen, aber die Zuordnung beibehalten:
src# umount /mnt/sda3-open
src# rmdir /mnt/sda3-open
Nun wollte ich die Wiederherstellungspartition auf dem Quelllaufwerk mounten:
src# mkdir /mnt/dest-sda4
src# sshfs root@dest:/mnt/sda4-open /mnt/dest-sda4
Nachdem dies gemountet war, konnte ich jetzt ddrescue ausführen:
src# ddrescue -f -n /dev/sda1 /mnt/dest-sda4/sda1.ddrescue.img /mnt/dest-sda4/sda1.ddrescue.log
Dadurch wurde ein Image mit der gleichen Größe wie die ursprüngliche Partition erstellt. Es sieht also so aus, als ob ungenutzter Speicherplatz nicht ausgeschlossen wird.
Ich versuchefsarchiverstattdessen jetzt:
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
Das Mounten von /dev/sda1 und Ausführen von df zeigt, dass nur 33 MB verwendet werden und die .fsa-Datei nur 24 MB groß ist. Vielleicht ist sie also komprimiert. Das ist besser als die ursprünglichen 120 MB.
Versuchen wir es nun mit der Root-Partition sda3, um zu sehen, wie das geht:
src# fsarchiver savefs /mnt/dest-sda4/sda3.fsarchiver.img.fsa /dev/mapper/sda3-opened
Dies wird wahrscheinlich eine Weile dauern, deshalb speichere ich dieses Update vorerst.
AKTUALISIEREN:Das ging schneller als erwartet. Das hier ist das Ergebnis:
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
Noch interessanter wird es, wenn man sich die Ausgabe des obigen Befehls ansieht:
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 das richtig verstehe, ist das ermutigend, denn es gab keine Probleme beim Lesen der Daten vom Quelllaufwerk.
Lassen Sie uns etwas aufräumen:
src# umount /mnt/dest-sda4
src# rmdir /mnt/dest-sda4
Als Nächstes stelle ich die archivierten Dateien auf /dev/sda1 und /dev/sda3 des Ziels wieder her. Sehen wir uns aber zunächst einmal an, was wir auf dem Ziellaufwerk haben, da ich vergessen habe, wo ich mit der Einrichtung aufgehört habe.
Erstens: Gibt es auf /dev/sda1 ein Dateisystem?
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 auch keine NTFS-Meldung. Da steht also nichts.
Lassen Sie uns das erste Partitionsabbild wiederherstellen:
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
Lasst uns jetzt montieren:
dest# mount /dev/sda1 /mnt/sda1
dest# ls -l /mnt/sda1
...
dest$ df -h | grep sda1
...
Bisher sieht es gut aus.
Lassen Sie uns jetzt die Root-Partition erstellen.
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?
Dasselbe wie vorher – da ist nichts.
Lassen Sie uns das Partitionsabbild wiederherstellen:
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
Lasst uns jetzt montieren:
dest# mount /dev/mapper/sda3-opened /mnt/sda3-open
dest# ls -l /mnt/sda3
...
dest$ df -h | grep sda3
...
Bisher sieht es gut aus.
Ich habe auf beiden auch Folgendes ausgeführt:
# fsarchiver probe simple
Es sieht alles so aus wie erwartet.
Eine Sache, die ich glaube ich noch übersehe, ist, dass ich glaube, dass dies Grub durcheinander bringen wird. Ich meine mich zu erinnern, dass Stage 1 problemlos vom MBR bootete, aber Stage 2 auf der /boot-Partition nicht gefunden werden konnte, als ich das letzte Mal versuchte, so etwas zu tun.
Diese Seiteführte zuDas, in dem beschrieben wird, 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/{sys,dev,proc}
Wenn ich neu starte, sollte dies funktionieren und das Laufwerk sollte ordnungsgemäß booten. Allerdings ist es jetzt spät und ich möchte noch nicht näher darauf eingehen.
Außerdem bin ich noch nicht überzeugt, dass das Ganze ein Happy End haben wird. Der obige Befehl grub-install gab an, dass die Installation für i386 erfolgt, aber ich glaube, ich möchte 64-Bit.
Ich muss diesen Teil möglicherweise wiederholen, indem ich die System Rescue CD über Rescue64 neu starte. Ich bin nicht sicher, ob der Standardstart 32-Bit gestartet hat.
Um den Rest werde ich mich morgen kümmern.
AKTUALISIEREN:Die gute Nachricht ist, dass die Standard-Boot-Version der System Rescue-CD rescue64 war, das dürfte also kein Problem gewesen sein.
Es stellte sich heraus, dass ich LVM völlig vergessen hatte und die UUIDs des Laufwerks offensichtlich nicht übereinstimmen.
...
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 nehme an, ich könnte damit kämpfen, aber ich werde mir die Mühe nicht machen. Stattdessen werde ich versuchen, was dirkt vorgeschlagen hat, und das komplette /dev/sda klonen – UUIDs und alles –, da 40 GB nur vier mal 10 GB sind, die ich letzte Nacht übertragen habe und die über das LAN nicht zu lange gedauert haben.
Ich konnte das gestern Abend nicht machen, weil ich NBD nicht zum Laufen bekam, also musste ich in Image-Dateien speichern. Das geht nicht, wenn ich eine komplette Festplatte klone, also schauen wir mal, ob Pipes oder Named Pipes besser funktionieren.
Zurück zum Anfang: Beide Computer wurden nun von der bootfähigen CD „System Rescue CD“ gebootet, beide sind über ihre jeweiligen per DHCP zugewiesenen IP-Adressen im Netzwerk verfügbar und bei beiden wurde das Root-Passwort per passwdBefehl festgelegt.
Bevor ich dies mit den echten Laufwerken mache, möchte ich mit einem winzigen künstlichen Laufwerk üben. Deshalb werde ich damit beginnen, dieses 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 weiß. Ich habe mich nicht wieder mit LVM befasst. Naja.
Ich habe jetzt eine /root/tempsrc.dat, die ein Image einer Festplatte enthält, z. B. ein SD-Karten-Image, das ich auf das Remote-Ziel übertragen möchte. Auf der ersten Partition befindet sich eine Datei namens note1.txt, und die dritte Partition ist verschlüsselt und hat eine note3.txtmit anderem Inhalt. Ich möchte sicherstellen, dass ich auf all dies zugreifen kann, nachdem ich die ausgeführt fsarchiverund übertragen habe.
Lassen Sie uns etwas zum Zielort 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
Lassen Sie uns auch hierfür Loopback-Geräte erstellen:
src# losetup /dev/loop1 /root/tempsrc.dat
dest# losetup /dev/loop2 /root/tempdest.dat
Als ich mich nun darauf vorbereitete, die Übertragung durchzuführen, stellte ich fest, dass fsarchiver dies nicht wie angegeben handhaben kannHierUndHier.
Ich hatte gehofft, so etwas wie das Folgende zu tun:
src# fsarchiver savefs /tmp/fifo1 /dev/loop1
dest# fsarchiver restfs /tmp/fifo2 id=0,dest=/dev/loop2
AKTUALISIEREN:Ich habe mein 40-GB-Ziellaufwerk durch ein temporäres drittes Laufwerk ersetzt und den Ziel-PC eingeschaltet.
Beginnen wir mit der Einrichtung dieses neuen Laufwerks:
dest# mkdir /mnt/sda-open
dest# mount /dev/sda1 /mnt/sda-open
Erneuter Übertragungsversuch, diesmal jedoch mit der Ausführung auf dem gesamten /dev/sda auf einmal:
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
So viel zu dieser Idee. Ich schätze, es wird nicht ohne Grund „FS“-Archiver genannt. Versuchen wir es mit Partimage.
src# partimage --compress=1 save /dev/sda /mnt/dest-sda/src-sda.partimg.bz2
Auch das hat nicht funktioniert. Offenbar betrifft dies nur Dateisysteme und nicht die gesamten Datenträger.
Da wir die gesamte Festplatte bearbeiten, wollen wir prüfen, 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 wird in der Ausgabe behauptet, dass es in etwa einer Stunde fertig sein wird.
Antwort1
Nun, es scheint, dass ich mit dem Zwischenlaufwerk auf dem richtigen Weg war. Das war zwar nicht das, was ich ursprünglich vorhatte, aber es hat mir geholfen, mein Problem zu lösen.
Das neue Laufwerk ist jetzt ein Klon des Originallaufwerks und läuft prima.
Um mein Originallaufwerk trotz der gegebenen Einschränkungen zu klonen (insbesondere, dass eine System Rescue-CD ohne Clonezilla über das LAN erforderlich war), konnte ich es wie folgt durchführen.
Zuerst habe ich die temporäre 160-GB-Festplatte wie oben beschrieben an einen Ersatz-PC angeschlossen und beide Computer mit meiner bootfähigen System Rescue-CD gebootet.
Von meinem srcPC aus habe ich die 160 GB-Festplatte destlokal auf dem PC gemountet sshfsund dann ddrescuewie oben beschrieben ausgeführt, um das fehlerhafte Laufwerk als Image-Datei auf der 160 GB-Festplatte abzubilden. Dieses 40 GB-Laufwerk wurde in eine 40 GB-Image-Datei abgebildet, und es dauerte etwa eine Stunde, bis es über mein 100 Mbit/s-LAN abgeschlossen war.
Ich werde dieses Image behalten, damit ich das nicht noch einmal machen muss. Von nun an sollten die inkrementellen Sicherungen der Daten ausreichen, um eine Wiederherstellung durchzuführen, nachdem dieses erste Image erfasst wurde.
Nachdem diese Phase abgeschlossen war, ließ ich das fehlerhafte 40-GB-Laufwerk durch das Ersatzlaufwerk mit der zufällig gleichen Kapazität von 40 GB im srcHost ersetzen, ohne es zu berühren oder auch nur auszuschalten dest.
Dann habe ich den Computer wieder hochgefahren, srcdie System Rescue-CD gebootet, das destVerzeichnis sshfserneut gemountet und dieses Mal die Wiederherstellung von meinem Image mit folgendem durchgeführt:
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 es sich um ein Image eines kompletten Laufwerks (nicht von Partitionen) handelte, konnte ich einfach die CD auswerfen und neu starten src, und alles war wie es war.