awunschik Posted January 21, 2020 Share #1 Posted January 21, 2020 Hi! Ich betreibe seit ca.einem halben Jahr ein Eigenbau-NAS, auf dem Xpenology installiert ist. Hier die Spezifikationen:ASRock J4105-ITX Inter-Tech IPC SC-4100 Wuerfel 250 Watt Inter-Tech 8192MB Samsung M471A5244CB0-CRCD0 DDR4-2400 SO-DIMM CL17-17-17 Single 4x Seagate Archive HDD 8TB Installiert ist Xpenology auf einem 8 GB Platinum USB-Stick. Als Speicherkonfiguration habe ich diese Synology-Geschichte genommen mit der "Ausfallsicherheit" von einer HDD. Das System lief 24/7 ohne Probleme, bis mir letzten Freitag das Betriebssystem meldete, dass der Speicherpool ausgefallen sei, oder so. Ich habe dann zu Hause auch gleich gesehen, dass die LEDs der Trays 3 und 4 nicht mehr leuchteten. Nach einigen Test mit anderem Netzteil und dergleichen, ist mir dann aufgefallen, dass die zwei Festplatten am 2. SATA-Controller des Boards hängen. Laut Benutzerhandbuch handelt es sich um den ASMedia (vermute ich). • 2 x SATA3 6.0 Gb/s Connectors, support NCQ, AHCI and Hot Plug• 2 x SATA3 6.0 Gb/s Connectors by ASMedia ASM1061, support NCQ, AHCI and Hot Plug Die Festplatten werden von anderen Rechnern und den anderen 2 Anschlüssen noch erkannt. Und nun zu meiner eigentlichen Frage: Wie komme ich wieder an meine Daten? Also wie kann ich das System wieder zum Laufen bringen. Es geht mir darum, dass der Speicherpool wieder erkannt wird. Hier meine Fragen im Einzelnen: 1. Da auf das Board noch Garantie ist, wäre eine Reklamation möglich. Wäre das die beste Lösung? Ich weiß ja nicht, ob die Taiwanesen da großes Geschiss machen, und den SATA-Controller reparieren oder nicht doch das ganze Mainboard wechseln. 2. Würde es auch funktionieren, einen PCI-E-Controller zu installieren, der die Platten dann anspricht? Ich brauch Hilfe von erfahrenen Benutzern, die sich damit auskennen. Vielen Dank im Voraus! LG André Quote Link to comment Share on other sites More sharing options...
jensmander Posted January 22, 2020 Share #2 Posted January 22, 2020 Schon mal mit einem alternativen Boot Stick getestet (Live Linux o.ä.), ob an den besagten Ports wirklich keine HDDs mehr erkannt werden? Nur um XPEnology als Verursacher ausschließen zu können. Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 22, 2020 Author Share #3 Posted January 22, 2020 3 minutes ago, jensmander said: Schon mal mit einem alternativen Boot Stick getestet (Live Linux o.ä.), ob an den besagten Ports wirklich keine HDDs mehr erkannt werden? Nur um XPEnology als Verursacher ausschließen zu können. Danke für Deine Antwort! Ich habe im BIOS die Anzeige für die 4 SATA-Ports. Port 1 und 2 erkennt alle vier Platten (nach Neustart und umstecken). Port 3 und 4 erkennt keine Platte mehr (laut BIOS). Deshalb die Vermutung des defekten Controllers. Nun habe ich erstmal einen 4-fach PCI-E-Controller bestellt und hoffe, dass das Ganze damit wieder funktioniert 😩 Quote Link to comment Share on other sites More sharing options...
jensmander Posted January 22, 2020 Share #4 Posted January 22, 2020 Hm. Wenn das BIOS schon nix mehr anzeigt... Wenn es nicht gerade ein Controller mit Port Multiplier und exotischem Chipsatz ist, sollte es fluppen. Ggf. musst Du (falls die HDDs in DSM am Controller nicht erkannt oder angezeigt werden) das Sata Port Mapping in der grub.cfg anpassen oder Du deaktivierst alle onboard Ports und klemmst alle HDDs an den Controller. Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 23, 2020 Author Share #5 Posted January 23, 2020 Ich habe den Controller eingebaut und alles angeschlossen. Jetzt meldet mir DSM im INFO-Center, dass die Systempartitionierung der zwei oben erwähnten Festplatten fehlgeschlagen sei. Wenn ich nun den Speicher-Manager öffne, wird mir gesagt Speicherpool 1 sei abgestürzt. Nun schlägt DSM eine Sichererung meiner Daten und eine darauf folgende Reperatur vor. Jetzt stehe ich vor dem Problem, die Daten nicht sichern zu können, weil ich nicht ran komme 🙄 Ich befürchte, dass wenn ich einfach auf Reparieren gehe, meine Daten futsch sind. Weiß jemand einen Rat? Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 23, 2020 Share #6 Posted January 23, 2020 lies doch mal diesen noch laufenden fall, ist sehr lehrreich (nicht nur in bezug auf die frage ob man ein backup braucht) https://xpenology.com/forum/topic/24525-help-save-my-55tb-shr1-or-mount-it-via-ubuntu/?do=getNewComment Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 24, 2020 Author Share #7 Posted January 24, 2020 11 hours ago, IG-88 said: lies doch mal diesen noch laufenden fall, ist sehr lehrreich (nicht nur in bezug auf die frage ob man ein backup braucht) https://xpenology.com/forum/topic/24525-help-save-my-55tb-shr1-or-mount-it-via-ubuntu/?do=getNewComment Danke Dir! Ich will jetzt auch echt nicht auf doof machen, aber bringt mich das weiter den Beitrag zu studieren? Versteh mich bitte nicht falsch - ich will nicht, dass mir die gebratenen Tauben in den Mund fliegen, nur habe ich gerade ganz wenig Zeit mich weiter zu bilden. hab da mal kurz reingelesen und es sind bömische Dörfer für mich 😫 Was ich für Fehler gemacht habe, das ist mir nun einigermaßen klar. Ich habe nicht den Ernstfall eines Hardwareausfalls in Form des Controllers gedacht und das falsche "System" in Form von "Ausfllsicherheit 1 von 4 gewählt". Also hilft mir der von dir verlinkte Beitrag? LG André Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 24, 2020 Share #8 Posted January 24, 2020 58 minutes ago, awunschik said: ch habe nicht den Ernstfall eines Hardwareausfalls in Form des Controllers gedacht und das falsche "System" in Form von "Ausfllsicherheit 1 von 4 gewählt". Also hilft mir der von dir verlinkte Beitrag? ich dachte da eher an die mdstat und mdadm sachen um sich über den zustand des raids zu verschaffen, bei 4 platten macht man normalerweise nur eine platte redundanz (er hatte 13 platten da sind eher 2 angesagt) und backup wäre der punkt den du eben nicht hasst, ersatzhardware kann man relativ zeitnah kaufen, da muss man nichts vorhalten raid zu haben deckt eben nur ein begranztes feld ab und wenn du jetzt zeitnah ein raid reparieren willst wirst du dich damit beschäftigen müssen, die alternative ist es erst mal so liegen zu lassen die platten aus dem raid haben einen status der angibt wie viel "unterschied" es beim schreiben gab/gibt (sie sind nicht in sync) und wenn du eine platte manuell in das raid "zwingst" und dabei einen gewissen verlust in kauf nimmst dann sollte man die bessere der beiden platten nehmen (klar das du in dem fall auch eine fuktionierende hardware als grundlage bauchst, in dem fall eben auch gut zu sehen das alls die arbeit für die katz ist wenn man die ursache des problems nicht beseitigt) Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 24, 2020 Author Share #9 Posted January 24, 2020 9 hours ago, IG-88 said: ich dachte da eher an die mdstat und mdadm sachen um sich über den zustand des raids zu verschaffen, ... mdstat spuckt das aus: Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sda5[0] sdb5[1] 23427586368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/2] [UU__] md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] 2097088 blocks [16/4] [UUUU____________] md0 : active raid1 sda1[0] sdb1[1] 2490176 blocks [16/2] [UU______________] unused devices: <none> Und bei mdadm kommt Folgendes: mdadm: Found some drive for an array that is already active: /dev/md2 mdadm: giving up. mdadm: No arrays found in config file or automatically Ich habe keine Ahnung was ich hier tue 😜 Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 25, 2020 Share #10 Posted January 25, 2020 mal vorausgesetzt du hast alle 4 platten online (ersatzcontroller für die 2 ausgefallenen sata ports), kannst du ja mal folgende befehle absetzen fdisk -l ls /dev/sd* mdadm --detail /dev/md2 mdadm --examine /dev/sd[abcd]5 | egrep 'Event|/dev/sd' /dev/md0 /dev/md1 sind system und swap, die laufen soweit erst mal, da das system ja startet und in dem raid1 /dev/md0 sind 2 von 4 platten aktiv, es gibt also nocjh eine als redundanz der letze befehl gibt sowas wie die sequenz nummer bei den schreibvorgängen an, in einem funktionierenden raid sind die gleich, bei dir müssten sda5 und sdb5 gleich sein und bei sdc5 und sdd5 stecht was anderes und wenn man eine platte in das raid "zwingt" dann die mit der höheren zahl die näher an a/b lieg, das minimiert den verlust wenn 3 von 4 im raid sind hätte man ein funktionierendes raid des wegen einer fehlenden platte degraded ist Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 25, 2020 Author Share #11 Posted January 25, 2020 Danke Dir erstmal das du Geduld mit mir hast und dran bleibst! So sieht das ganze aus nach Eingabe der vier Befehle.Wie "zwinge" ich denn die Platten wieder in das RAID? sudo fdisk -l Disk /dev/ram0: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram1: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram2: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram3: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram4: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram5: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram6: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram7: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram8: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram9: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram10: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram11: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram12: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram13: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram14: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram15: 640 MiB, 671088640 bytes, 1310720 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 588A26DF-FB20-4482-B28A-43DA8F2F8A90 Device Start End Sectors Size Type /dev/sda1 2048 4982527 4980480 2.4G Linux RAID /dev/sda2 4982528 9176831 4194304 2G Linux RAID /dev/sda5 9453280 15627846239 15618392960 7.3T Linux RAID Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 37888397-2EFF-4A0B-968B-E0ABCB2E4FB0 Device Start End Sectors Size Type /dev/sdb1 2048 4982527 4980480 2.4G Linux RAID /dev/sdb2 4982528 9176831 4194304 2G Linux RAID /dev/sdb5 9453280 15627846239 15618392960 7.3T Linux RAID Disk /dev/sdc: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: 36512BBE-A2AA-4999-B0D5-FB290FA7D8B5 Device Start End Sectors Size Type /dev/sdc1 2048 4982527 4980480 2.4G Linux RAID /dev/sdc2 4982528 9176831 4194304 2G Linux RAID /dev/sdc5 9453280 15627846239 15618392960 7.3T Linux RAID Disk /dev/sdd: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: E2E136EE-927C-4859-B486-F1C10983B92A Device Start End Sectors Size Type /dev/sdd1 2048 4982527 4980480 2.4G Linux RAID /dev/sdd2 4982528 9176831 4194304 2G Linux RAID /dev/sdd5 9453280 15627846239 15618392960 7.3T Linux RAID Disk /dev/md0: 2.4 GiB, 2549940224 bytes, 4980352 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/md1: 2 GiB, 2147418112 bytes, 4194176 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes GPT PMBR size mismatch (102399 != 15257599) will be corrected by w(rite). Disk /dev/synoboot: 7.3 GiB, 7811891200 bytes, 15257600 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 52173969-41B8-4EDB-9190-B1CE75FCFA11 Device Start End Sectors Size Type /dev/synoboot1 2048 32767 30720 15M EFI System /dev/synoboot2 32768 94207 61440 30M Linux filesystem /dev/synoboot3 94208 102366 8159 4M BIOS boot Disk /dev/zram0: 1.1 GiB, 1199570944 bytes, 292864 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 1.1 GiB, 1199570944 bytes, 292864 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram2: 1.1 GiB, 1199570944 bytes, 292864 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram3: 1.1 GiB, 1199570944 bytes, 292864 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes ls /dev/sd* /dev/sda /dev/sda5 /dev/sdb2 /dev/sdc1 /dev/sdd /dev/sdd5 /dev/sda1 /dev/sdb /dev/sdb5 /dev/sdc2 /dev/sdd1 /dev/sda2 /dev/sdb1 /dev/sdc /dev/sdc5 /dev/sdd2 sudo mdadm --detail /dev/md2 Version : 1.2 Creation Time : Sun Jun 2 22:53:00 2019 Raid Level : raid5 Array Size : 23427586368 (22342.29 GiB 23989.85 GB) Used Dev Size : 7809195456 (7447.43 GiB 7996.62 GB) Raid Devices : 4 Total Devices : 2 Persistence : Superblock is persistent Update Time : Sat Jan 25 15:27:15 2020 State : clean, FAILED Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : NAS_DS918plus:2 (local to host NAS_DS918plus) UUID : 96879d75:bd06edee:8c1bd43a:3702eb17 Events : 2790 Number Major Minor RaidDevice State 0 8 5 0 active sync /dev/sda5 1 8 21 1 active sync /dev/sdb5 - 0 0 2 removed - 0 0 3 removed sudo mdadm --examine /dev/sd[abcd]5 | egrep 'Event|/dev/sd' /dev/sda5: Events : 2790 /dev/sdb5: Events : 2790 /dev/sdc5: Events : 2746 /dev/sdd5: Events : 2746 Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 25, 2020 Share #12 Posted January 25, 2020 (edited) 10 hours ago, awunschik said: Wie "zwinge" ich denn die Platten wieder in das RAID? so wie hier (ich kopiere im wesentlichen nur was da steht und passe es an deine 4 laufwerke an, in dem anderen fall sind es 13 platten) https://xpenology.com/forum/topic/24525-help-save-my-55tb-shr1-or-mount-it-via-ubuntu/?do=findComment&comment=131382 die ergebnisse sehen erst mal wie erwartet aus und deine platten die nicht mehr im raid sind (sdc und sdd) haben beide den gleichen stand, ist also egal welche von beiden man nimmt um das raid wiederherstzstellen, der verlust ist der gleiche (44 Blöcke a 64kB) mdadm --stop /dev/md2 mdadm --assemble --force /dev/md2 /dev/sd[abc]5 in dem fall zwingt man (--force) die dritte platte in das raid und nimmt den verlust von 44 blöcken in kauf wenn das filesystem btrfs ist kann beim konsistez check an hand der prüfsummern zumindest feststellen lassen welche files nicht so sind wie sie sein sollten cat /proc/mdstat mdadm --detail /dev/md2 jetzt noch mal den zustand prüfen und danach würde man das 4. laufwerk dem raid hinzufügen um die redundanz wiederherzustellen (was dann einige zeit dauert da er ja die redudanz daten aus den drei laufwerken neu erzeugen muss - aber das ist noch zu früh, erst mal sehen beim assemble raus kommt Edited January 26, 2020 by IG-88 Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 27, 2020 Author Share #13 Posted January 27, 2020 sudo mdadm --stop /dev/md2 mdadm: stopped /dev/md2 sudo mdadm --assemble --force /dev/md2 /dev/sd[abc]5 mdadm: forcing event count in /dev/sdc5(2) from 2746 upto 2797 mdadm: /dev/md2 has been started with 3 drives (out of 4). cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sda5[0] sdc5[2] sdb5[1] 23427586368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [UUU_] md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] 2097088 blocks [16/4] [UUUU____________] md0 : active raid1 sda1[0] sdb1[1] 2490176 blocks [16/2] [UU______________] unused devices: <none> sudo mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sun Jun 2 22:53:00 2019 Raid Level : raid5 Array Size : 23427586368 (22342.29 GiB 23989.85 GB) Used Dev Size : 7809195456 (7447.43 GiB 7996.62 GB) Raid Devices : 4 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Jan 27 11:20:04 2020 State : clean, degraded Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : NAS_DS918plus:2 (local to host NAS_DS918plus) UUID : 96879d75:bd06edee:8c1bd43a:3702eb17 Events : 2798 Number Major Minor RaidDevice State 0 8 5 0 active sync /dev/sda5 1 8 21 1 active sync /dev/sdb5 2 8 37 2 active sync /dev/sdc5 - 0 0 3 removed --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- sudo mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sun Jun 2 22:53:00 2019 Raid Level : raid5 Array Size : 23427586368 (22342.29 GiB 23989.85 GB) Used Dev Size : 7809195456 (7447.43 GiB 7996.62 GB) Raid Devices : 4 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Jan 27 11:20:04 2020 State : clean, degraded Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : NAS_DS918plus:2 (local to host NAS_DS918plus) UUID : 96879d75:bd06edee:8c1bd43a:3702eb17 Events : 2798 Number Major Minor RaidDevice State 0 8 5 0 active sync /dev/sda5 1 8 21 1 active sync /dev/sdb5 2 8 37 2 active sync /dev/sdc5 - 0 0 3 removed Soll ich das Ding jetzt neustarten? Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 27, 2020 Share #14 Posted January 27, 2020 (edited) 13 hours ago, awunschik said: Soll ich das Ding jetzt neustarten? ja, versuchs mal (der status des raid sollte nach dem neustart von crashed auf degraded geändert sein) danach würde man das 4. laufwerk normal hinzufügen so das ein raid rebuild läuft, kann man eigentlich dann auch auf der gui machen in dem man auf der raidgruppe das 4. laufwerk wieder hinuzfügt sollten danach noch systempartitionen als defekt angezeigt werden auch reparieren lassen, das ist nur raid1 und es gab ja 2 gültige partitionen, die anderen werden dann einfach dem raid1 hinzugefügt und dabei überschrieben, damit sind die wieder in sync Edited January 28, 2020 by IG-88 1 Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 28, 2020 Author Share #15 Posted January 28, 2020 Ein ganz ganz dickes fettes Danke für deine Geduld, investierte Zeit und deine kompetenten, schnellen Antworten! ✊ Es hat genau so funktioniert, wie du es beschrieben hast. Dank Dir habe ich wieder ein funktionierendes System praktisch ohne Datenverlust. 😁 Ich werde mir für die Zukunft vornehmen, mich da mal ein bisschen rein zu lesen. Herzliche Grüße André Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 28, 2020 Share #16 Posted January 28, 2020 10 hours ago, awunschik said: praktisch ohne Datenverlust. du merkst ih nur nicht, du solltest noch scrubing laufen lassen um evtuelle fehler durch die verluste zu finden, theoretisch findest du so raus welche dateien betroffen sind Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 28, 2020 Author Share #17 Posted January 28, 2020 20 minutes ago, IG-88 said: du merkst ih nur nicht, du solltest noch scrubing laufen lassen um evtuelle fehler durch die verluste zu finden, theoretisch findest du so raus welche dateien betroffen sind Ist das Scrubbing dann hier zu finden? Dann mache ich das wohl nach der Konsistenzprüfung? Oder besser über die Console? Quote Link to comment Share on other sites More sharing options...
IG-88 Posted January 28, 2020 Share #18 Posted January 28, 2020 alles ok, da bist du richtig, ich habe aber noch nicht gesehen was passiert wenn fehlerhafte dateien gefunden werden, in deinem fall sollte der prozess etwas finden auf jeden fall schauen ob/wo do ein log/bericht dazu findest Quote Link to comment Share on other sites More sharing options...
awunschik Posted January 28, 2020 Author Share #19 Posted January 28, 2020 Na dann werde ich das mal hier posten, wenn alles durchgelaufen ist... Vermutlich in 3 Tagen oder so. Schönen Feierabend! Quote Link to comment Share on other sites More sharing options...
awunschik Posted February 4, 2020 Author Share #20 Posted February 4, 2020 So alles ist durch. Wie auf den Bildern zu sehen aber ergebnislos. Ich habe jetzt keine Log-Dateien finden können. Muss weitersuchen... Quote Link to comment Share on other sites More sharing options...
IG-88 Posted February 4, 2020 Share #21 Posted February 4, 2020 ist es denn aktiviert bei deinem system? beim erzeugen eines shares kann/sollte man das aktivieren 3. tab bei einem share (advanced) https://blog.synology.com/how-data-scrubbing-protects-against-data-corruption/ soweit ich das nachlesen konnte würde man das in dem paket "Log Center" nachher finden Quote Link to comment Share on other sites More sharing options...
awunschik Posted February 5, 2020 Author Share #22 Posted February 5, 2020 10 hours ago, IG-88 said: ist es denn aktiviert bei deinem system? beim erzeugen eines shares kann/sollte man das aktivieren 3. tab bei einem share (advanced) Ja ich habe es aktiviert. Also wenn damit der Datenintegritätsschutz der gemeinsamen Ordner gemeint ist (siehe Bild 1) 10 hours ago, IG-88 said: soweit ich das nachlesen konnte würde man das in dem paket "Log Center" nachher finden Ich habe das Paket "Protokoll-Center" nachinstalliert. Der Inhalt zeigt mir jedoch lediglich, dass das Scrubbing statt gefunden hat. Ein Ergebnis lässt sich aber nicht auslesen... Bild zwei zeigt einen HTML-Export. Quote Link to comment Share on other sites More sharing options...
Donny05 Posted February 28, 2020 Share #23 Posted February 28, 2020 Hallo, ich will mir ein J4105 System zulegen. Um mehr als 4 Sata Ports zu haben will ich einen Sata Controller verbauen. Gibt es Empfehlungen welches Modell man am besten verwenden sollte? Danke vorab. Quote Link to comment Share on other sites More sharing options...
IG-88 Posted February 29, 2020 Share #24 Posted February 29, 2020 On 2/28/2020 at 12:50 PM, Donny05 said: ich will mir ein J4105 System zulegen. Um mehr als 4 Sata Ports zu haben will ich einen Sata Controller verbauen. Gibt es Empfehlungen welches Modell man am besten verwenden sollte? was hat das jetzt mit der topic zu tun? dein controller ist nicht defekt und deine platten sind nicht aus dem raid gefallen bitte mach für ein neues thema auch einen neuen tread auf, ganz oben rechts in der übersicht, "stat new topic" Quote Link to comment Share on other sites More sharing options...
apejovic Posted July 26, 2020 Share #25 Posted July 26, 2020 Hi! @awunschik Kannst Du mir ein paar Screenshots bzw. Bilder von deinen BIOS-Einstellungen machen? Hatte jetzt das exakte Problem wie Du (ebenfalls J4105-ITX mit 120W picu PSU). Allerdings vermute ich ein paar BIOS Einstellungen hinter dem Problem. Ich konnte eine HDD aus dem Raid entfernen, in einem anderen System (DS214play) auf Fehler überprüfen (alles ok), formartieren und das Raid in dem Xpenology-Nas wieder über die Reparaturoption herstellen. Bei mir waren stromsparende Optionen aktiviert. Vermute, daß diese, zu dem aussteigen des Raids geführt haben. Ich bin davon ausgegangen, daß diese nur mit einem Betriebssystem a la Windows oder Linux greifen. Mal schauen ob das jetzt Abhilfe gebracht hat. Werde bei Gelegenheit meine BIOS-Einstellungen hochladen. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.