QNAP Datenrettung

Max G. schrieb:

sudo dd if=/dev/sdb of=/mnt/disk.img

Dazu nimmt man besser ddrescue:

sudo apt install gddrescu sudo ddrescue /dev/sdb /mnt/disk.img /mnt/disk.img.map -v -v --data-preview=32 [--reverse]

Max G. schrieb:

sudo losetup -o 1085739008 /dev/loop10 ./disk.img

Schritt 4-5 etwas einfacher:

1

losetup /dev/loop10 disk.img

2

partprobe /dev/loop10

3

4

->

5

6

ls -l /dev/loop10*

7

brw-rw---- 1 root disk   7, 10  1. Dez 21:56 /dev/loop10

8

brw-rw---- 1 root disk 259,  4  1. Dez 21:56 /dev/loop10p1

9

brw-rw---- 1 root disk 259,  5  1. Dez 21:56 /dev/loop10p2

10

brw-rw---- 1 root disk 259,  6  1. Dez 21:56 /dev/loop10p3

Εrnst B. schrieb:

Schritt 4-5 etwas einfacher:

[...]

Oder noch einfacher:

1

> losetup -fP --show disk.img

2

3

4

>

Danke. Inzwischen habe ich herausgefunden, dass man mit "Thin Volume" bei QNAP noch viel mehr Spaß haben kann :(

Diese Seite hier https://www.industrialdreams.com/qnap-disk-drive-recovery-on-linux-part-i/ erklärt, wie man mittels eines Kernelpatches (den es hier https://github.com/czankel/qnap-kernel-ramdisk zum Glück schon fertig gibt) wieder auf die Daten kommt. Das vgchange -a y brauchte ewig, lief aber am Ende durch.

Max G. schrieb:

sudo dd if=/dev/sdb of=/mnt/disk.img

abgesehen dass bereits erwähnte ddrescue (...)

wenn die Quellplatte randvoll ist gehts, wennnoch 500GB frei sind dauerts nur unnötig lange und das Image unnötig gross. SEHR gross!

Wenn der Rest der Platte mit Nullen gefüllt ist, könnte das komprimierte Image viel kleiner werden. Deswegen habe ich bei MS den Befehl sdelete -z geliebt, bevor ich von gesunden Platten Images gezogen habe. Das dauert jedoch ewig, hat aber den Vorteil, dass man dann weiß, dass die dieser Datenträger bis zum bitteren Ende der Partition beschreibbar ist. Frühausfälle sind dann schon aufgefallen.

aber es muss immer noch alles gelesen werden...

Max G. schrieb:

der Versuch, die Daten von meinem nicht mehr laufenden QNAP zu retten, waren einigermaßen erfolgreich. Weil das nicht ganz trivial ist, schreibe ich hier auf, wie ich das gelöst habe. Einige Details kann man sicher anders machen.

Völlig sinnfrei ohne Angabe einer Fehlerbeschreibung.

@Max: Redest Du vom einer Single-Platte? - Oder von einem Raid?

Thomas S. schrieb:

@Max: Redest Du vom einer Single-Platte? - Oder von einem Raid?

Bei QNAP werden alle Platten mittels LVM verwaltet, egal ob Single, JBOD oder RAID.

Wäre eigentlich kein Problem. Wird es nur dadurch, dass QNAP halt proprietäre Erweiterungen verwendet. Bzw. (schlimmer): Die Volumes IMMER für die Verwendung dieser Erweiterungen markiert, auch wenn sie im konkreten Fall in Wirklichkeit überhaupt nicht verwendet werden.

Das ist ein absichtlich eingebaute Inkompatibilität mit dem einzigen Zweck der "Kundenbindung".

So kann man die Sachlage wohl zusammenfassen.

Die Daten sind inzwischen alle gerettet und liegen auf einer Platte mit einem ganz normalen ext4. Ich wollte auch keine Unterstützung, sondern den Misthaufen für den Fall dokumentieren, dass jemand anders mal damit Probleme hat. Hat gleichzeitig den Vorteil, dass ich selbst die Beschreibung wieder finde, falls ich sie jemals wieder brauche - allerdings werkelt neuerdings hier TrueNAS, das Thema ist für mich also hoffentlich durch.

Hi. Schön das Du es hin bekommen hast!

Gleiches Thema mit RAID-Verbund gibt es bei Synology. Darauf bin ich einmal rein gefallen, als nach 1,5Monaten die neue Diskstation nicht mehr an ging. Synology brauchte zwei Monate zum Austausch mit Versand nach England. Hier wird ein abgewandeltes mdadm (oder war es ein LUKS?) verwendet.

Danach wieder selbst gebaut und OMV aufgespielt.