[how-to] Defektes Raid-5 wiederherstellen

Supaman · 27. Jul 2007

was war passiert:

config: cs406 mit 4x 500 gb @raid-5

beim starten der platten aus dem hibernation mode ist platte #4 nicht aufgewacht -> cs406 meckert, raid-redunanz nicht mehr da. cube station neu gestartet, übers web-interface gestartet, alles wieder gut.

einen tag später: selber effekt, platte #4 wacht nach hbernation mode nicht auf, box neu gestartet, nur ist dieses mal beim neustart die platte #1 zusätzlich ausgefallen -> 2 platten ausgefallen -> raid defekt und per webinterface nicht reparierbar.

(wie ich später gesehen habe, war die ursache das der stromstecker nicht richtig drin war)

da auf dem raid keine schreibzugriffe stattgefunden haben zur der zeit, *mussten* die daten noch ok sein, nur das raid war als "ungültig" deklariert. ich hab dann zur sicherheit erstmal 1:1 kopieren der platten an einem anderen rechner gemacht.

der rest war einfacher als ich dachte:

ACHTUNG: einloggen als "root", nicht als "admin" - das passwort ist das gleiche!
(weil halbfett anscheinend nicht reicht, jetzt in EXTRA groß und roter farbe... )

raid stoppen:
mdadm --stop /dev/md2

raid reparieren für 4-platten systeme (CS-406, CS-407, DS-408)
mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3

raid reparieren für 5-platten systeme (DS-508):
mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3

dauert nur ein paar sekunden, es werden ein paar meldungen ausgegeben, sofern möglich wird der superblock neu geschrieben.

den status kann überprüfen mit
mdadm --query --detail /dev/md2

neu starten, das "volume1" sollte jetzt wieder verfügbar sein. dann letzte platte übers webinterface reparieren (syncen) lassen und alles ist wieder ok.

mein persönlicher erfahrungsbericht, alle angaben ohne gewähr.

gruß,

supa

NocTec · 27. Jul 2007

Das hatte ich auch schonmal hier beschrieben:

http://www.synology-forum.de/showthread.html?t=261&highlight=mdadm

bjoernsøn · 13. Jan 2008

ähnliche situation

hi guys,

bitte nicht lachen über meine fragen - ich weiss es einfach nicht besser - trotzdem danke erst einmal für diese tolle anleitung - nur leider funktioniert diese bei mir nicht!

wenn ich mich über telnet an meiner rs-406 fw 2.0.3 0518 angemeldet habe & zb den befehl: "mdadm --stop /dev/md2" eingebe, kommt: permission denied! oder hätt' ich mich anders anmelden müssen?

was nun?

situation ist bei mir ähnlich wie von "supaman"

beschrieben, nur dass es bei mir während eines schreibzugriffes passierte.

PS.: eigentlich hatte ich gelesen, dass bei "mdadm --stop ..." alle daten verloren gehen würden? stimmt aber laut euren aussagen nicht. oder was ist nun richtig?

derverzweifelteNEWBYsoftwareRAIDrebuilder

Rca1234 · 13. Jan 2008

Hi bjoernsøn,

hast Du dich als Benutzer "root" mit Deinem Admin-Passwort (das gleiche wie auf der Webconsole) eingeloggt. So sollte es gehen.

Zum Vorgehen an sich kann ich Dir leider nix sagen.

Grüße!

Supaman · 13. Jan 2008

du musst dich als "root" einloggen nicht als unterprivilegierter user. und das man an einem raid-system nur rumschrauben sollte, wenn es OFFLINE ist, sollte klar sein.. deshlab "mdadm --stop". da gehen keine daten verloren, das raid ist während der zeit nur nicht übers netzwerk zugreifbar.

bjoernsøn · 15. Jan 2008

danke für die raschen antworten! die schritte haben soweit nachvollziehbar geklappt, aber das resultat: volume1 weiterhin abgestürzt 0.00GB mit 3hdds.

hat noch jemand eine idee?

Rca1234 · 15. Jan 2008

Auch betroffen :-(

Hallo zusammen,

habe gestern hier noch selbst geantwortet, jetzt selbst das RAID 5 kaputt (4*250GB).
Ich schreibe auch hier im Thread weil meine Problematik so ähnlich wie bei Supaman und Bjornson ist und es vielleicht auch Bjornson helfen könnte. Hoffe das ist recht so.

Offenbar konnten bei mir die Platten nicht mehr erwachen. Da die Cubestation hing (kein Webinterface, nix, kein Ausschalten per blauem Knopf möglich) habe ich letztendlich den Strom kurz unterbrochen.

Nach dem Reboot piepen und die Meldung:

Volume [1] was degrade, please repair it.

Es lag laut Webmanagementtool angeblich an Platte 3, die bis zum Reboot nicht erkannt wurde.
Habe alle Steckern der vier Platten neu draufgesteckt, rebootet und das Volume über das Webmanagementtool repariert.
Im Systemlog stand dann:

System starts to repair Volume [1] with disk [3].

Dann war er recht schnell fertig (gefühlt 3 Minuten) aber offenbar nicht erfolgreich, im Log stand nun:

Volume [1] was crashed.

Seit dem stand im Volumemanager:
Dieses Volume kann nicht verwendet werden, bitte entfernen Sie es.

Habe mich dann per SSH eingeloggt, das RAID angehalten und dann den Trick von Supaman ausprobiert mit folgendem Ergebnis:

CubeStation> mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 4.
mdadm: /dev/sdd3 is identified as a member of /dev/md2, slot 3.
mdadm: added /dev/sdb3 to /dev/md2 as 1
mdadm: no uptodate device for slot 2 of /dev/md2
mdadm: added /dev/sdd3 to /dev/md2 as 3
mdadm: added /dev/sdc3 to /dev/md2 as 4
mdadm: added /dev/sda3 to /dev/md2 as 0
mdadm: /dev/md2 has been started with 3 drives (out of 4) and 1 spare.

Cubestation dann rebootet.

Es steht aber immer noch, daß das RAID nicht verwendet werden kann und entfernt werden muß. Dennoch steht bei allen vier Festplatten als Festplattenstatus: Normal.

Was kann ich tun? Meine Idee bis jetzt: noch eine Festplatte kaufen (mindestens auch 250GB), dann an Stelle der bemängelten dritten einbauen (Slot 2, richtig?).
Dann die CubeStation nochmal starten und hoffen dass sich was tut.

Könnt ihr auch mir bitte weiterhelfen? Was sagt ihr, was kann ich tun?

Viele Grüße,

Ralf

Supaman · 16. Jan 2008

mal eines vorweg: die beschriebene vorgehensweise ist dazu gedacht ein raid zu reparieren, das *eigentlich* ok sein müsste und nur von der raid-definiton defekt ist. nicht geeignet bei physikalischen defekten, was naheliegt wenn der repair mit fehler abbricht.

1. wenn dir deine daten lieb sind: mach eine 1:1 kopie jeder platte BEVOR du weiter rumprobierst.
2. die defekte platte auf jeden fall ersetzen
3. synology-support kontaktieren oder das ganze nochmal versuchen
4. falls nicht erfolgreich: versuchen die daten mit raid geeigneten tools zu recovern

Rca1234 · 16. Jan 2008

Hallo Supaman,

zunächst mal herzlichen Dank für Deine Antwort.

Habe mich noch ein bißchen mit dem Thema beschäftigt und mir auch mdadm ein bischen angeschaut.

Habe also heute:
- eine neue Platte gekauft
- die alte ausgebaut und neu gebootet -> dann sagt er wieder "degraded"
- die neue eingebaut und neu gebootet -> jetzt kann man wieder "Repair" drücken!
- dann habe ich also repariert und bin davor sitzen geblieben. Er war wieder nach kurzer Zeit fertig und behauptete "Einstellungen erfolgreich geändert".

Wieder im "Volume" Fenster, sehe ich immer noch "abgestürzt", aber alle Platten im Festplattenstatus: normal

Habe wieder neu gebootet, dachte vielleicht liegt es daran.
Also neu gebootet, wieder Piepen, wieder "crashed".

Dann habe ich mal in letzter Verzweiflung versucht den Status des RAID abzufragen, und jetzt staune ich (Status von jetzt):

CubeStation> mdadm --query --detail /dev/md2
/dev/md2:
Version : 00.90.03
Creation Time : Tue Dec 25 22:46:10 2007
Raid Level : raid5
Array Size : 728635776 (694.88 GiB 746.12 GB)
Device Size : 242878592 (231.63 GiB 248.71 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Wed Jan 16 20:51:58 2008
State : clean, degraded, recovering
Active Devices : 3
Working Devices : 4
Failed Devices : 0
Spare Devices : 1

Layout : left-symmetric
Chunk Size : 64K

Rebuild Status : 7% complete

UUID : 6717a492:6d8e6704:17f23fb9:fa70a163
Events : 0.307152

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/hda3
1 8 19 1 active sync /dev/hdb3
4 8 35 2 spare rebuilding /dev/hdc3
3 8 51 3 active sync /dev/hdd3

Gehe ich also recht in der Annahme, daß meine CubeStation fleißig dabei ist das Array wieder aufzubauen?
Dann müßte ich nur warten bis er fertig ist und könnte dann wieder arbeiten (und erstmal *komplett* sichern, hab bisher nur ne Teilsicherung)?
Das würde bedeuten, daß die Meldungen der CubeStation einfach irreführend wären, oder?

Und: geht das Volume nur, wenn alle vier Platten funktionieren? Dachte es läuft auch mit drei, nur langsamer.

Mich wundert nur, wieso da /dev/hda3, /dev/hdb3, /dev/hdc3, /dev/hdd3 steht. Dachte das wären /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3?

Und: in dem Webmanagementtool zeigt er bei Volume immer noch, daß Volume1 nicht nutzbar wäre und ersetzt werden müsse sowie Gesamtgröße 0 und Ungenutzte Größe 0.

@Supaman, was weißt Du mehr? Ist wieder alles ok wenn der Rebuild gelaufen ist?

@bjoernson: vielleicht geht es bei Dir auch so?

Viele Grüße,

Ralf

P.S.: Jetzt ist er bei 10%. Würde mal spontan mit 4 Stunden Aufbauzeit für die 230GB-Platte rechnen.

Rca1234 · 17. Jan 2008

Noch etwas mehr Hoffnung aber noch keine Lösung

Hallo zusammen,
besonders Supaman und auch björnson!

Nachdem ich meine Cube 4 Stunden habe werkeln lassen ist das RAID *grundsätzlich* wieder repariert:

CubeStation> cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md2 : active raid5 sda3[0] sdb3[1] sdc3[2] sdd3[3]
728635776 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
393472 blocks [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
787072 blocks [4/4] [UUUU]

unused devices: <none>

CubeStation> mdadm --query --detail /dev/md2
/dev/md2:
Version : 00.90.03
Creation Time : Tue Dec 25 22:46:10 2007
Raid Level : raid5
Array Size : 728635776 (694.88 GiB 746.12 GB)
Device Size : 242878592 (231.63 GiB 248.71 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Thu Jan 17 06:48:05 2008
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : 6717a492:6d8e6704:17f23fb9:fa70a163
Events : 0.307155

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/hda3
1 8 19 1 active sync /dev/hdb3
2 8 35 2 active sync /dev/hdc3
3 8 51 3 active sync /dev/hdd3
CubeStation>

Mit diesen beiden Befehlen sieht man wie gesagt auch den Status während des Recoverys.

Stand nun:
RAID ist wieder ok, Cube meldet in der Websoftware aber immer noch, daß das Volume1 crashed ist und ersetzt werden muß. Erst dann (!) habe ich die Cube runtergefahren und schaue heute abend wieder (also reboot erst heut abend).

(jetzt wirds auch für björnson wieder interessant)

Warum? Habe mal in die messages des Betriebssystems geschaut und festgestellt, daß die Cube da irgendwelche Dinge macht (da laufen viele Skripte wenn ich das richtig verstehe). Am Ende konnte jedenfalls Volume1 nicht gemountet werden. Ich vermute deshalb steht in der Websoftware auch, daß Volume1 kaputt ist.

@björnson *NATÜRLICH OHNE GEWÄHR*: Ich könnte mir denken, daß bei Dir die Situation ähnlich ist. Vielleicht magst Du auch einfach die Kiste einschalten und prüfen, ob sich Dein RAID selbsttätig recovered (falls Du es Dir zutraust. Hinweis: den Status des RAIDS abfragen zerstört *keine* Daten). Dann wärst Du quasi so weit wie ich jetzt auch.

Werde heute abend die Station neu booten und hoffen, daß es dann klappt.

Frage nur: was, wenn Volume1 immer noch nicht gemountet werden kann, was kann man dann tun?
Bei nem "normalen" Laufwerk könnte man fsck aufrufen aber wie ist das bei dieseem RAID?

Viele Grüße,

Ralf

Supaman · 17. Jan 2008

@björnson
klaro, es gibt immer möglichkeiten...
- synology support fragen
- das hier ausprobieren: http://www.synology-forum.de/showthread.html?t=261&highlight=mdadm
- platten an windows pc anschliessen und mit raid-fähigen datenrettungstools wie z.b. http://www.runtime.org/raid.htm das glück versuchen

wichtig: vorher 1:1 kopie machen

@rca1234
wichtig ist erstmal, das /dev/md2 konsistent ist, dann solltest du auch zugriff auf die daten habe. wenn das der fall ist, mach eine datensicherung und setz das system von grund neu auf. ein raid, das im webinterface als "crashed" angezeigt wird ob wohl ers funktioniert wäre mir nicht geheuer.

Rca1234 · 18. Jan 2008

Gelöst

Hallo zusammen,

danke Supaman für Deine Hinweise. Das mit dem "Konsistenz" passte ganz gut zu dem was ich noch vorhatte: /var/log/messages ansehen.

Hier habe ich mal ausführlich aufgeschrieben wie ich das Problem nun lösen konnte. Vermutlich sind auch fast alle Daten wieder da/ganz, von einigen defekten Dateien abgesehen (naja, war halt nicht schnell genug mit meinem passenden Backup-Konzept).

P.S.: Falls ne deutsche Version gewünscht ist, kann ichs gern nochmal übersetzen.

bjoernsøn · 25. Jan 2008

gelöst?

hi alle zusammen,

1.) mensch ralf du warst ja echt aktiv in den letzten tagen & scheinst eine lösung gefunden zu haben!?

"As I do not have the possibility to copy the harddisks (only CubeStation supports SATA at my home, no additional harddisks), I finally decided to repair the defect filesystem. To me it appeared better to recover some data than no data.

So I checked the filesystem and it indeed was corrupt (I did not count but assume >>100 errors), so it was fixed.

After the next reboot CubeStation obviously was able to mount the Volume1 and reports that everything is fine."

könntest du die einzelnen schritte nochmal zusammenfassen? vorallem die im zitat sind für mich leider nicht nachvollziehbar!

& denkst du dass der plattenwechsel tatsächlich nötig gewesen ist? die platte war wahrscheinlich nicht defekt! oder?

& was das verursachende problem war ist auch unklar (klar die hd-sleep funktion), aber was hat ihn dann zum crash des raid gebracht & wieso konnte das passieren?

bin ich (nehmen wir an ich bekomme meine daten auch wieder recovert) vor einem erneuten ereigniss dieser art sicher, wenn ich die sleep-funktion rausnehme?

2.) synology-support wurde involviert. erst per mail, dann schaute ein engineer per telnet drauf. resultat: sehr geehrter kunde, da kann man von ferne nichts machen, wir bitten um einsendung des gerätes samt platten. Ziel: tawain (versandkosten werden übernommen). puuh - dacht ich mir ...

3.) würde gerne ein rohdaten-image (1:1 kopie) vorher ziehen wollen, bevor ich irgend etwas weiteres tue & ggf. von einem image die daten rauskopieren - dann wär ich glücklich.
wenn ich meine 4 platten an einen raidcontroller (XP, 4 chanel SATAII pci raid karte) anschliesse, sind alle partionen (1,2,3 plus 133mb nicht zugeordneter speicherplatz, 4 x wd5000ys) auf allen vier platten gleichmäßig vorhanden (in webinterface stand wie bei ralf - status ob - volume 1 crashed).
"raid reconstructor" finden nur kein signifikantes raid. weiss auch nicht wie dieses aufgebaut ist! sektoren 64k, rotation 3-2-1?

dervonMURPHYgebeutelte

Supaman · 25. Jan 2008

@björnson
vieles von dem was du wissen willst, ist hier bereits mehrfach genannt worden.

würde gerne ein rohdaten-image (1:1 kopie) vorher ziehen wollen

stichwort: mit linux cd booten, platte mit "DD" befehl kopieren

wenn ich meine 4 platten an einen raidcontroller (XP, 4 chanel SATAII pci raid karte) anschliesse, sind alle partionen (1,2,3 plus 133mb nicht zugeordneter speicherplatz

das dateiformat ist LINUX, nicht windows. ergo sieht windows da jede menge freien speicherplatz. und wenn du pech hast, hat windows schon auf den platten rumgematscht.

"raid reconstructor" finden nur kein signifikantes raid. weiss auch nicht wie dieses aufgebaut ist! 8 sektoren (4kb), rotation 1-2-3 forward und reihenfolge von links nach rechts wie sie eingebaut sind? kann da jemand weiterhelfen?

guckst du im post von rca1234:

State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : 6717a492:6d8e6704:17f23fb9:fa70a163
Events : 0.307155

was das mouten und auslesen eines synology raids angeht, so ist das hier die richtige anleitung: http://www.synology-forum.de/showthread.html?t=261&highlight=mdadm

bjoernsøn · 25. Jan 2008

weiterhin planlos

@rca1234

RackStation> cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md2 : active raid5 sdb3[1] sdc3[2] sdd3[3]
1461199872 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]

md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3]
393472 blocks [4/4] [UUUU]

md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3]
787072 blocks [4/4] [UUUU]

unused devices: <none>
RackStation> mdadm --query --detail /dev/md2
/dev/md2:
Version : 00.90.03
Creation Time : Fri Feb 13 11:36:28 2004
Raid Level : raid5
Array Size : 1461199872 (1393.51 GiB 1496.27 GB)
Device Size : 487066624 (464.50 GiB 498.76 GB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Fri Jan 25 19:08:14 2008
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : 806b7cc7:209505b6:d1927bb9:9b6b1f34
Events : 0.747679

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/hdc3
3 8 51 3 active sync /dev/hdd3
RackStation> mount -o ro /dev/md2 /mnt
mount: Mounting /dev/md2 on /mnt failed: Invalid argument

RackStation> /var/log/messages
-ash: /var/log/messages: Permission denied

wie denied?

so, es sieht also bei mir genauso aus wie bei dir. nur bei mir ist autorebuild nicht angesprungen.

wenn ich dich nun richtig verstehe - gibt es hier ein mounting problem, welches du mittels fsck.ext (oder wo mit?) gelöst hast. nutzt fsck.ext auch die info die in einem raid5 drinnen steckt (sprich die redundanz die auf den anderen partitionen hinterlegt ist), um die konsistenz wiederherzustellen?
sollte ich erst die erste platte wieder einbinden & fsck.ext durchführen oder umgekehrt.
wenn ich mir die "Built-in commands" anschaue:
-------------------
. : alias bg break cd chdir continue eval exec exit export false fg getopts hash help jobs kill let local pwd read readonly return set shift times trap true type ulimit umask unalias unset wait
frag' ich mich, wo steht dieser befehl?

@supaman
danke für die hinweise

Trolli · 25. Jan 2008

Der Befehl heisst fschk.ext3 und steht in /sbin/

bjoernsøn · 25. Jan 2008

uups

bjoernsøn schrieb:
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/hdc3
3 8 51 3 active sync /dev/hdd3

was is'n das?

Rca1234 · 25. Jan 2008

Hallo zusammen!

bjoernsøn;6041 schrieb:
hi alle zusammen,
1.) mensch ralf du warst ja echt aktiv in den letzten tagen & scheinst eine lösung gefunden zu haben!?

Sagen wir es so: sicher nicht *die* Patentlösung, aber habe wohl die Problematik verstanden und habe für mich eine erträgliche Lösung gefunden.

Meine Schadensbilanz ist übrigens folgende:
Share "public" wurde total zerstört, enthielt aber glücklicherweise nur "unwichtige" Daten. Schade aber gut verkraftbar.
Von allen anderen Shares (Foto, Musik, Homes...) habe ich vermutlich neun Dateien verloren - welche weiß ich noch nicht.
Mittlerweile gibt es ein "Komplettbackup".

könntest du die einzelnen schritte nochmal zusammenfassen? vorallem die im zitat sind für mich leider nicht nachvollziehbar!

Nochmal eins vorweg: derjenige mit der meisten Erfahrung hier ist sicher Supaman. Ich selbst habe die CubeStation erst seit Ende Dezember und konnte mir nur aufgrund des Forums hier, besonders aber aufgrund meiner SuSE-Linux Erfahrung von vorher helfen.

In dem von Dir zitierten Teil schreibe ich, daß nur meine Cube SATA kann (meine Arbeitsrechner sind alles alte Hunde bzw. ein Notebook). Von daher konnte ich meine Platten aus dem Cube weder unter Linux mounten noch vorher kopieren.
Deshalb habe ich mich dazu entschieden das defekte Filesystem meines RAID zu reparieren.

& denkst du dass der plattenwechsel tatsächlich nötig gewesen ist? die platte war wahrscheinlich nicht defekt! oder?

Vermutlich sind alle vier "alten" Platten ok, ja. Dennoch habe ich sie jetzt gegen vier aus der RAID-Edition von Western Digital ersetzt.

& was das verursachende problem war ist auch unklar (klar die hd-sleep funktion), aber was hat ihn dann zum crash des raid gebracht & wieso konnte das passieren?

Ich vermute folgende Kausalkette:
Auslöser: Platten gehen nicht korrekt in Schlafmodus bzw. mindestens eine Platte wacht nicht richtig auf
-> RAID5 degraded
-> Versuch der Korrektur via WebInterface (was auch immer da passiert)
-> Filesystem auf RAID5 korrupt; RAID5 kann nicht mehr gemountet (als Dateisystem eingebunden) werden, erscheint nurmehr als crashed

Mögliche Lösungen (meine persönliche Meinung):
1. Wenn möglich, die Platten des defekten RAID-Verbunds kopieren (wie Supaman ja auch immer wieder betont)
2. Volume neu aufbauen und Sicherung wieder einspielen (wenn man eine hat)
oder
2. Filesystem reparieren (z.B. weil man keine komplette Sicherung hat. ACHTUNG! Es kann zum Datenverlust bis hin zu komplettem Verlust aller Daten kommen).

bin ich (nehmen wir an ich bekomme meine daten auch wieder recovert) vor einem erneuten ereigniss dieser art sicher, wenn ich die sleep-funktion rausnehme?

Das würde ich auch gern wissen.
@Supaman, was sagst Du? Und wie finde ich heraus, ob meine Platten mit dem Sleep klarkommen?

2.) synology-support wurde involviert. erst per mail, dann schaute ein engineer per telnet drauf. resultat: sehr geehrter kunde, da kann man von ferne nichts machen, wir bitten um einsendung des gerätes samt platten. Ziel: tawain (versandkosten werden übernommen). puuh - dacht ich mir ...

Ich persönlich hätte da ein Problem mit. Aber wie gesagt, das muß jeder selbst wissen. Immerhin bietet nicht jeder diesen Service.

3.) würde gerne ein rohdaten-image (1:1 kopie) vorher ziehen wollen, bevor ich irgend etwas weiteres tue & ggf. von einem image die daten rauskopieren - dann wär ich glücklich.

Ja das schlagen ja auch Supaman und Trolli vor. Ich habe darauf verzichtet, weil ich die Möglichkeit halt nicht (ohne Weiteres) habe.

An Deiner Stelle würde ich - wie von Supaman und Trolli empfohlen und erläutert - Deine alten Platten auf vier neue kopieren. Dann würde ich auf den Originalplatten kopieren das Filesystem zu reparieren und schauen ob Du mit dem Erlebnis leben kannst.

wenn ich meine 4 platten an einen raidcontroller (XP, 4 chanel SATAII pci raid karte) anschliesse, sind alle partionen (1,2,3 plus 133mb nicht zugeordneter speicherplatz, 4 x wd5000ys) auf allen vier platten gleichmäßig vorhanden (in webinterface stand wie bei ralf - status ob - volume 1 crashed).
"raid reconstructor" finden nur kein signifikantes raid. weiss auch nicht wie dieses aufgebaut ist! sektoren 64k, rotation 3-2-1?

Hier hatte Supaman ja schon geantwortet.

Grüße,

Ralf

Rca1234 · 26. Jan 2008

Re!

bjoernsøn schrieb:
RackStation> cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md2 : active raid5 sdb3[1] sdc3[2] sdd3[3]
1461199872 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]

Hast Du Dein RAID5 / md2 aus drei Platten aufgebaut und Slot 1 gar nicht belegt?

... Update Time : Fri Jan 25 19:08:14 2008
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

(...)

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/hdc3
3 8 51 3 active sync /dev/hdd3

Warum /proc/mdstat und mdadm unterschiedliche Platten anzeigen hab ich auch noch nicht ganz kapiert. Macht jedenfalls nix und es sind natürlich dieselben. Ich gehe von Verknüpfungen aus (habs aber nicht untersucht).

RackStation> mount -o ro /dev/md2 /mnt
mount: Mounting /dev/md2 on /mnt failed: Invalid argument

Hatte ich auch, kommt wohl mit dem Filesystem nicht klar.

RackStation> /var/log/messages
-ash: /var/log/messages: Permission denied

wie denied?

Bist Du als root drauf? Dann musst Du messages sehen können!

so, es sieht also bei mir genauso aus wie bei dir. nur bei mir ist autorebuild nicht angesprungen.

...oder es ist schon längst gelaufen. Ist ja auch schon ne Weile her bei Dir, und wenn das Gerät lange genug lief...

wenn ich dich nun richtig verstehe - gibt es hier ein mounting problem, welches du mittels fsck.ext (oder wo mit?) gelöst hast. nutzt fsck.ext auch die info die in einem raid5 drinnen steckt (sprich die redundanz die auf den anderen partitionen hinterlegt ist), um die konsistenz wiederherzustellen?
sollte ich erst die erste platte wieder einbinden & fsck.ext durchführen oder umgekehrt.

Zu fsck auf ext3 siehe z.B. hier.
Also ich habe fsck auf md2 losgelassen (Befehl steht glaub ich irgendwo oben, den ich verwendet habe). ACHTUNG! Webb da Fehler beseitigt werden kann es zu großen Datenverlusten kommen. Dafür kannst Du nachher wieder mounten.

Aber wieviele Platten nutzt Du nun? 3 oder 4? Ich habe die vierte ja erst eingebunden, automatisch aufbauen lassen und dann das Filesystem repariert.
Dann gesichert und mittlerweile das Volume aus vier neuen Platten neu aufgebaut und rückgesichert.

Hoffe es hilft etwas, sonst frag gern weiter.

Grüße,

Ralf

Supaman · 26. Jan 2008

@Supaman, was sagst Du? Und wie finde ich heraus, ob meine Platten mit dem Sleep klarkommen?

das kannst du nur mit try & error ausprobieren.

RackStation> /var/log/messages
-ash: /var/log/messages: Permission denied

wie denied?

es muss heissen "cat /var/log/messages". einfach nur den pfad einzugeben ohne befehl davor bringt halt die o.g. fehlermeldung.

State : clean, degraded
Active Devices : 3
Working Devices : 3

Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 19 1 active sync /dev/sdb3
2 8 35 2 active sync /dev/hdc3
3 8 51 3 active sync /dev/hdd3

das gibt prinzipiell hoffnung. das raid ist funktionsfähig, die platte #1 (sda3) vorhanden, aber nicht zugeordnet. das hier "/dev/hdc3" + "/dev/hdd3" irritiert mich zwar etwas, muss aber nicht heissen. ich mache grade selber einen rebuild bei mir weil ich am "upgraden" bin, da sieht es so aus:

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/hda3
4 8 19 1 spare rebuilding /dev/sdb3
2 8 35 2 active sync /dev/hdc3
3 8 51 3 active sync /dev/hdd3

man beachte die unterschiedliche device kennzeichnung zwischen active-sync und der rebuild festplatte.

ich würde maö prüfen, ob /md2 gemounted ist bzw gemounted werden kann, die redunanz der 4ten platte ist dafür nicht erforderlich.

mount -o ro /dev/md2 /mnt

das ist vermutlich nicht der richtige befehl, wenn ich in mein /mnt auf der cs reinschaue, ist da kein /md2 zu sehen. die reine eingabe von "mount" zeigt das hier an:

NAS> mount
/dev/md0 on / type ext3 (rw,data=ordered)
/tmp on /tmp type tmpfs (rw)
/sys on /sys type sysfs (rw)
/proc/bus/usb on /proc/bus/usb type usbfs (rw)
/dev/md2 on /volume1 type ext3 (usrquota,grpquota)