QNAP Datenrettung

[Max G. (l0wside)]

Hallo zusammen,

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.

1. Neue Platte (größer als die existierende besorgen), partitionieren 
und ein großes Dateisystem darauf formatieren (z.B. ext4)
2. Beide Platten an ein Linux-System anschließen (USB-SATA-Adapter 
können ggf. hilfreich sein)

Im Folgenden nehme ich an, dass die neue Platte /dev/sdc ist und die 
Platte aus dem kaputten QNAP /dev/sdb.

3. Daten auf die neue Platte kopieren

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

Warten und Daumen drücken. Nach dem Abschluss kann man die alte Platte 
entfernen.

4. Jetzt müssen wir die Partition in der Image-Datei finden. Das geht 
mit

cd /mnt/
sudo fdisk -l ./disk.img

fdisk liefert nun die Partitionen. Die größte ist in der Regel 
richtig. Von dieser brauchen wir den "Start"-Wert (bei mir 2120584) und 
müssen ihn mit 512 multiplizieren (bei mir also 1085739008).

5. Nun beginnt die Magie. Erst mal als Loopback die Partition mounten:

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

6. Mit vgscan nun die "Volume Group" suchen.

sudo vgscan

Bei mir steht dann da:

Found volume group "vg1" using metadata type lvm2

7. Mit dieser Information können wir nun die Volume Group (bei mir vg1) 
aktivieren und anschließend das (mehrfach virtualisierte) Laufwerk 
mounten:

sudo vgchange -ay vg1
sudo mkdir /drive
sudo mount /dev/vg1/lv1 /drive

Die Daten sollten jetzt unter /drive vorhanden sein.

Vielleicht kann es ja mal jemand brauchen...

Grüße Max

[Jens G. (jensig)]

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]

[Εrnst B. (ernst)]

Max G. schrieb:
> sudo losetup -o 1085739008 /dev/loop10 ./disk.img

Schritt 4-5 etwas einfacher:

losetup /dev/loop10 disk.img
partprobe /dev/loop10

->

ls -l /dev/loop10*
brw-rw---- 1 root disk   7, 10  1. Dez 21:56 /dev/loop10
brw-rw---- 1 root disk 259,  4  1. Dez 21:56 /dev/loop10p1
brw-rw---- 1 root disk 259,  5  1. Dez 21:56 /dev/loop10p2
brw-rw---- 1 root disk 259,  6  1. Dez 21:56 /dev/loop10p3

[Ob S. (Firma: 1984now) (observer)]

Εrnst B. schrieb:

> Schritt 4-5 etwas einfacher:
[...]

Oder noch einfacher:

>

> losetup -fP --show disk.img

>

[Max G. (l0wside)]

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.

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

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!

[Lu (oszi45)]

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.

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

aber es muss immer noch alles gelesen werden...

[Frank D. (Firma: LAPD) (frank_s634)]

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.

[Thomas S. (Firma: Chipwerkstatt) (tom_63)]

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

[Ob S. (Firma: 1984now) (observer)]

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.

[Max G. (l0wside)]

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.

[Marci W. (marci_w)]

.● Des|ntegrator ●. schrieb:
> sind dauerts nur unnötig lange
> und das Image unnötig gross. SEHR gross!

Mag sein, aber wenn es um Datenrettung geht, wären mir solche Dinge 
völlig egal. Hauptsache ich hätte meine Daten noch!

ciao

Marci