[DE] Platte mit ddrescue geklont - auf der Zielplatte fehlen Daten

[tomsiduction]

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]

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]

Vielen Dank

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

Danke

[der_bud]

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]

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]

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]

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]

Mit rsync oder ähnlichen Ansätzen komme ich nicht weiter, weil die Partitionen  verschlüsselt sind.

Warum ist das ein Hindernis?

[tomsiduction]

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]

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

Begreif ich nicht

[tomsiduction]

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]

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