Hallo zusammen,
mein TS-863U-RP (8*8TB RAID5) ist ausgefallen. Den genauen Grund kenne ich nicht. Vielleicht vollgelaufen, oder durch WOL geweckt worden heiß gelaufen.
Da das NAS auch nicht mehr hochfuhr, habe ich folgendes bisher erfolgreich durchgeführt:
Alle HDs entfernt
NAS gebootet
Die Platten eine nach der anderen eingeschoben
Mit Qfinder und der MAC-Adresse der verwendeten NIC als Passwort Zugang ermöglicht
SSH aktiviert
Ich kann mich nun per ssh einloggen, aber NICHT per Web (Login geht auf, aber die Zugangsdaten werden nicht akzeptiert)
Qos ist 4.5.3.1652
Nach dem Login habe ich md_checker laufen lassen. Das Raid ist im Status OFFLINE:
[~] # md_checker
Welcome to MD superblock checker (v2.0) - have a nice day~
Scanning system...
RAID metadata found!
UUID: 4f1565f2:a1a3739e:08a66542:98569df2
Level: raid5
Devices: 8
Name: md2
Chunk Size: 512K
md Version: 1.0
Creation Time: Feb 25 19:18:19 2019
Status: OFFLINE
===============================================================================================
Enclosure | Port | Block Dev Name | # | Status | Last Update Time | Events | Array State
===============================================================================================
NAS_HOST 1 /dev/sdb3 0 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
NAS_HOST 2 /dev/sdc3 1 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
NAS_HOST 3 /dev/sdd3 2 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
NAS_HOST 4 /dev/sde3 3 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
NAS_HOST 5 /dev/sdf3 4 Rebuild Jun 17 10:55:28 2021 467310 AAAAAAAA
NAS_HOST 6 /dev/sdg3 5 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
NAS_HOST 7 /dev/sdh3 6 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
NAS_HOST 8 /dev/sdi3 7 Active Jun 17 11:01:53 2021 467314 AAAA.AAA
===============================================================================================
[~] #
Alles anzeigen
Wie man sieht wurde ein md2 gefunden
/dev/sdf3 steht auf Rebuild
Leider rebuildet sich da nix von selber. Ich habe das NAS einige Tage angelassen. Der Zustand bleibt so.
Frage1:
Ich hatte bei einem vorigen Rettungsversuch eine andere Reihenfolge als b, c, d, e, f, g, h.
Hat das damit zu tun, im welcher Reihenfolge man die Platten einschiebt?
Dann habe ich versucht, das LVM zu starten. Klappt nicht, da das RAID wohl noch nicht online ist
[~] # /etc/init.d/init_lvm.sh
Changing old config name...
mv: can't rename '/etc/config/ssdcache.conf': No such file or directory
mv: can't rename '/etc/config/qlvm.conf': No such file or directory
mv: can't rename '/etc/config/qdrbd.conf': No such file or directory
mv: can't rename '/etc/config/raid.conf': No such file or directory
Reinitialing...
Detect disk(8, 0)...
ignore non-root enclosure disk(8, 0).
Detect disk(8, 16)...
dev_count ++ = 0Detect disk(8, 32)...
dev_count ++ = 1Detect disk(8, 48)...
dev_count ++ = 2Detect disk(8, 64)...
dev_count ++ = 3Detect disk(8, 80)...
dev_count ++ = 4Detect disk(8, 96)...
dev_count ++ = 5Detect disk(8, 112)...
dev_count ++ = 6Detect disk(8, 128)...
dev_count ++ = 7Detect disk(8, 0)...
ignore non-root enclosure disk(8, 0).
Detect disk(8, 16)...
Detect disk(8, 32)...
Detect disk(8, 48)...
Detect disk(8, 64)...
Detect disk(8, 80)...
Detect disk(8, 96)...
Detect disk(8, 112)...
Detect disk(8, 128)...
sh: /sys/block/sdb/device/qnap_param_latency: Permission denied
sh: /sys/block/sdc/device/qnap_param_latency: Permission denied
sh: /sys/block/sdd/device/qnap_param_latency: Permission denied
sh: /sys/block/sde/device/qnap_param_latency: Permission denied
sh: /sys/block/sdf/device/qnap_param_latency: Permission denied
sh: /sys/block/sdg/device/qnap_param_latency: Permission denied
sh: /sys/block/sdh/device/qnap_param_latency: Permission denied
sh: /sys/block/sdi/device/qnap_param_latency: Permission denied
sys_startup_p2:got called count = -1
/etc/init.d/init_lvm.sh: line 12: 20503 Segmentation fault /sbin/storage_util --sys_startup_p2
Done
Alles anzeigen
Next Step wäre doch, das RAID zusammenzubauen, damit es wieder ONLINE ist, oder?
also in meinem Fall:
mdadm -AfR /dev/md2 /dev/sdb3 /dev/sdc3 /dev/sdd3 /dev/sde3 /dev/sdf3 /dev/sdg3 /dev/sdh3 /dev/sdi3
Frage2:
muss die Reihenfolge die sein, die ich bei md_checker gesehen habe?
Ich habe im Netz widersprüchliches gelesen. Die einen sagen, dass die Platten ja eine ID mitbringen und es einen Superblock gibt.
Andere behaupten, wenn man hier einen Fehler macht, sei das RAID zerstört
Was mich richtig nervt ist, dass ich den Zustand nicht speichern kann. Beim nächsten booten muss ich wieder alle Platten ziehen und von vorn beginnen.
Frage3:
Kann ich einen Zwischenzustand so speichern, dass ich das NAS normal booten kann?
Frage4:
Was wären die nächsten Schritte, wenn das RAID wieder ONLINE ist?
Auf dem RAID liegt ja LVM-Kram
Hier einiges, das ich im Netz gefunden habe:
mdadm --detail /dev/md2
pvdisplay
vgdisplay
lvdisplay
pvs
Frage5:
Wenn ich am Ende wirklich das LVM gemountet bekomme, wie mach ich das ganze persistent, sodass ich normal booten kann?
Falls Ihr ganz anders vorgehen würdet, dann immer raus damit!
Vielen Dank für Eure Tipps schon mal im Voraus
Klaus