Raid entfernen

[whitbread]

Ich hänge mich mal dran.

Wollte den einfachsten Weg gehen, eine Platte in meiner DS212 durch eine andere zu ersetzen und dachte machste erst nen Raid-1 und dann zurück in Basis - Pustekuchen: das war die Dümmste aller Ideen!!!

Ich bin daran gescheitert, Prozesse per kill zu beenden, da diese immer wieder neu gestartet werden. Die überall angegebenen Scripte in "/usr/syno/etc/rc.d/" existieren bei mir nicht bzw. haben keinerlei Funktion. Kann mir jemand dabei helfen, diese loszuwerden?

Oder gibt es irgend eine andere Variante die zum Ziel führen könnte? Ich dachte daran die HDD komplett zu klonen und die ersten beiden Partitionen zu löschen, so dass nur alle Daten erhalten blieben.

Achja: DSM ist schon die aktuelle Beta...

 

[dil88]

Mit dieser Anleitung solltest Du migrieren können.

 

[whitbread]

Jein - ich kann zwar eine neue Diskgruppe / ein neues Volume erstellen, ABER:

Ich habe kein SHR erstellt sondern ein Raid-1; sieht dann so aus:





Also es besteht keine Eile - alles läuft auf dem defekten Raid-1 ja, aber so lassen kann ich es endgültig wohl leider nicht...

 

[dil88]

Das ist immer so, wobei ich nicht wusste, dass Du eine Diskgruppe verwendest, die bei zwei gespiegelten Platten m.E. keinen Sinn macht. Deshalb gibt es in der Anleitung ja den optionalen Punkt, die zweite Platte wieder ins Spiel zu bringen und die Daten ggfs. erneut zu migrieren.

 

[whitbread]

Das mit den Diskgruppen habe ich noch nicht gerafft. Früher gab es halt keine Volumes ohne Diskgruppe, daher wohl die Diskgruppe.

Das "erneut migrieren" kommt dann quasi einer Neuinstallation gleich - werde mal testen welche Pakete denn sauber gesichert werden / wurden (insbesondere die PhotoStation macht mir da Sorgen)...

Ist ja echt Mist, dass man von Raid-1 nicht mehr vernünftig zurück kommt

 

[dil88]

Die Photo Station läßt sich ja in der Datensicherung selektieren - wie auch die Metadaten. Insofern sollte gerade die schon gesichert werden. Ich musste sie noch nicht restaurieren, insofern weiß ich nicht, ob alles abgedeckt ist und funktioniert.

Das erneute Migrieren entspricht aus verschiedenen Gründen keiner Neuinstallation. Erstens wird die Systempartition gespiegelt, so dass DSM und Systemkonfiguration erhalten bleiben. Zweitens kann man die gemeinsamen Ordner sehr einfach verschieben (einfach das Volume ändern). Pakete müssen aber aus einer Datensicherung restauriert oder neu installiert und konfiguriert werden. Da kannst Du Dir jetzt ggfs. Screenshots der Konfiguration erstellen.

 

[whitbread]

Tja - so werde ich halt gezwungen mal eine Wiederherstellung im halben Ernstfall anzuwenden. Eine Platte mit dem nun defekten Raid lasse ich solange liegen bis alles passt.

Nur mies, dass so etwas einen zu diesem umständlichen und zeitaufwendigen Prozedere zwingt...

 

[whitbread]

Also kurzes Resumée: Musste alle Pakete neu installieren bzw. reparieren (mal so mal so...) und habe dann die Wiederherstellung (sofern vorgesehen) durchgeführt.

Problemlos gingen: Webalizer, DNS-Server, MariaDB
Nur unvollständig die Photo Station
Trotz Sicherung direkt vor Neuinstallation werden einige Einstellungen (Rechte) und vor allem die Albumdeckblätter nicht wiederhergestellt. Das ist ziemlich doof...

 

[Puppetmaster]

Wiederherstellung de PhotoStation bzw. der Transfer derselben auf eine andere DS habe ich schon mehrfach durchgeführt, dabei wurden weder Benutzer- noch Albumeigenschaften verändert. Absolut problemlos.

Evtl. liegt es an der Benutzerverwaltung der Photostation? Ich nutze da die PhotoStation-eigene Verwaltung.

 

[whitbread]

Ich war auch überrascht, soll ja die Sicherung der Anwendung Photo Station eigtl. alles erschlagen.

Ich nutze LDAP für meine Nutzerverwaltung und habe es ziemlich flat über Gruppenrechte eingestellt; insofern war es schnell erledigt.

Übrigens - nach Neuindizierung über Nacht sind jetzt die Albumdeckblätter wieder die alten...

 

[Online78]

Hey Community

Es ist schon 2021 und viel Zeit vergangen seit dem letzten Eintrag. Ich habe eine DS918+ und darauf zwei Raid1 am laufen gehabt. Aus meiner Sicht machte ein Raid nicht so Sinn, weil es ein Raid mit zwei SSD war für eine VM, auf welcher mein Mailserver läuft. SSD fallen ja auch nicht so aus wie HDD. Weil ich aber mein anderes Raid 1 erweitern will, brauchte ich ein Festplatten Steckplatz frei. So entschloss ich mich eine SSD Festplatte raus zu nehmen, und den Platz frei zu machen.

Es hat alles ganz einfach funktioniert:
1. Backup erstellt mit Hyperbackup;
2. Alle Dienste mit einer erstellten Aufgabe im Aufgabenplaner der Systemsteuerung ausgeschaltet;
3. SSD raus gezogen;
4. Alarm in der Systemsteuerung ausgeschaltet
5. ssh als admin in die DS;
6. root rechte mit sudo su -
7. fdisk -l (hat mir die liste aller Speicher gegeben, bei mir musste ich md2 auf Basic umbiegen - md2 hatte die exakte grösse des Speicherpools)
8. mdadm --grow --raid-devices=1 --force /dev/md2
9. Im Speichermanager festgestellt, dass der degradierte Speicherpool verändert wurde und nun als Basic Speicherpool angezeigt wird.

Alle Dienste neu gestartet und die neue HDD um den anderen Speicherpool zu erweitern eingesteckt sowie entsprechend erweitert.

Nach meinem Wissen geht dies wenn der Speicherpool explizit als Raid1 erstellt wurde. Ob es mit SHR geht weiss ich nicht. Ich hatte vor Jahren dies schon mal so gemacht und es hat ganz einfach funktioniert.

Vielleicht hilft dieser Beitrag jemandem,
Gruss Online78

 

[ubr]

Danke, Online78. Es ist 2022 und ich will Deinen Weg probieren, um mein SHR1, das eigentlich aus zwei SSD und aktuell nur noch aus einer einzigen SSD besteht und daher als "degradiert" geflaggt ist, in Basic JBOD umzuwandeln.

Zu Schritt 2 in Deiner Beschreibung oben habe ich eine Frage. Du schreibst: "Alle Dienste mit einer erstellten Aufgabe im Aufgabenplaner der Systemsteuerung ausgeschaltet". Ich würde vor einer Änderung am RAID auch gern alle Zugriffe auf das Volume verhindern. Wie macht man das mit einem Job im Task Scheduler?

Weiter schreibst Du, "ob das mit SHR geht weiss ich nicht". Ich glaube, es müsste gehen. Denn SHR1 legt ja nur ein Logical Volume über das RAID1. Und ich glaube, das sollte das Volume theoretisch sogar vor Beschädigungen schützen, wenn ich am drunterliegenden RAID1 Änderungen vornehme. Das heißt, ich vermute, Dein Schritt 8 sollte auch mit SHR1 funktionieren, und nicht nur mit RAID1. Hier habe ich gestern die Frage gepostet, ob jemand schon mal mdadm --grow --raid-devices=1 --force /dev/mdX auf einen SHR1 angewandt hat.

 

[ubr]

Danke, Online78. Es ist 2022 und ich will Deinen Weg probieren, um mein SHR1, das eigentlich aus zwei SSD und aktuell nur noch aus einer einzigen SSD besteht und daher als "degradiert" geflaggt ist, in Basic JBOD umzuwandeln.

Zu Schritt 2 in Deiner Beschreibung oben habe ich eine Frage. Du schreibst: "Alle Dienste mit einer erstellten Aufgabe im Aufgabenplaner der Systemsteuerung ausgeschaltet". Ich würde vor einer Änderung am RAID auch gern alle Zugriffe auf das Volume verhindern. Wie macht man das mit einem Job im Task Scheduler?

Weiter schreibst Du, "ob das mit SHR geht weiss ich nicht". Ich glaube, es müsste gehen. Denn SHR1 legt ja nur ein Logical Volume über das RAID1. Und ich glaube, das sollte das Volume theoretisch sogar vor Beschädigungen schützen, wenn ich am drunterliegenden RAID1 Änderungen vornehme. Das heißt, ich vermute, Dein Schritt 8 sollte auch mit SHR1 funktionieren, und nicht nur mit RAID1. Hier habe ich gestern die Frage gepostet, ob jemand schon mal mdadm --grow --raid-devices=1 --force /dev/mdX auf einen SHR1 angewandt hat.

Also, ich habe meine DS jetzt nochmal zusätzlich gesichert und den Prozess einfach mal beherzt probiert.

Ergebnis: Mit einem einzigen Standard-Linux-Befehl lässt sich ein RAID1 oder SHR1 mit zwei Drives wieder auf ein gesundes Ein-Drive-Basic-JBOD reduzieren. Es ist ganz einfach:

• Zuerst nehme ich das Laufwerk aus der DS heraus, das ich aus dem RAID herauslösen möchte. Hierzu gibt es theoretisch dedizierte Optionen des Linux-Standardbefehls mdadm, aber für meine Zwecke habe ich sie nicht gebraucht.
• Der Befehl

  mdadm --grow --raid-devices=1 --force /dev/mdX

  funktioniert auf dem verbleibenden Laufwerk (das mit dem "degradierten" RAID) wunderbar. Nach einer Sekunde heißt es "raid_disks for /dev/mdX set to 1" und der Drops ist gelutscht: Der Storage Manager meldet ein gesundes RAID mit nur einem Laufwerk. Fertig! Aus einem "Degraded SHR1" wurde ein "Healthy SHR" — natürlich ohne "Data Protection", weil ja nur noch ein Drive. Aber das war ja das Ziel. ("Force" klingt gefährlich, aber unterdrückt nur die Rückfrage, ob man wirklich ein RAID mit nur einer Platte einrichten möchte.)
• Wichtig: vorher ermitteln, welches RAID wir brechen wollen. Es gibt bei DSM nämlich immer mindestens 3 RAIDs: ein Daten-RAID (zB /dev/md3, und zwei für DSM. Mit dem Befehl cat /proc/mdstat gibt es eine Übersicht aller Laufwerkskonstellationen auf der DS, und man erkennt das gewünschte RAID leicht an der Größe. Im Zweifelsfall mit sudo pvs nochmal genauer hinschauen und die Volume Groups mit sudo lvs überprüfen.
  
  Klingt kompliziert, aber am Ende ist die Frage ob's sich um /dev/md3 oder /dev/md2 handelt — und das sieht man sofort an Größe, Volume-Nummer und Physischem Laufwerk. /dev/md0 und /dev/md1 sind auf jeden Fall vom System (/-Partition und Betriebssystem): Bleibt als Daten-RAID nur /dev/md2 oder höher.
• Nach der Umstellung ist die neue RAID-Konfiguration sofort verfügbar. Ich habe dennoch sicherheitshalber neu gebootet. In älteren Beschreibungen heißt es, man müsse vorher alle DSM-Services etc stillegen. Ich habe das nicht gemacht und ich glaube es ist auch einfach nicht nötig. Denn während man das RAID verändert, ändert sich nichts am darüber liegenden Logischen Volume /volumeX: Es ist halt einfach ein "Hot Swap"-Vorgang, und DSM kann das.
• Aus dem entnommenen zweiten Laufwerk meines RAID habe ich tatsächlich mit derselben Methode eine weitere identische DS218+ geklont. Das ist praktisch, denn das Duplizieren einer vollen 2 TB SSD dauert keine zwei Stunden und ist mit Parity-Bits gegen Bitfehler abgesichert.
• Synology Support sagt dazu "Depending on the current status of your storage pool it's not possible to fix the RAID (at least temporary) or convert it to another RAID type since it's not allowed. The only possible way will be by adding a new drive and repair the storage pool, otherwise any changes on the RAID configuration or if the current SSD fails you will lose all of your data." Diese Behauptung ist hinlänglich bekannt, aber ich kann sie definitiv nicht bestätigen.
  
  Und finde dieses künstliche Verbot von 1-Drive-RAIDs auch eine äußerst ärgerliche Produktpolitik von Synology. Ich konnte mir mit meiner Methode die Anschaffung einer sinnlosen dritten SSD jedenfalls sparen, die ich gebraucht hätte, um das degradierte RAID zu heilen und das Gesamtsystem mit dem Migration Manager zu einer zweiten DS mit einer neuen SSD zu übertragen.

Das Ergebnis sah nach eine Sekunde nach sudo mdadm --grow --raid-devices=1 --force /dev/md3 bei mir jedenfalls so aus — Problem gelöst!

 

[Iarn]

Ich möchte über den Danke Button hinaus ein dickes, fettes Lob aussprechen. Ich denke, das ist echt mal ein echter Fortschritt für die Benutzung von Synology Diskstations. Gefühlt klam die Frage sehr oft hoch und wurde immer mit "neu aufsetzen, weil ist leider so" beantwortet und jetzt gibt es eine Lösung, die zwar ein bisschen Kommandozeile benötigt aber aus meiner Sicht auch für weniger versierte Leute zu schaffen ist.

 

[friedirch_fuhr]

Vielen Dank für Ihre Anleitung, die gerade eben bei meiner DS220+ meine vorherigen stundenlangen vergeblichen Versuche fehlerfrei und positiv beendet hat.

 

[Kaangeer]

Moin und großes Dankeschön für die Anleitung.

Bin unbeleckt mit Terminalbefehlen und weil es nicht sofort geklappt habe ich erst noch openssh auf dem Windowsrechner nachinstalliert und noch die Firewall auf der DS abgeschaltet, dann hat aber alles geklappt.