awunschik

ASRock J4105-ITX SATA-Controller DEFEKT

Recommended Posts

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é
 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 😩

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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? 

POOL.jpg

POOL2.jpg

Share this post


Link to post
Share on other sites
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é

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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 😜

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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 by IG-88

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites
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 by IG-88
  • Thanks 1

Share this post


Link to post
Share on other sites

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é

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

 

Bild.jpg

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Na dann werde ich das mal hier posten, wenn alles durchgelaufen ist...
Vermutlich in 3 Tagen oder so.

Schönen Feierabend!

Share this post


Link to post
Share on other sites

So alles ist durch.
Wie auf den Bildern zu sehen aber ergebnislos.
Ich habe jetzt keine Log-Dateien finden können.
Muss weitersuchen...

1.jpg

2.jpg

3.jpg

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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.

1.jpg

2.jpg

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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"

 

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.