2 SHR Platten entfernt - piep - dann removed - wie nun wieder als volume aktivieren

[framp]

Meine DS418Play hat 4 Bay - 2 davon sind Produktion - die anderen fuer die Zukunft gedacht.

Darauf habe ich ein vol2 mit SHR erstellt und taeglich darauf ein Backup per Hyperbackup erstellt. Jetzt wollte ich mal testen was passiert wenn ich die beide rausziehe - piiiiiip - und ich habe das Volume dann removed. Wenn ich die beiden Platten wieder einstecke werden die Platten als 'not initialized' angezeigt. Gibt es keine Moeglichkeit das Volume wieder der Syno bekanntzumachen? Ich habe keine Moeglichkeit gefunden

 

[Fusion]

Ist nicht ganz klar was du genau gemacht hast.

Heißt 4 bay, dass du auch 4 Platten verbaut hast wie in der Signatur?
Und auf 3+4 hast du ein zweites SHR angelegt das dann als Volume 2 erscheint?
Und das hast du dann im Betrieb gezogen?
Und dann hast du dieses Volume im Speichermanager noch entfernt?

Dann war das letzte vermutlich der Fehler. Wenn er auch bei einem Neustart dieses RAID nicht mehr einbindet.
In der GUI gibt es keine Möglichkeit das rückgängig zu machen.

 

[RichardB]

Ich hatte Dich vor solchen Experimenten gewarnt. Nur damals war nur die Rede davon, dass Du eine Platte aus einem der SHRs reißt. Und jetzt beide (also ein ganzes RAID 1)! Ich weiß jetzt auch nicht, wie Du das SHR wieder zum Laufen kriegst.

Eventuell runterfahren, das andere SHR ziehen und mit dem nicht initialisierten hochfahren. Nur sowas würde ich selbst mit externem Backup in 1.000 Jahren nicht versuchen.

Ich bin einfach feig und habe keine 2 SHR-1 auf einer Syno zum Rumspielen.

 

[framp]

...Ist nicht ganz klar was du genau gemacht hast...

Genau das was Du verstanden hast

Dann war das letzte vermutlich der Fehler. Wenn er auch bei einem Neustart dieses RAID nicht mehr einbindet.

Nach einem Reboot zeigt DSM dass das Volume degraded ist. Jetzt habe ich einen Rebuild angestossen. Mal sehen was dabei rauskommt

Ich verstehe nicht warum das SHR nicht wieder erkannt wird. Es ist keine Platte korrupt

 

[RichardB]

ps: Das war nicht böse gemeint.
Ich bewundere Deinen Mut und Deine Experimentierfreudigkeit. Nur wie Du aus der Nummer wieder rauskommst, weiß ich leider nicht.
Wenn es "nur“ das Backup-SHR ist, ist es eh nicht so schlimm.

 

[framp]

md3 war vorher mein zweites Volume. Morgen wird es wohl wieder das sein...

cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md3 : active raid1 sdc5[2] sdd5[1]
      2925435456 blocks super 1.2 [2/1] [_U]
      [>....................]  recovery =  2.8% (82918656/2925435456) finish=371.6min speed=127478K/sec
      
md2 : active raid1 sda5[0] sdb5[1]
      3902187456 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
      2097088 blocks [4/4] [UUUU]
      
md0 : active raid1 sdc1[2] sda1[0] sdb1[1]
      2490176 blocks [4/3] [UUU_]
      
unused devices: <none>

 

[RichardB]

Wie @fusion schon angemerkt hat: Auf der GUI sehe ich da auch keine Möglichkeit. Es sei denn, Deine angestoßene Reparatur ist erfolgreich.
Allerdings bist Du der Konsolenprofi. Geht vielleicht da etwas?

EDIT:
Du warst schneller

 

[synfor]

Ich verstehe nicht warum das SHR nicht wieder erkannt wird. Es ist keine Platte korrupt

Wird daran liegen, dass du die Platten im laufenden Betrieb nacheinander gezogen hast. Wenn du so etwas noch einmal vorhast, mach das, wenn überhaupt, besser nur dann, wenn das NAS heruntergefahren ist und nie ohne Backup.

 

[framp]

@synfor Wenn der rebuild durch ist (hoffentlich erfolgreich) werde ich das auch noch mal mit einer runtergefahrenen DS durchexzerzieren

 

[framp]

...Ich hatte Dich vor solchen Experimenten gewarnt. Nur damals war nur die Rede davon, dass Du eine Platte aus einem der SHRs reißt. Und jetzt beide (also ein ganzes RAID 1)!...

Wie schon geschrieben - das Volume war nur ein Backupcache. Es liegen weitere aktuelle Backups auf anderen Medien ...

 

[Puppetmaster]

Über alle Platten liegt das System auf einem RAID1. Wenn du nun ein ganzes Volume entfernst, wird der DSM wohl schon aufgrund der Inkonsistenz der Systempartition Probleme haben dieses wieder einzubinden.

 

[framp]

... Über alle Platten liegt das System auf einem RAID1...

Wie ich gerade vorhin bei einem Recoveryversuch einer einzelnen Platte aus einem SHR mit zwei Platten bemerkte ist dass unter der Decke dieses SHR ein RAID5 benutzt wird. Nachdem ich das entdeckte und darueber nachdachte geht natuerlich nur ein RAID5.

 

[synfor]

RAID5 mit 2 Platten?

 

[framp]

obelix ~ # mdadm --examine /dev/sde5
/dev/sde5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 11542862:539660c5:7bc34443:d9e0d610
           Name : DiskStation:2
  Creation Time : Thu Sep  5 11:50:47 2019
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 3897366912 (1858.41 GiB 1995.45 GB)
     Array Size : 5846050368 (5575.23 GiB 5986.36 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : 4df6d8f3:3ef2acd0:ef5d0d9d:79135526

    Update Time : Tue Oct  8 19:16:15 2019
       Checksum : 52689bcb - correct
         Events : 15415

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 1
   Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)

 

[RichardB]

@framp benutzt 4 Platten. Ein verstecktes RAID 5 wäre möglich, mir aber jetzt auch schleierhaft. Eventuell ein RAID 10 oder 0+1. Bei einem SHR ist allerdings vieles möglich. Lässt sich das verifizieren?

 

[Fusion]

Nein, mit raid 1 gehen auch N Platten. Das RAID ist dann f-fach redundant, sprich der DSM startet auch noch mit der letzten verbliebenen Platte. Das bezüglich der Systempartition. Diese wird immer überprüft wenn eine Platte wieder hinzugefügt wird.

Bezüglich der Datenpartition.
Wenn ein Teil, oder ganzes RAID im laufenden Betrieb entfernt wird, wird dies als potentiell fehlerhaft angesehen. Die einzige Situation wo es eventuell nicht überprüft wird ist wenn du das komplette zweite SHR nur im ausgeschalteten Zustand entfernst und auch wieder hinzufügst und zwischen drin nichts an der Konfiguration im Speichermanager änderst, außer vielleicht einen Alarm auszuschalten.
Bist ja eh grad im Spieltrieb unterwegs und kannst das testen.

@framp mit 'cat /proc/mdstat' kannst du dir die gesamte RAID config ausgeben lassen

 

[RichardB]

@framp:
Und schon wieder warst Du schneller. Nur bist Du wirklich sicher, dass Du 2 RAID 1 eingerichtet gehabt hast?
Ich möchte keinesfalls Deine Kompetenz anzweifeln, nur das ist echt schräg.

 

[RichardB]

@fusion:
Schon klar. Nur lt. #14 haben wir ein RAID 5 mit 4 Platten. Das macht mich stutzig.

 

[Fusion]

Ja, wo das herkommt ist die Frage. Vermute aus einer anderen DS (Indikator RAID-5 und sde bei einer 4 bay...)
Hatte auch den Fehler gemacht, den ich bei anderen nicht mag, nämlich Postings in der Zwischenzeit übersehen /nicht gelesen.

Der Auszug aus Post #6 sieht dagegen schlüssig aus.
md0 Systempartition, raid-1
md1 swap, raid-1
md2 und 3 die beiden SHR-1 mit Platte 1+2 bzw Platte 3+4, auch beides RAID-1

Das SHR wird offensichtlich erkannt, andernfalls könntest du keinen Rebuild anstoßen (Stichwort "recovery" im Auszug aus Post #6). Es wird eben nur sicherheitshalber als potentiell beschädigt angesehen.
Zumindest auf der Konsole kann man das glaube überstimmen bei mdadm beim Zusammenbau des gefundenen RAID. Allerdings fährt man bei so Systemen wie Synology meist besser wenn man an so grundlegenden Sachen nur das tut was vorgesehen ist um.

 

[framp]

Mea culpa Ich habe mich offensichtlich geirrt. Ich dachte die Platte haette ich bei meinen initialen Synotest in einem SHR gehabt. Die Fakten sprechen dagegen - und ich hatte auch einmal ein RAID5 mit 4 Platten testweise erstellt. Daraus ist sie offensichtlich.

Mein Rebuild des Volume2 mit SHR ist nach dem Restart der Syno durch und die Ausgabe sieht wir folgt richtig aus:

mdadm --examine /dev/sdc5
/dev/sdc5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 11bd0df2:342c75c4:a5792a8f:5db88e47
           Name : syno:3  (local to host syno)
  Creation Time : Wed Oct  9 19:04:59 2019
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 5850870912 (2789.91 GiB 2995.65 GB)
     Array Size : 2925435456 (2789.91 GiB 2995.65 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=0 sectors
          State : clean
    Device UUID : e3aa3958:7e9f0fcd:24047432:4e336659

    Update Time : Sun Jan 19 10:41:11 2020
       Checksum : 6707a3f - correct
         Events : 589


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

...Das SHR wird offensichtlich erkannt, andernfalls könntest du keinen Rebuild anstoßen (Stichwort "recovery" im Auszug aus Post #6). Es wird eben nur sicherheitshalber als potentiell beschädigt angesehen...

Macht Sinn.

...Zumindest auf der Konsole kann man das glaube überstimmen bei mdadm beim Zusammenbau des gefundenen RAID. Allerdings fährt man bei so Systemen wie Synology meist besser wenn man an so grundlegenden Sachen nur das tut was vorgesehen ist um...

Da bin ich bei Dir. Irgendwo habe ich mal gelesen dass Synology auch irgendwelche Aenderungen in mdadm eingebaut hat. Deshalb ist es sicherlich besser nicht haendisch mit mdadm am RAID rumzudoktoren

Dann werde ich die 2 Platten von Volume2 noch mal rausnehmen und mit einer der Platten versuchen auf einem externen Linux die Daten zu recovern - ist ja mein eigentliches Ziel ...