Platte mit ddrescue geklont - auf der Zielplatte fehlen Daten

tomsiduction · 2017/11/19, 21:03:31

Hallo
Ich habe mit ddrescue meine Platte geklont (Platte mit LUKS und LVM)

sudo ddrescue -v -- force /dev/sda2 /dev/sdb2

Nun fehlen auf der Zielplatte Daten.
Fsck war auf beiden Platten unauffällig.
Smartctl weist keine Fehler auf.

Wie kann ich sicherstellen, dass auf die Zielplatte auch wirklich und korrekt geschrieben wird (und wenn das aus irgendwelchen Gründen nicht geschieht mir zumindest ein Hinweis gegeben wird)

Macht ein

"dd" mit der Option "oflag=direkt"

mehr Sinn?

Vielen Dank

cas · 2017/11/20, 04:13:31

Falls die Platte keine Probleme macht, sehe ich keinen Grund ddrescue zu benutzen.

Ansonsten verweisen
http://www.manpagez.com/info/ddrescue/ddrescue-1.12/ddrescue_6.php und
https://wiki.ubuntuusers.de/gddrescue/
darauf, immer ein logfile zu benutzen.

zunächst

Code Select

ddrescue -n QUELLE ZIEL ddrescue.log
Falls es Fehler gab (steht im logfile)

Code Select

ddrescue QUELLE ZIEL ddrescue.log

Falls es keine Fehler gab, kann auch nichts fehlen.

PS: sudo wird bei siduction nicht benutzt, sondern direkt root.

tomsiduction · 2017/11/20, 12:10:56

Vielen Dank

Würde der Umstand, dass auf Zielplatte Daten fehlen, welche sich (dennoch) auf der Quellplatte befinden im Logfile stehen ?

Danke

der_bud · 2017/11/20, 15:17:35

Ja, das müsste dann eigentlich im Logfile stehen, weil dieses auch verwendet wird um abgebrochene Vorgänge fortzusetzen oder im ersten Versuch fehlerhafte Vorgänge zu wiederholen, es ist also nicht "nur" ein Log sondern auch eine Steuerdatei.

Hintergrund vom doppelten Aufruf wie von cas beschrieben ist also, im ersten Lauf mit '-n' nur die auf Anhieb fehlerfreien Daten zu lesen und fehlerhafte ohne retry zu überspringen, was recht schnell geht. Im zweiten Lauf werden dann die per Logfile als fehlerhaft markierten gründlicher probiert (langsam) ohne sich um schon gesichertes kümmern zu müssen. Ganz ohne Log fehlt die Info, ob und warum etwas übersprungen/aufgegeben wurde.

tomsiduction · 2017/11/29, 20:35:30

Hallo
Ich habe folgende Erfahrung gemacht:

Noch dem clonen, - siehe nachfolgendes Protokoll

# Mapfile. Created by GNU ddrescue version 1.22
# Command line: ddrescue -n -f -v /dev/sda2 /dev/sdb2 ddrescue4.log
# Start time: 2017-11-29 03:55:15
# Current time: 2017-11-29 06:06:48
# Finished
# current_pos current_status current_pass
0x3A195F0000 + 1
# pos size status
0x00000000 0x3A19600000 +

war - entgegen der Erwartungen aus dem Protokoll - keine Dateiidentität von Ursprungs- und Zielpartition gegeben.

Was kann ich noch unternehmen um (wenigstens) die nicht korrekt übertragenen Dateien angezeigt zu bekommen?

Vielen Dank im Voraus

Geier0815 · 2017/11/30, 11:05:59

Als erstes könntest Du die Ausgaben von ddrescue erhöhen indem Du bis zu 4mal v (kleines V) bei den Optionen angibst. Das die zu rettende Partition nicht eingehängt sein sollte, auch nicht lesend, hast Du beachtet? Ansonsten solltest Du mal gucken ob evtl. symbolische Links oder ähnliche Späße betroffen sind, da schweigt sich die Doku leider zu aus wie mit diesen umgegangen wird.
Ganz im Zweifel kannst Du die Quell-Partition lesend einhängen und ein diff gegen das Ziel laufen lassen um heraus zu finden was fehlt. Dies würde ich im ersten Schritt aber nur über Datum und Größe machen lassen und nicht noch über den Inhalt der Dateien.

Das Manual von gddrescue kennst Du?

tomsiduction · 2017/12/01, 19:34:33

Hallo und vielen Dank
Ich habe den Hinweis befolgt:

Das Ergebnis ......

GNU ddrescue 1.22
About to copy 249533 MBytes from '/dev/sda2' [UNKNOWN] (249533825024) to '/dev/sdb2' [UNKNOWN] (249533825024)
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 4992 sectors
Sector size: 512 Bytes
Direct in: no Direct out: no Sparse: no Truncate: no
Trim: yes Scrape: no Max retry passes: 0

ipos: 249533 MB, non-trimmed: 0 B, current rate: 17301 kB/s
opos: 249533 MB, non-scraped: 0 B, average rate: 35924 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 249533 MB, bad areas: 0, run time: 1h 55m 45s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished

sah gut aus.
Jedoch stellte sich wieder eine Inkonsistenz heraus.
Mit rsync oder ähnlichen Ansätzen komme ich nicht weiter, weil die Partitionen verschlüsselt sind.

Schön wäre es wenn ich ein Clone-Programm hätte, welches mir (Schreib-) Fehler anzeigt.
Gibt es so etwas?

Vielen Dank nochmal

melmarker · 2017/12/01, 22:33:18

Quote from: tomsiduction on 2017/12/01, 19:34:33
Mit rsync oder ähnlichen Ansätzen komme ich nicht weiter, weil die Partitionen verschlüsselt sind.

Warum ist das ein Hindernis?

tomsiduction · 2017/12/02, 12:34:18

Ich habe folgendes als Hindernis wahrgenommen:

Quell und Zielpartition sind verschlüsselt.

Daher sind auf beiden Partitionen die gleichen LVs

als auch die gleichen VGsys.

Damit kann ich die jeweiligen LVs (auf den beiden Partitionen) nicht auf unterschiedliche Mountpoints einhängen.

Daher klappt es nicht mit rsync

Vielen Dank

melmarker · 2017/12/02, 12:56:44

Quote from: tomsiduction on 2017/12/02, 12:34:18
Damit kann ich die jeweiligen LVs (auf den beiden Partitionen) nicht auf unterschiedliche Mountpoints einhängen.

Begreif ich nicht

tomsiduction · 2017/12/02, 16:43:56

Hallo und vielen Dank
Ich habe die Quellplatte im laufenden System eingehängt

Dies ergibt bei mir (zunächst) folgendes Bild:

/dev/mapper/VGsys-LVroot 12319880 10678572 995780 92% /
/dev/mapper/VGsys-LVdaten 205762452 173016728 22223920 89% /daten
/dev/mapper/VGsys-LVhome 20511312 11865020 7581332 62% /home

Wenn ich nun die verschlüsselte Zielplatte einhänge habe ich - unter Berücksichtigung des Umstandes dass es ein Backup werden soll - auf dieser Zielplatte wiederum

/dev/mapper/VGsys-LVroot
/dev/mapper/VGsys-LVdaten
/dev/mapper/VGsys-LVhome

also insgesamt zwei mal

/dev/mapper/VGsys-LVroot
/dev/mapper/VGsys-LVdaten
/dev/mapper/VGsys-LVhome

Dieses löst bei meinem System eine Fehlermeldung aus
Vielen Dank

bluelupo · 2017/12/03, 17:59:57

Hi tomsiduction,

erst mal eine Frage noch, sind die Quell- bzw. Zieldisk in einem phsikalischen System?

Ein LV-Name muss innerhalb einer VG (Volumegroup) einmalig sein.

So etwas würde gehen:
/dev/VGsys/LVdaten
/dev/VGsystem/LVdaten

Du kannst keine zwei LV's mit demselben Namen anlegen/mounten in einer VG. Wenn du eine verschlüsselte oder unverschlüsselte Disk per dd sichern willst muss das zwingend über einen sog. Snapshot erfolgen. Diesen kannst aus dem laufenden System heraus erstellen (muss natürlich einen anderen Namen haben als das zu sichernde LV). Dieser Snapshot wird innerhalb weniger Sekunden erstellt und ist konsistent. Danach kannst du genau diesen Snapshot per dd auf ein Medium sichern. Nach der "Kopieraktion" kannst du das Snapshot-LV wieder löschen.

Einen Snapshot LV erstellt man mit dem lvcreate Kommando (Option -s):

Code Select


# lvcreate -l<Größe_des_Quell-LV> -s -n SNAPSHOT_LVdaten /dev/VGsys/LVdaten