Hallo zusammen,
kurz vor dem Jahresabschluss hatte ich ein kleines Problem mit meinem QNAP-NAS:
Während das System eine der Festplatten neu aufgebaut hat, beschloss meine USV, dem NAS den Befehl zum herunterfahren zu geben, was dieses auch prompt tat.
Resultat: Der RAID-Controller war verwirrt und das RAID5 somit unbrauchbar.
An dieser Stelle möchte ich mich bei den diversen „Datenrettungsexperten“ – ja, die meisten davon tauchen ganz weit vorne in der Googlesuche auf – bedanken, die mir nach ihren „Analysen“ diverse Horrorszenarios geliefert haben, die nichts mit dem zu erkennenden Fehlerbild zu tun hatten und mich durch ihre Angebote zur Datenrettung von etwa 15.000 (in Worten: Fünfzehntausend!!) Euro für die Standardlösung bzw. 6000 EUR, wenn ich bereit bin, 3-4 Monate zu warten, nachhaltig dazu motiviert haben, mein Problem selbst zu lösen.
(Nicht falsch verstehen: Wenn mir jemand sagt: RAID-Wiederherstellung kostet 10.000EUR, dann ist das ehrlich und okay – jeder macht seine Preise selbst. Wenn mir aber wilde Stories geliefert werden, und die „kundenspezifische“ Lösung angeblich so aufwendig ist, dann ist das für mich nahe am Tatbestand der arglistigen Täuschung).
Noch einmal vielen Dank dafür – die 500 EUR Analysekosten betrachte ich als Lehrgeld!
Bevor ich jetzt anfange, die Lösung zu beschreiben, noch einige grundlegende Dinge:
- Arbeitet nie mit dem Original: Ich hab mir bei dem Wiederherstellungsprozess die Kopien meiner Festplatten mehrfach zerschossen, bevor der Workflow funktioniert hat. Ein paar Ersatzfestplatten kosten nicht die Welt (verglichen mit der Alternative, s.o.) und die 35 EUR für die Kopierstation (z.B https://www.amazon.de/gp/product/B011NUPSCA/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 ) waren auch gut angelegt.
- Markiert Eure Festplatten – die Reihenfolge, die die Platten im RAIDverbund hatten sind essenziell wichtig.
- Das NAS nicht neu starten – die QNAPS haben die dumme Eigenschaft, dann die anwesenden Festplatten wahlweise platt machen zu wollen oder alles auf Werkseinstellungen zurückzusetzen. Das macht alles nur komplizierter.
- Nehmt die Festplatten nach der Analyse raus, macht Euch eine Kopie und legt das Original zur Seite. Ihr braucht es als Grundlage für weitere Kopien, wenn was schiefgeht oder – wenn alles Stricke reißen und Euch die Daten so wichtig sind – um einen der oben genannten Kollegen zu bemühen…
- [Update] Lest Euch im VORFELD die folgende Seite durch: https://wiki.ubuntuusers.de/Software-RAID/ . Eventuell findet Ihr hier schon eine einfache Lösung für Euer Problem. Auf jeden Fall hilft es zu verstehen, was Ihr tut.
Jetzt aber zur eigentlichen Lösung:
Als erstes benötigt Ihr einen Konsolenzugriff auf das NAS. Also Putty herunterladen (http://www.putty.org/ ), IP-Adresse des NAS, Port 22 eintragen, verbinden, als admin anmelden und Ihr seid im Rennen.
Im nächsten Schritt müsst Ihr herausfinden, auf welchen Partitionen Eure Daten liegen.
Mit
ls /dev/sd*
bekomm Ihr eine Liste mit allen Partitionen, die aktuell auf dem System vorhanden sind. Im nächsten Schritt schaut Ihr Euch eventuell vorhandene Superblocks auf diesen Partitionen an:
mdadm --examine /dev/sdXn
Das X müsst Ihr durch den Buchstaben für die jeweilige HDD ersetzen, das n durch die Nummer der Partition. Zum Beispiel:
mdadm --examine /dev/sda3
Als Ergebnis bekommt Ihr dann hoffentlich etwas, das so aussieht:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 6e16c374:46c69b71:bc77c868:069371e2
Name : 0
Creation Time : Fri Jan 16 07:58:21 2015
Raid Level : raid5
Raid Devices : 5
Avail Dev Size : 7810899112 (3724.53 GiB 3999.18 GB)
Array Size : 15621798144 (14898.11 GiB 15996.72 GB)
Used Dev Size : 7810899072 (3724.53 GiB 3999.18 GB)
Super Offset : 7810899368 sectors
Unused Space : before=0 sectors, after=296 sectors
State : clean
Device UUID : 61479a3c:76b05353:1a7e0713:ee1d4d9b
Update Time : Thu Nov 3 14:31:33 2016
Checksum : 29591b87 – correct
Events : 81892
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 0
Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing)
Ihr werdet mehrere solcher Blocks finden. Aber nur eines je HDD beinhaltet Eure Daten. Erkennbar am einfachsten an der Größenangabe unter „Array Size“. Ich hab den ganzen Kram dann jeweils ins Notepad++ kopiert, und hatte nachher eine schöne Übersicht über meine Festplatten.
Ihr braucht außerdem die Angabe unter „Chunk Size“ sowie die „Device Role“. Letztere gibt Euch eine Aussage darüber, an welcher Stelle sich die Platte im RAID-Verbund befunden hat (hier die erste Platte).
Das Ergebnis der fehlenden Platte sah bei mir so aus:
sdd3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 6e16c374:7b4c1961:bc77c868:069371e2
Name : 0
Creation Time : Fri Jan 16 07:58:21 2015
Raid Level : raid5
Raid Devices : 5
Avail Dev Size : 7810899104 (3724.53 GiB 3999.18 GB)
Array Size : 15621798144 (14898.11 GiB 15996.72 GB)
Used Dev Size : 7810899072 (3724.53 GiB 3999.18 GB)
Super Offset : 7810899368 sectors
Unused Space : before=0 sectors, after=288 sectors
State : active
Device UUID : cd0c0b7e:b0514866:041b0d10:38d519f3
Update Time : Thu Nov 3 14:31:33 2016
Bad Block Log : 512 entries available at offset -8 sectors
Checksum : d2979675 – correct
Events : 0
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing)
Ihr seht: Das Ding wurde als „spare“ gekennzeichnet, sollte aber eigentlich „active device 3“ sein!
Bei QNAP gibt es eine Festplatte, die nicht im Datenverbund ist. Darauf befinden sich das Betriebssystem und andere Systeminfos. Die hat keinen Superblock. Für alle anderen Festplatten solltet Ihr wenigstens einen Superblock finden, der die ARRAY UUID des Datenarrays hat. Ansonsten funktioniert das Ganze nicht.
Bevor wir zum Zusammensetzen des RAIDs kommen, solltet Ihr Euch Gedanken machen, wo ihr Eure Daten hinschreiben wollt, wenn Ihr denn Zugriff darauf habt. Ich hatte einen Slot frei (6 HDDs möglich, nur 5 im Array), die ich im QNAP FrontEnd als Speicherpool eingebunden habe.
Wichtig – diese Platte muss genug Speicherplatz haben, um alle Eure Daten aufnehmen zu können. Wenn das nicht klappt, könnt Ihr externe Festplatten per USB anschließen und die Daten darauf verteilen.
So… jetzt geht’s aber ans Eingemachte.
Ihr habt die relevanten Partitionen in der richtigen Reihenfolge parat, Ihr kennt die Chunk Size, RAID Level, Anzahl der HDD,…
Es fehlt das Filesystem Eurer Partition:
blkid | grep sda3 | awk '{print $3}'
…wirft Euch am Ende sowas aus wie: TYPE=“ext4″
Jetzt braucht Ihr noch eine freie Bezeichnung für Euer neues RAID.
ls /dev/md*
liefert Euch eine Information, welche Bezeichnungen bereits vergeben sind. In meinem Fall waren das:
md13 md256 md9
Das neue Raid hab ich dann also md5 getauft. Das könnt Ihr frei wählen.
Der Befehl zum Zusammenbau des RAIDs ist:
mdadm -Cv /dev/md5 --assume-clean -l5 -n5 -c64 /dev/sd[cdefg]3
MDADM ist der Befehl mit dem man in Linux Raidsysteme administriert. Man benötigt Root-Rechte zur Ausführung, also im Zweifel ein sudo voranstellen. Wird aber als admin auf dem QNAP nicht gebraucht.
-C steht für „create“, also ein neues RAID erstellen.
-v -> verbose: Ich will sehen, was passiert
/dev/md5 ist die Bezeichnung des neuen RAIDs
–assume clean bringt den eigentlichen Mehrwert bei der ganzen Aktion. Normalerweise würde das System sagen, dass nicht genügend HDDs zur Wiederherstellung des RAIDs vorhanden sind. Mit „assume clean“ wird die „Reserveplatte“ als aktiv behandelt und das RAID kann aufgebaut werden.
-l ist das RAID-Level. Findet Ihr als Information im Superblock – bei mir Level 5
-n ist die Anzahl der beteiligten Laufwerke – in meinem Fall 5
-c ist die Chunk Size aus dem Superblock. In meinem Fall 64
/dev/sd[cdefg]3 gibt die Partitionen in der richtigen Reihenfolge an. Hier also jeweils die Partition der Festplatten sdc3, sdd3, sde3, sdf3, sdg3. Man kann es auch trennen. Hier noch mal ein Beispiel eines Raid 1 mit 2 Festplatten (sdc3 und sdd3):
mdadm -Cv /dev/md5 --assume-clean -l1 -n2 -c64 /dev/sdc3 /dev/sdd3
Genauere Infos findet Ihr hier: https://linux.die.net/man/8/mdadm
Ihr werdet gefragt, ob das RAID jetzt erstellt werden soll. Mit „y“ bestätigen und wenn alles gut geht, bekommt Ihr die Meldung, dass das RAID gestartet wurde.
Im nächsten Schritt muss das RAID gemounted werden. Dazu braucht Ihr ein Verzeichnis, das nachher als Mountpunkt dient. Also z.B.:
mkdir /home/raid
Das ist der Punkt, an dem Ihr später hoffentlich Eure Daten wiederfindet. Hier hängen wir jetzt das RAID ein. Ich habe die leidvolle Erfahrung gemacht, dass jeder Versuch, die Daten zu verändern zu einem Verlust des RAIDs geführt hat. Also machen wir das Ganze schreibgeschützt:
mount -t ext4 -o ro /dev/md5 /home/raid
das „ext4“ ersetzt Ihr durch das, was Ihr vorher beim Auslesen des Filesystems Eurer Platten gefunden habt. Eure Daten sollten jetzt im Verzeichnis /home/raid zu sehen sein:
ls /home/raid
Wenn das der Fall ist, dann habt Ihr den schwierigsten Part überstanden. Jetzt müssen die Daten nur noch an einen anderen Ort kopiert werden:
cp -av /home/raid /share/CACHEDEV1_DATA/
Unter /share/CACHEDEV1_DATA habe ich die Festplatte laufen, die die Daten aufnehmen soll. Ihr müsst hier natürlich das Ziel eintragen, wo Eure Daten hin sollen. Der Kopiervorgang hat bei mir satte 12 Stunden gedauert für 3,8TB. Wenn Ihr nicht alles auf eine Platte bekommt, dann kopiert nur einen Teil der Daten, wechselt dann das Laufwerk und kopiert dann den Rest.
Jetzt könnt Ihr Euch ein neues RAID anlegen und die gesicherten Daten wieder zurückspielen.
Am meisten geholfen hat mir dieser Beitrag hier: http://www.linuxquestions.org/questions/linux-server-73/mdadm-re-added-disk-treated-as-spare-750739/
Den Beteiligten vielen Dank, Euch viel Erfolg!
