Raid-System aufteilen und wiederherstellen / aus 1x4 mach 2x2

[the_baker]

Hallo,
ich habe eine 918+ mit 4 x 9 TB als SHR.

Ich möchte nun gerne auf 2 x 2 Platten umsteigen. Dazu habe ich folgende Idee:

1. Eine Platte des 4-er Raids formatieren und als neues Volume 2 einsetzen.
-> Jetzt habe ich 2 Volumes. Volume 1 im Notbetrieb als 4-er-Raid mit einer fehlenden Platte, Volume 2 als Einzelplatte

2. Nun mit der Systemsteuerung die Shares auf Volume 2 umziehen
-> Jetzt ist Volume 1 "leer"

3. Nun die restlichen Platten platt machen. Aus 2 Platten wird Volume 1 SHR, die 3. Platte zu Volume 2 als SHR zufügen.
-> Im Anschluss Shares neu verteilen, so dass Zugriffe verschiedener Applikationen sich gegenseitig weniger beeinflussen.

Frage:
Ist das praktikabel?
Habe ich was übersehen?


Hintergrund:
Das BTRFS macht Probleme, die sich nicht reparieren lassen. Etwa 1300 Snapschots lassen sich nicht löschen. Dennoch wird das System durch die Synology-Diagnose für OK gehalten.
Das Raid ist im Moment zu 15 TB ausgelastet.
Der Speicher-Analysator zeigt, dass nur ca. 7 TB durch aktive Daten belegt werden.
-> Eine erhebliche Anzahl von Speicherplatz geht in den zum Teil nicht löschbaren Snapshots verloren.
-> Das System rödelt dauernd, um die Bereinigung durchzuführen, was nicht gelingt.

-> Ich möchte das gesamte BTRFS platt machen und neu aufsetzen

Ich habe aber Skrupel, alles komplett platt zu machen und dann aus dem Backup über das Netzwerk wieder zu restaurieren.
Folgende Bedenken:
1. Man merkt hinterher, dass "irgendwas" doch nicht im Backup war.
2. Es dauert sehr lange, bis die Daten zurück sind.
3. Während des Vorgangs hat man einen kompletten Systemausfall.

-> Daher die Idee, wie oben beschrieben vorzugehen.


---
Edit / Nachträge:

Es gibt einen SSD-Raid-Cache, inkl. BTRFS-Cache (erst nach Beginn der Probleme eingerichtet)
Es gibt Docker & VMs
Es gibt Videoüberwachung, da laufen Streams.
Es gibt ein Echzeit-Produktivsystem, das erzeugt ständig einzelne, sehr kleine Textdateien und zükünftig auch noch Datenbankeinträge. Hier ist Performance besonders wichtig!

 

[ctrlaltdelete]

Ja, das geht so, du musst aber die Pakete auch umziehen, am einfachsten mit appmover (siehe meine Signatur)
2 x SHR/Raid 1 halte ich nicht für sinnvoll, ich würde eher das Snapshot Problem lösen.
Edit: siehe gute Begründung von @dil88 ich war mal wieder zu schreibfaul.
Edit: Achtung falls du Docker und VMs verwendest, dann musst du nochmal fragen.

 

[dil88]

Ich würde nicht auf zwei Speicherpools/Volumes wechseln, wenn Du nicht dauerschreibende Pakete wie z.B. Videoüberwachung nutzt. Mehr Spindeln sorgen für mehr Performance, so dass normale konkurrierende Zugriffe verschiedener Applikationen keine Probleme bereiten sollten. Ein großes Volume bietet die beste Flexibilität hinsichtlich der Nutzung der verfügbaren Kapazität.

 

[ctrlaltdelete]

Wenn du einen neuen Speicherpool willst um deine Probleme zu resetten, dann mache das doch genau so nur lege halt trotzdem ein SHR mit erstmal 1 HDD an und erweitere dieses dann um die anderen 3 HDDs?

 

[ctrlaltdelete]

Und oder schaue dir das mal an???
https://kmg.group/posts/2022-11-04-remove-files-from-btrfs-snapshots/

 

[the_baker]

Danke für die schnellen Antworten und Ideen.

Nachträge:
Es gibt einen SSD-Raid-Cache
Es gibt Docker & VMs
Es gibt Videoüberwachung, da laufen Streams.
Es gibt ein Produktivsystem, das erzeugt ständig einzelne, sehr kleine Textdateien und zükünftig auch noch Datenbankeinträge

Edit:
Zu den Applikationen: Das hatte ich nicht auf dem Schirm, das Synology die platt machen würde, wenn man Volume 1 formatiert.
Zu Docker: Die Date liegen auf einem Share, die Konfiguration, ich habe keine Ahnung ...
Zu VMs: Da habe ich gelernt, man soll die runterfahren und exportieren, dann nacher neu aufsetzten.

Zu BTRFS: Ich habe "alles" versucht, das zu retten, und will nun reinen Tisch machen.

 

[ctrlaltdelete]

Dann sollten wir morgen mal telefonieren, ich schreibe dir eine PN.
1. SSD Cache, auflösen, ggf. RAM Upgrade, macht mehr Sinn
2. Docker und VMs müssen manuell gesichert werden und die würde ich dann auf die NVME-SSD als Speicherpool/Volume schieben
3. Welche Videoüberwachung? Ich würde die Cams auf eine separate HDD laufen lassen, also dann folgendes Setup:
3 HDDs SHR BTRFS: Daten
1 HDD SHR ohne Datenschutz: Surveillance
1-2 NVME-SSDs RAID1 BTRFS: Pakete, Docker, VMs
4.Was für ein Produktivsystem?
5. Welche und wo liegt die Datenbank?
6. Gewerbliche oder private Nutzung?
Edit: Ich kauf mir jetzt a Maß und morgen ein Auto

 

[the_baker]

1. Telefonieren klingt cool. RAM habe ich 12 GB, nicht Synology-Zertifiziert, weswegen die Supportanfragen versagen.
2. Ich habe auch noch eine externe Platte, aber die ist sehr voll. Cache als Umziehplatte verwenden klingt cool.
3. Zu meinen Platten, ich habe zwar 4 x WD100EFAX-68LHPN0, aber 2 davon sind mit 7200 rpm.
4. Ladenkasse einer kleinen Bäckerei (meines Bruders). Jeder Bon macht ein .txt und ein Signaturfile.
5. Maria-DB aus dem Paketzentrum
6. beides ... Ich halte die IT ohne finanzielle Zuwendugnen am Laufen, nutze dieselbe aber auch privat. Noch oldschool Familenstory.
(und auch für meine "richtige" Arbeit mit, weil es dort auch an IT mangelt; hier vor allem Dashcam-Aufnahmen; ich mache Verkehrsinfrastruktur in der Verwaltung)

Auf den SSDs hätte ich gefüht nur den Cache gemacht. Das ist mein zweiter Cach in der Maschine, nachdem der erste die Zahl der R/W-Cycles überschritten hat und um Austausch gebeten hat.

Ich hätte noch 3 Autos übrig. Sind seit bestimmt 5 Jahren nicht oder fast nicht bewegt worden ... Noch alles Verbrenner, der älteste von 1973.
Schönen Abend!

 

[the_baker]

Ok, stand jetzt habe ich folgendes Vorgehen vor:

1. Volume 1 Laufwerk 4 deaktivieren
2. Volume 2 mit Laufwerk 4 erstellen
3. Shares mit Hilfe der Systemsteuerung umziehen
4. apps mit Hilfe Synology_app_mover auf Volume 2 verschieben
5. checken, was noch getan werden muss, ob alles Läuft ...
6. Platten des Volume 1 deaktivieren, sehen ob alles über Volume 2 läuft.
7. Wenn alles läuft, die anderen 3 Platten zu Volume 2 hinzufügen

D.h. wahrscheinlich mache ich doch kein 2x2, sondern bleibe bei 1x4.
-> mehr Flexibilität, blei mehr nutzbarem Plattenplatz.
Ich habe aber immernoch Bedenken, ob die Perfomance bei 2x2 nicht besser wäre

Die SSDs (2 x 1 TB als Raid) würde ich weiter als Cache verwenden, inkl BTRFS-Metadaten, nicht als weiteres Volume.
-> Bedenken, dass durch Systemupdates der Hack irendwann in der Zukunft schief geht und dann das Produktivsystem der Bäckerei tot ist.
Der Berater empfielt zwar 1,4 TB bei den 4x10TB Platten, aber hey...
Bisher habe ich 95% Trefferquote beim SSD-Cache.

Falls was schief geht, habe ich auf einer 216j ausreichend gebackupt, so hoffe ich.

Drückt mir die Daumen.


Letzte Bedenken:
Wo ist eigentlich das synologyeigene System?
D.h. was passiert, wenn Volume 1 in das Volume 2 integriert wird?
-> Wenn ich die Synology-FAQ richtig verstehe, dann auf jeder einzelnen Platte, d.h. es dürfte alles safe funktionieren?


Nebengdanken:
Wahrscheinlich ist die Performance des Produktivsystems besser, wenn diese Daten direkt auf einem SSD-Volume landen, weil dann auch neue Daten direkt darauf geschrieben werden, anstatt in das Raid, wo noch andere Last wie surveillance drauf läuft? Bei mir werden da vor allem wenige kB große Dateien geschrieben.

 

[dil88]

Das DSM wird gespiegelt auf einer eigenen Partition auf allen SATA-Laufwerken gespeichert. Insofern sind Deine geplanten Anpassungen hinsichtlich Speicherpools / Volumes etwas, was am DSM vorbei geht und da keine Probleme verursacht, da die Speicherpools auf eigenen Partitionen gespeichert werden.

Ich persönlich würde an Deiner Stelle drei Platten in einem Speicherpool/Volume für die Daten und eine Platte für Surveillance betreiben, wenn die Kameras permanente Schreiblast erzeugen, vor allem wenn es dabei dann auch noch um kleine Dateien geht.

 

[the_baker]

Großes Problem:
Ich habe jetzt das Laufwert 4 deaktiviert. Rausgezogen und wieder eingesteckt.

Laufwerk 4 wird im Speichermanager angezeigt, lässt sich aber nicht wieder aktivieren, weder als neues Volume, noch zum "Reparieren" des Volume 1.

((( !!!

Edit:
Beim 2. Versuch hat es jetzt geklappt. Ich musste jedoch auch einen neuen Speicherpool anlegen.
Ufff!

 

[ctrlaltdelete]

Und wie läuft der Umzug?

 

[the_baker]

Es fing eigentlich gut an, wurde aber schnell langsam. Irgendas hält Volume 1 bei 100 % Auslastung :-/
D.h. es geht sehr zäh mit Übertragungsrate von unter 1 MB/s (am Anfang waren es coole 180 MB/s). Ich warte jetzt erst mal, bis das aktuelle share umgezogen ist und ob sich die Sache dann wieder beruhigt.

Ich hatte den SSD-Cache vom Volume 1 weggenommen und dem Volume 2 gegeben, in der Annahme, dass die 3 Platten parallel schneller liefern können, als Volume 2 verkraftet, aber Pustekuchen.

Parallel habe ich als erstes Paket über das Umzugsskript das Docker-Paket ausgewählt. Das macht nun auch schon seit Stunden ein obligatorisches Backup vor dem Umzug.

Das einzig Positive bisher ist daher derzeit, dass wenigstens immernoch Webseite und Mailserver im Hintergrund nutzbar sind.


Edit:
Ich frage mich, ob der Manuelle Docker-Umzug über verschieben der Container und neues Importieren der Configs nicht effizienter gewesen wäre.

 

[ctrlaltdelete]

Hast du die Container nicht vorher gesichert über einen Export?
Webseite und Mailserver, was läuft denn noch alles auf der "armen" DS?

 

[the_baker]

Doch, ich hab die Container so gesichert, dass ich auch manuell umziehen kann. Das war für mich der Grund, das Script auf Docker als erten Kandidaten auszuprobieren. Falls es schief geht, habe ich alles, um es manuell zu machen.
Ich habe das Script jetzt mal mit Ctrl Z gestoppt. Das hat kurz zu hoher schreibrate auf Volume 2 geführt, aber nur ein Spike, dann war es wieder wie zuvor.

Die Kiste liest und schreibt irgendwas auf Volume 1. ... ob ich nicht doch alle Kopiervorgänge unterbreche, um zu sehen, ob ich rausfinden kann, was da los ist...? Im Moment laufen immernoch die 2 Kopiervorgängen von shares. Eine davon mit sehr vielen kleinsten Textdateien. Aber so eine habe ich zuvor schon parallel zu anderen shares kopieren lassen, und es ging gut.

 

[the_baker]

Also meine Erfahrungen soweit mit dem Umzug der Shares:
Shares mit einer großen Anzahl kleiner Dateien mag das System nicht. Dann dauert es ewig und die Leistung geht total in den Keller. Besonders wenn zwei Shares kleine Dateien beinhalten, z.B. Softwareentwicklung.

Man kann dem Phänemen etwas entgegentreten, wenn man das neue Share mit Kompression anlegt. Das ist ein gefühlter Eindruck!

Nachdem eine dieser Shares abgearbeitet war, konnte ich parallel Shares mit größeren Dateien, z.B. Musikbibliothek problemlos umziehen.

Das Docker-Umzugsskript verzeichnet jetzt auch wieder Lebenszeichen und bewegt Dinge.

 

[ctrlaltdelete]

Führe immer nur eine Aktion aus, die zeitgleichen Zugriffe bremsen es nur aus, mach es nacheinander.

 

[the_baker]

Ich habe das Umziehen des einen Shares nun abgebrochen, nachdem das heute um 10:00 immer noch bei ca 66% hing. Ich habe den Umzug neu gestartet, nun mit Komprimierung, in der Hoffnung, das ginge dann besser. Scheinbar geh es aber nur gut, bis er an die Stelle mit den vielen Kleinstdateien kommt. Ab etwas über ca 58 % geht es kaum voran. Das lesende Volume ist an der Auslastungsgrenze, das schreibende quasi idle.

Ich habe über Nacht auf der Backup-DS216j eine Kopie des fraglichen Ordners gezipt. Da will ich nun versuchen, die Zipdatei auf dem neuen Volume zu entpacken und dann in das in das Basis-Verzeichnis zu verschieben, so dass die Auslastung des alten Volume 1 irrelevant ist. Sieht bisher gut aus. Das Entpacken ist schon bei über 70% und es geht weiter voran.

Um 15:00 Uhr ist ein Wartungstermin mit einem Dienstleister terminiert. Mal sehen, ob ich den halten kann... :-/
Wenn nicht, muss die Wartung auf dem Volume 1 passieren, wie dann auch der produktive Betrieb für diese Woche. (oder ich switche auf das Backup-NAS, und muss dann von dort aus wieder migrieren..)

... ich wusste, warum ich diese Aktion seit Monaten vor mir herschiebe ...

 

[metalworker]

Ich würde dir empfehlen erst zu fragen bevor du neues Probierst.

Das Komprimieren für die Freigabe einzuschalten machts eher schlimmer.

Ich hätte an deiner Stelle erstmal stück für stück verschoben.

 

[ctrlaltdelete]

Was treibst du für einen Unfug, das macht es ja noch langsamer.
Hast du dich daran gehalten immer nur eine Operation zeitgleich auszuführen?
Edit: Und sorry, aber ich denke deine Kenntnisse sind für dein geplantes Vorhaben nicht so ganz ausreichend.