erfolgreiche Datenrettung RAID5 auf DS410

Status
Für weitere Antworten geschlossen.

Talon

Benutzer
Mitglied seit
31. Okt 2010
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Hallo,

auf meiner DS410 war das RAID5 Volume abgestürzt. Mir ist es gelungen, teilweise mit Informationen aus dem Forum, meine Daten zu retten.

Zu Beginn wollte ich eine Reperatur innerhalb der DS410 durchführen. Die Anleitung dafür findet am hier:

http://www.synology-forum.de/showthread.html?t=510

Leider kam ich bereits beim 1. Punkt nicht weiter.

raid stoppen:
mdadm --stop /dev/md2

Ich bekam immer die Fehlermeldung "Ressource Busy". :eek: Auch das Stoppen aller Dienste und Apps auf der Box brachten keinen Erfolg.



Also, der andere Weg - Reperatur ausserhalb der Synology.

Mein PC hat zum Glück 6 SATA Anschlüsse und konnte dafür genutzt werden. Nur läuft auf diesem kein Linux, sondern Win7 (selber Schuld :rolleyes: ).
Eine Option hierfür ist Knoppix. Schnell die aktuelle Verion runterladen und brennen.

Jetzt kann es losgehen:

PC-Festplatten abkabeln und die 4 Platten der DS410 anschliessen. Dabei habe ich auf die Reihenfolge geachtet:

Disk1 - SATA0
Disk2 - SATA1
Disk3 - SATA2
Disk4 - SATA3

Den Rechner von der DVD booten lassen. Da Knoppix ein Live System ist und normalerweise ohne Festplatten arbeitet wird der RAID Treiber nicht automatisch geladen.

zuerst auf root wechseln:

RAID Treiber laden:

Zunächst kannst du überprüfen ob die Partitionen überhaupt noch als RAID erkennbar sind:
mdadm --examine --brief /dev/sda3

ARRAY /dev/md/2 metadata=1.1 UUID=4b9499e3:bfdcf0c6:4d457609:16210eab name=

Dies für alle 4 Platten durchführen ( /dev/sda3, /dev/sdb3, /dev/sdc3 /dev/sdd3 ). Die UUID muss immer gleich sein.

Jetzt das RAID in Betrieb nehmen (auf korrekte Syntax achten):
mdadm --assemble /dev/md/2 /dev/sd[abcd]3

Brachte keinen Erfolg - also eine Nummer härter:
mdadm --assemble --force /dev/md/2 /dev/sd[abcd]3

Na also, schnell den Status geprüft:
cat /proc/mdstat

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdb3[0] sdd3[4] sdc3[3] sda3[2]
4381251840 blocks super 1.1 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

Zum Test mal mounten:
mount /dev/md2 /mnt

Alles prima, zum Schluss das RAID mit umount wieder abhängen den PC runterfahren. Die Festplatten auf ihrem angestammten Platz in der Synology einbauen und...

... alle Daten wieder da. :D:D:D


Ich hoffe der Beitrag ist eine kleine Hilfe für jeden der mal in die selbe Situation kommt.
 

randfee

Benutzer
Mitglied seit
08. Apr 2010
Beiträge
1.070
Punkte für Reaktionen
3
Punkte
64
Erstmal, glückwunsch, dass nix weg ist (kein Backup gehabt)?
Nicht zuletzt da ich das selbe System habe interessiert mich doch aber der genaue Grund für so einen umständlichen und komplexen recovery-weg. Was heißt "RAID5 ist abgestürzt"? Eine Platte futsch? Sollte die DS sowas nicht selber beseitigen können (mit neuer Platte)? Hätte halt gerne ein paar Details zur Ausgangssituation.
 

Talon

Benutzer
Mitglied seit
31. Okt 2010
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Backup ist schon vorhanden, aber nur "wichtigen Daten". 4.5TB muss man erst einmal sichern können. Werde jetzt sicherlich was tun müssen.

Einen Defekt einer Platte habe ich nicht feststellen können. Problem bei mir, das HDD3 und HDD4 auf "nicht initialisiert" standen (siehe Scrennshot).

Laut Log gab es auf beide Platten IO Fehler:
Oct 27 18:22:13 kernel: [78215.596029] ata3: exception Emask 0x10 SAct 0x0 SErr 0x180000 action 0x6 fro zen
Oct 27 18:22:13 kernel: [78215.603350] ata3: edma_err_cause=00000020 pp_flags=00000000, SError=00180000
Oct 27 18:22:13 kernel: [78215.610401] ata3: SError: { 10B8B Dispar }
Oct 27 18:22:13 kernel: [78215.618609] ata2: exception Emask 0x10 SAct 0x0 SErr 0x190002 action 0xe fro zen
Oct 27 18:22:13 kernel: [78215.625922] ata2: edma_err_cause=00000020 pp_flags=00000000, SError=00180000
Oct 27 18:22:13 kernel: [78215.632973] ata2: SError: { RecovComm PHYRdyChg 10B8B Dispar }
Oct 27 18:22:13 kernel: [78215.642912] ata4: exception Emask 0x10 SAct 0x0 SErr 0x190002 action 0xe fro zen
Oct 27 18:22:13 kernel: [78215.650223] ata4: edma_err_cause=00000020 pp_flags=00000000, SError=00180000
Oct 27 18:22:13 kernel: [78215.657274] ata4: SError: { RecovComm PHYRdyChg 10B8B Dispar }
Oct 27 18:22:18 kernel: [78220.604070] ata3.00: disabled
Oct 27 18:22:18 kernel: [78220.648835] sd 2:0:0:0: [sdc] START_STOP FAILED
Oct 27 18:22:18 kernel: [78220.660949] SynoCheckRdevIsWorking (7636): remove active disk sdc3 from md2 raid_disks 4 mddev->degraded 0 mddev->level 5
Oct 27 18:22:18 kernel: [78220.672020] raid5: Disk failure on sdc3, disabling device. Operation continu ing on 3 devices
Oct 27 18:22:18 kernel: [78220.680462] syno_hot_remove_disk (7536): cannot remove active disk sdc3 from md2 ... rdev->raid_disk 2 pending 0
Oct 27 18:22:18 kernel: [78220.691379] scsi 2:0:0:0: rejecting I/O to dead device
Oct 27 18:22:18 kernel: [78220.696512] scsi 2:0:0:0: rejecting I/O to dead device
Oct 27 18:22:18 kernel: [78220.701638] end_request: I/O error, dev sdc, sector 4980352
Oct 27 18:22:18 kernel: [78220.707199] md: super_written gets error=-5, uptodate=0
Oct 27 18:22:18 kernel: [78220.712414] raid1: Disk failure on sdc1, disabling device.
Oct 27 18:22:18 kernel: [78220.712418] Operation continuing on 3 devices
Oct 27 18:22:18 kernel: [78221.037078] ata4.00: disabled
Oct 27 18:22:18 kernel: [78221.043027] sd 3:0:0:0: rejecting I/O to offline device
Oct 27 18:22:29 kernel: [78221.066510] end_request: I/O error, dev sdd, sector 1188864
Oct 27 18:22:29 kernel: [78221.072085] raid1: Disk failure on sdd1, disabling device.
Oct 27 18:22:29 kernel: [78221.072088] Operation continuing on 2 devices
Oct 27 18:22:29 kernel: [78221.082094] raid1: sdd1: rescheduling sector 1188608
Oct 27 18:22:29 kernel: [78221.087352] sd 3:0:0:0: rejecting I/O to offline device
Oct 27 18:22:29 kernel: [78221.092569] sd 3:0:0:0: rejecting I/O to offline device
Oct 27 18:22:29 kernel: [78221.097784] sd 3:0:0:0: rejecting I/O to offline device
Oct 27 18:22:29 kernel: [78221.102996] end_request: I/O error, dev sdd, sector 9437184
Oct 27 18:22:29 kernel: [78221.108558] md: super_written gets error=-5, uptodate=0
Oct 27 18:22:29 kernel: [78221.113774] raid5: Disk failure on sdd3, disabling device. Operation continu ing on 2 devices

Beide Platten hatten ein Dirtyflag ???

Ein SMART Test sagt alles OK. Naja, mal sehen...

Ich hoffe nicht, dass es an der FW 1354 liegt. Die hatte ich ein paar Tage zuvor installiert.
 

Anhänge

  • Unbenannt.JPG
    Unbenannt.JPG
    57 KB · Aufrufe: 138

randfee

Benutzer
Mitglied seit
08. Apr 2010
Beiträge
1.070
Punkte für Reaktionen
3
Punkte
64
hast du den Synology-Support vorher kontaktiert. Die sind 1. da ziemlich schnell und hätten dir 2. bestimmt enthusiastisch weitergeholfen. 3. wenn es ein FW Problem ist, dann wären die dafür auch noch dankbar.

Kein Plan, was das verursacht haben könnte.
 

GuethnerA

Benutzer
Mitglied seit
06. Jul 2011
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
RAID5 unter Knoppix retten

Hallo,
bei mir hat ein Blitzeinschlag den Netzwerkanschluß der CS407e zerstört. Alle 4 Platten scheinen ok. Deshalb Rettungsversuch unter Knoppix.
Ich habe 3x 1TB als RAID5 sowie 1x 2TB als single.
Die Rettung der 2TB-Platte ging problemlos, so wie von Talon beschrieben.
Bei der Rettung des RAID5-Verbunds gibt es aber Probleme.
Der Befehl mdadm --examine /dev/sda3 liefert vernünftige Angaben, RAID5 erkannt (sdb3, sdc3 ebenso).
Will ich aber mit mdadm --assemble die Laufwerke verbinden erschein die Meldung:

"mdadm: cannot open device /dev/sda3 : device or resource busy"
"mdadm: /dev/sda3 has no superblock - assembly aborted"

Die zweite Zeile resultiert vermutlich aus Zeile 1, schließlich zeigt examine den Superblock aller 3 Laufwerke an.
Was mache ich falsch ? Bitte um Hilfe.
Gibt es eine Möglichkeit, auf die Daten in der CS407e zuzugreifen (ohne Netzwerk, da die Netzwerkkarte ja geschossen ist) ?
Kann ich die Platten in eine aktuelle CubeStation einbauen und dort die Daten lesen ?
Kann mir ev. jemand eine CS407e ausleihen ?
GuethnerA
 

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
13.999
Punkte für Reaktionen
264
Punkte
373
Hallo,
Gibt es eine Möglichkeit, auf die Daten in der CS407e zuzugreifen (ohne Netzwerk, da die Netzwerkkarte ja geschossen ist) ?
die einzige Möglichkeit ist die serielle Konsole. Auf dem Mainboard gibt einen Block mit 6 Pins (meist JP1), dort kann man auf die serielle Konsole zugreifen (ACHTUNG 3,3V Level).
Bauanleitung für das benötigte Kabel.

Wenn die CS das Raid zumindest lesend bereitstellen kann, kannst Du per Konsole auf eine USB Disk sichern.

Gruß Götz
 

GuethnerA

Benutzer
Mitglied seit
06. Jul 2011
Beiträge
2
Punkte für Reaktionen
0
Punkte
0
Datenrettung mit Knoppix erfolgreich durchgeführt

Hallo,
bei mir ist die CS407e durch einen Blitzeinschlag zerstört worden. Die Netzwerkkarte auf der Platine ist komplett verbrannt.
Also wie von TALON so toll beschrieben per Knoppix die Datenrettung gestartet.
Meine Konfiguration:
- 1x 2TB Platte als Single-Laufwerk
- 3x 1TB als RAID5-Verbund

Erster Stolperstein:
Die 2TB-Platte mußte ich mit "mdadm --assemble /dev/md/2 /dev/sda3" einbinden, obwohl es sich ja um kein RAID handelt. Hat dann aber problemlos funktioniert.
Zweiter Stolperstein:
Daten also in Linux per MC auf die externe NTFS-Festplatte kopiert. Das war vermutlich weniger klug (NTFS als Ziel), da Linux alles einfach so draufgepackt hat. Die CS407e hat aber in den Verzeichnissen des DLNA-Servers (\music \video \picture) zusatzinfos abgelegt (Verzeichnisse @eadir). Diese Verzeichnisse enthalten Dateien mit Namen, die nicht Windowskompatibel sind (z.B. "film1:3.jpg"). Durch den doppelpunkt ":" im Dateinamen kann Windows später nicht mehr auf die Dateien zugreifen, auch nicht löschen. Die Dateien sind aber kein Verlust, da vom CS407e automatisch angelegt. ChkDsk findet diese Dateien und beseitigt die Fehler, die Dateien sind dann allerdings unbrauchbar, weil Dateiname file#####.*.

Mehr Probleme gab es bei der Rettung der Daten vom RAID5-Verbund. der Befehl "mdadm --examine" lieferte einwandfreie Superblocks, die Festplatten waren also unbeschädigt. Der Befehl "mdadm --assemble /dev/md/2 /dev/sd[abc]3" lieferte aber immer folgende Fehlermeldung:
"mdadm: cannot open device /dev/sda3 : device or resource busy"
Nach längerem Suchen fand ich unter GPARTED folgendes Laufwerk "/dev/mapper/pdc_ceejhcaeaa3".
Die Partitionsstruktur lief darauf schließen, dass dies ein zusammengesetztes Laufwerk aus meinen 3 RAID5-Platten ist, und so die Festplatten für mdadm sperrt. Der Befehl "dmraid" scheint für solche MAPPER-Laufwerke verantwortlich zu sein. Leider konnte ich damit aber nichts erreichen, das gemappte Laufwerk enthielt aber keine Daten.

Lösung:
Entgegen der Empfehlung von TALON habe ich die Festplatten nicht in der Orginalreihenfolge verbaut. Das brachte zuerst nichts, das MAPPER-Laufwerk erschien weiterhin, selbst dann, wenn ich die Festplatten einzeln per USB-Gehäuse dynamisch an Knoppix angemeldet hatte (nach Reihenfolge). Erst als das Laufwerk 1 ganz weggelassen habe (und auch das Ziellaufwerk, also nur 2 Platten im System), erschien das MAPPER-Laufwerk nicht mehr. Also nochmal per "mdadm --assemble /dev/md/2 /dev/sd[bc]3 --run" das RAID5 zusammengeschaltet, un siehe das, es geht. Mit mount einbinden und mit MC kopieren (vorher Ziel-Festplatte per USB anbinden) war dann ein Kinderspiel.

Mann bin ich froh, meine Daten wieder zu haben. Danke an das Synology-Team sowie an TALON für die gute Anleitung.
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
Mann bin ich froh, meine Daten wieder zu haben.

... und wir lernen daraus, man kann mit viel Aufwand und Stress seine Daten retten, aber eine gute Backup-Strategie hätte alles viel einfacher gemacht ...

Itari
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat