January 17, 20251 yr Moin, ich nutze Unraid seit ca. 1 Jahr und habe in der Zeit viel probiert, vor allem aber gelernt. In meinem System befinden sich 4 HDDs: Parity 6TB 1x Data Disk 6TB 2x Data Disk 2TB Da es sich um alte Platten handelt, möchte ich alle gegen neue austauschen. Dazu habe ich 4 WD Red Plus 6TB geordert. Anmerken möchte ich, dass ein Backup natürlich vorhanden ist. Das System ist noch nicht auf Unraid7 aktualisiert, der Stand ist 6.12.14 Vorgehen möchte ich wie in den Unraid Docs beschrieben. Wie würdet ihr vorgehen, erst die Parity Disk tauschen und danach die Daten Disks oder umgekehrt,? Mein Bauchgefühl sagt mir zunächst Parity Disk. Oder zunächst das System auf V7 updaten? Danke für eure Tipps! VG Werner
January 17, 20251 yr Community Expert Solution 10 hours ago, dweezle said: In meinem System befinden sich 4 HDDs: Parity 6TB 1x Data Disk 6TB 2x Data Disk 2TB Da es sich um alte Platten handelt, möchte ich alle gegen neue austauschen. Dazu habe ich 4 WD Red Plus 6TB geordert. Auch eien Art Geld zu verschwenden. WD Red sind in aller Redegl teurer als andere Disks und man profitiert (gerade im unraid Array) nicht wirklich von den so hoch gelobten FGaehigkeiten dieser NAS Platten, da unraid (bei energetisch sparsamer Konfiguration) die Disks weniger dauerlaufen läßt, sondern eher schlafen schickt. Und gerade diese "hoch gelobten" Red Festplatten sind eben eher für 24/7 Dauerlauf gedacht/opimiert. 10 hours ago, dweezle said: Anmerken möchte ich, dass ein Backup natürlich vorhanden ist. Lobenswert! 👍 10 hours ago, dweezle said: Das System ist noch nicht auf Unraid7 aktualisiert, der Stand ist 6.12.14 Vorgehen möchte ich wie in den Unraid Docs beschrieben. Wie würdet ihr vorgehen, erst die Parity Disk tauschen und danach die Daten Disks oder umgekehrt,? Ich Hahbe jetzt nicht auf dem Schirm, wie unraid Docs das beschreibt, aber ich vermute: immer nur eine Disk tauschen und das System sich wieder herstellen lassen, dann die Nächste... Eigentlich ist es absolut schnuppe in welcher Reihenfolge Du vorgehst. Aber: Wenn Du immer wieder nur eine Disk tauschst undd ann diese rebuilden läßt dauert es sehr lange. Leider weiß ich nicht, wieviele SATA Anschlüsse Du hast oder ob Du einen USB oder so Adapter für eine weitere Disk hast, deshalb gehe ich mal von gesamt 4 SATA Ports aus. Voraussetzung, wegen Datensicherheit, wenn etwas schief geht: Du hast wirklich ein aktuelles Backup! - System ausschalten. alle alten Disks raus. (1x 6TB + 2x 2TB Datendisks + 1x 6TB Parity) - 3 der neuen Disks rein. (3x 6TB) - System starten. - per New Config das alte Array entfernen und ein neues Array mit 3x Datendisk erstellen (keine Partity!). - System ausschalten, eine der alten Datendisks an den verbleibenden SATA anschließen. - System starten. - Die alte Disk per UD mounten und mit einem Tool Deiner Wahl die Daten ins Array kopieren (Ich nutze für sowas den mc, man kann aber auch die seit einiger Zeit eingebauten Dateimanager Fähigkeiten oder auch den krusader oder so nutzen). - System ausschalten, eine Andere der alten Datendisks an den verbleibenden SATA anschließen. - System starten. - Die alte Disk per UD mounten und mit einem Tool Deiner Wahl die Daten ins Array kopieren. - System ausschalten, die Letzte der alten Datendisks an den verbleibenden SATA anschließen. - System starten. - Die alte Disk per UD mounten und mit einem Tool Deiner Wahl die Daten ins Array kopieren. Nun sollte alles im Array sein. - Wenn Du die Dateien im Array auf den Disks noch ein bisschen umsortieren willst: mach das jetzt - System ausschalten, die alte Disk entfernen und die letzte neue Disk dazu. - System starten. und die neuest zugefügte Platte nun als Parity definieren und die Parity aufbauen lassen. Warten, bis fertig. Erledigt! Das sollte wohl eine der schnelleren Methoden sein (wenn meine Annahmen zur Hardware stimmen). Edited January 17, 20251 yr by DataCollector
January 17, 20251 yr Community Expert 56 minutes ago, cottec said: Warum kaufst du nicht 2x12 oder was auch immer? Reine Vermutung: Möglicherweise, weil er eher auf ca. 18TB Nutzkapazität abzielt und nicht auf 12TB?
January 18, 20251 yr Author 9 hours ago, DataCollector said: Reine Vermutung: Möglicherweise, weil er eher auf ca. 18TB Nutzkapazität abzielt und nicht auf 12TB? Korrekt 12 hours ago, DataCollector said: Leider weiß ich nicht, wieviele SATA Anschlüsse Du hast oder ob Du einen USB oder so Adapter für eine weitere Disk hast, deshalb gehe ich mal von gesamt 4 SATA Ports aus. 4xSATA3, 1xUSB3 5Gb, 1xUSB-C, 2xNvme mit je 2Tb bestückt. Ein USB3 Adapter mit Anschlussmöglichkeit SATA3 ist auch vorhanden, ist aber eher langsam. 12 hours ago, DataCollector said: Auch eien Art Geld zu verschwenden. WD Red sind in aller Redegl teurer als andere Disks und man profitiert (gerade im unraid Array) nicht wirklich von den so hoch gelobten FGaehigkeiten dieser NAS Platten, da unraid (bei energetisch sparsamer Konfiguration) die Disks weniger dauerlaufen läßt, sondern eher schlafen schickt. Und gerade diese "hoch gelobten" Red Festplatten sind eben eher für 24/7 Dauerlauf gedacht/opimiert. Ich habe mit dem Hersteller gute Erfahrungen, was Lebensdauer, Betriebslautstärke und Service betrifft. Ich habe die Platten direkt bei WD bezogen, zu einem günstigen Preis. Danke für deine ausführlichen Hinweise zur Vorgehensweise, ich werde deiner Empfehlung folgen. Das Update auf Unraid 7 werde ich nach dem Plattentausch durchführen.
January 19, 20251 yr ist das nicht etwas doof, von anfang an klein zu schachteln? Erweitern würde ich ja verstehen, aber direkt klein + 3x klein? Dann doch wenigstens ne größere Parity mit 10 oder 12gb oder was auch immer, dass man später mal ordentlich nachlegen kann Edited January 19, 20251 yr by cottec
January 19, 20251 yr Community Expert 29 minutes ago, cottec said: ist das nicht etwas doof, von anfang an klein zu schachteln? Dann doch wenigstens ne größere Parity mit 10 oder 12gb oder was auch immer, dass man später mal ordentlich nachlegen kann Das ist eine Frage des Preises und des Budget. Klar, ich bin auch ein Freund von "je größer, desto besser (im finanziell vertretbaren Rahmen)", aber wenn das Budget/Sonderangebot eben (nur) 4x 6TB her gibt und man so viel Platz wie möglich will sind es eben 18TB D + 6TB P. Und ja, ich gehe weiterhin davon aus, daß WD Red teurer sind. Somit hätte doch auch lieber das Budget für normale Consumerplatten aufgewendet und dann lieber was größeres genommen. Wenn es nicht flott sein muß im schlimmsten Falle vielleicht sogar Datenplatten SMR und Parity CMR. Edited January 19, 20251 yr by DataCollector
January 21, 20251 yr Author Ich habe noch eine Frage, ich habe bisher BFTRFS als Filesystem im Array und Cache eingesetzt. Nun möchte ich das Array aber mit XFS betreiben, Cache bleibt auf BTRFS. Hat das irgendwelche Auswirkungen auf den Docker Service? Ich habe im System diesen Ordner gefunden: /mnt/user/system/docker/installed/docker/btrfs und weiß nicht, ob die Änderung am FS zu Fehlern beim Start des Docker Service führen werden. Edited January 21, 20251 yr by dweezle
January 21, 20251 yr 4 minutes ago, dweezle said: Ich habe im System diesen Ordner gefunden: /mnt/user/system/docker/installed/docker/btrfs und weiß nicht, ob die Änderung am FS zu Fehlern beim Start des Docker Service führen werden. ist dein /system Share denn auf dem Array ? (was nicht empfohlen wäre ...) aber mal abseits davon, das ist ja schnell neu gemacht ... da liegt auch nichts relevantes (persistent) ...
January 21, 20251 yr Author Ich habe den /system Share auf dem Cache, wird aber mit dem Mover vom Array in den Cache übertragen. Wäre ein guter Zeitpunkt Fehler auszubügeln. Edited January 21, 20251 yr by dweezle
January 21, 20251 yr Community Expert 7 hours ago, dweezle said: Ich habe noch eine Frage, ich habe bisher BFTRFS als Filesystem im Array und Cache eingesetzt. persönliche Meinung: Mutig! Ich bin kein Fan von btrfs bei Einmzeldisks (wie im array) und seit unraid 6.12.x sind pools mit mehreren Datenträgern mit zfs zu bevorzugen (oder ich sollte sagen: mir bisher seltener mit echten Problemmeldungen aufgefallen). 7 hours ago, dweezle said: Nun möchte ich das Array aber mit XFS betreiben, Finde ich gut 7 hours ago, dweezle said: Cache bleibt auf BTRFS. Finde ich nicht gut. 7 hours ago, dweezle said: Hat das irgendwelche Auswirkungen auf den Docker Service? Im Regelfall laufen Docker nicht im Array, sondern auf Pools mit flotten SSDs. Nein, in dem Fall hat es keine Auswirkungen. Solltest Du da bewusst etwas sehr exotisches aufgesetzt haben (was ich nicht kenne), kann es vielleicht Auswirkungen haben, aber das ist aus Deiner Beschreibung nicht zu ersehen. 7 hours ago, dweezle said: Ich habe im System diesen Ordner gefunden: /mnt/user/system/docker/installed/docker/btrfs und weiß nicht, ob die Änderung am FS zu Fehlern beim Start des Docker Service führen werden. In aller Regel: keine Auskwirkungen, da (hoffentlich) der "system" share sowieso auf einem Pool ist.
January 21, 20251 yr Community Expert 7 hours ago, dweezle said: Ich habe den /system Share auf dem Cache, wird aber mit dem Mover vom Array in den Cache übertragen. So mache ich es auch. Du kannst mit dem Button "compute all" bei den Shares nachsehen, wo Deine shares in Wirklichkeit liegen. DIe 4 Systemshares liegen bevorzugt auf einer flotten SSD, welche sich in aller Regel in einem Pool finden. Diese systemshares lasse ich per Mover vom Array zum Cache aber nicht umgekehrt verschieben. Damit fange ich 2 Problemfälle ab: a) sollte einmal der Platz im Pool voll sein, schmiert unraid nicht gleich ab, sondern schreibt weitere Schreibzugriffe ins langsamere Array durch. b) sollten sich dann doch irgendwann im langsamen Array mal Daten der Systemshares befinden, wird vom mover versucht das Zeugt baldmöglichst (timergesteuert!) wieder un den flotten Cache zu verlagern.
January 22, 20251 yr Author 13 hours ago, DataCollector said: 21 hours ago, dweezle said: Cache bleibt auf BTRFS. Finde ich nicht gut. Das werde ich auf ZFS korrigieren, sobald ich auf Unraid7 aktualisiert habe. Bevor ich aktualisiere wollte ich aber noch etwas abwarten, ob es Meldungen zu Problemen gibt. 13 hours ago, DataCollector said: Solltest Du da bewusst etwas sehr exotisches aufgesetzt haben (was ich nicht kenne), kann es vielleicht Auswirkungen haben, aber das ist aus Deiner Beschreibung nicht zu ersehen. Ist nichts exotisches, habe mich bei der ersten Installation an die Docs gehalten und Videos von Spaceinvader angesehen 13 hours ago, DataCollector said: In aller Regel: keine Auskwirkungen, da (hoffentlich) der "system" share sowieso auf einem Pool ist. Liegt auf dem Pool 13 hours ago, DataCollector said: Du kannst mit dem Button "compute all" bei den Shares nachsehen, wo Deine shares in Wirklichkeit liegen. Das wusste ich nicht, danke! 13 hours ago, DataCollector said: DIe 4 Systemshares liegen bevorzugt auf einer flotten SSD, welche sich in aller Regel in einem Pool finden. 4 Systemshares? Bei mir sind /appdata, /domains und /system auf dem Pool, welcher ist der 4. Share? 13 hours ago, DataCollector said: Diese systemshares lasse ich per Mover vom Array zum Cache aber nicht umgekehrt verschieben. So habe ich es auch eingestellt. Danke Dir! Edited January 22, 20251 yr by dweezle
January 22, 20251 yr Community Expert 1 hour ago, dweezle said: Das werde ich auf ZFS korrigieren, sobald ich auf Unraid7 aktualisiert habe. Bevor ich aktualisiere wollte ich aber noch etwas abwarten, ob es Meldungen zu Problemen gibt. Ich weiß nicht ob die erwähneten "2xNvme mit je 2Tb" beide den Cache darstellen oder unterschiedliche Pools sind. Wenn unterscheidliche: xfs. Wenn beide in einem pool sind und sowas wie raid0 oder 1 darstellen sollen, ja dann bevorzuge ich seit unraid 6.12.x zfs. 1 hour ago, dweezle said: 4 Systemshares? Bei mir sind /appdata, /domains und /system auf dem Pool, welcher ist der 4. Share? diese 3 und /isos werden vom System angelegt. Da isos aber primär statische (ISO) Dateien enthalten sollte muß der nicht zwingend auf den flotten pool. er wird selten benutzt und kann somit auch auf dem array verbleiben, ohne dahingehend gravierende Auswirkungen zu haben.
January 23, 20251 yr Author On 1/22/2025 at 1:10 PM, DataCollector said: Ich weiß nicht ob die erwähneten "2xNvme mit je 2Tb" beide den Cache darstellen oder unterschiedliche Pools sind. Beide Nvme bilden den Cache-Pool, sobald ich umstelle auf Unraid7 werde ich den Cache auf ZFS umstellen. Das Update auf Unraid7 werde ich erst in ein paar Tagen durchführen. Den Wechsel der HDDs habe ich so durchgeführt, wie du vorgeschlagen hast und das hat super geklappt. Im Moment läuft noch die Erstellung der Parity-Disk. Vielen Dank für die Hilfe und guten Hinweise! VG Werner
January 23, 20251 yr Community Expert ich frag hier mal direkt, weil's gerade passt: Ich habe auch 2 NVMes als RAID1-Cache damals mit BTRFS eingerichtet. Ich hab zwar (noch) keine Probleme damit, würde aber trotzdem gerne der Empfehlung folgen und auf zfs wechseln. Wie gehe ich da am besten vor? Daten durch den mover auf's Array schieben lassen und pool löschen / neu anlegen und daten wieder zurückverschieben, richtig? Gibt es dabei irgendwas bestimmtes zu beachten?
January 24, 20251 yr Community Expert 4 hours ago, _alo_ said: ich frag hier mal direkt, weil's gerade passt: Ich habe auch 2 NVMes als RAID1-Cache damals mit BTRFS eingerichtet. Ich hab zwar (noch) keine Probleme damit, würde aber trotzdem gerne der Empfehlung folgen und auf zfs wechseln. Wie gehe ich da am besten vor? Du hast es unten ja ganz gut zuammengefasst, aber ich beschreibe es hier mal ausführlich, damit ein Hilfesuchender eine "Step By Step Anleitung" finden kann. Ich bin so vorgegangen und würde das auch anderen vorschlagen. Ist zwar etwas paranoid, falls etwas schief geht, aber es geht. Falls etwas schief geht: backups aktualisieren, notieren/Screenshot: welcher Datenträger im System was macht (parity, Datendisk, Pools und Namen der Pools (Schreibweise der Poolnamen beachten) ====Hauptteil Anfang === Die shares, die auf dem Pool sind auf das Array schieben (also die shares umkonfigurieren [mover sction: cache > Array], Dockercontainer & laufende VMs stoppen, Dockerdienst & VM Manager stoppen, mover starten) Array stoppen Zuordnung Pools mit new config entfernen (Preserve current assignments: Array Slots). die betreffenden 2 ehemaligen Pool Datenträger per UD (Destructiove mode) von ihren Partitionen befreien. Vielleicht sogar die ersten paar Minuten mit Preclear den 'Anfangsbereich' der SSDs löschen. Dann alle Pools wieder korrekt zuordnen (Namen und deren Schreibweise beachten), bei dem betreffenden Pool die Formatierung korrekt wählen (zfs) und den gewünschten Modus (Raid1 oder 0 ähnliche Einstellung). Array starten. Unten sollte für den Pool die Formatierungsoption erscheinen: ankreuzen + starten. Die shares, die aktuell auf dem Array sind zurück in den neuen Pool schieben. (also die shares umkonfigurieren [mover sction: Array > Cache], mover starten [vielleicht Extraschritt wegen Dockerdienst Image mit btrfs, siehe unten] Dockerdienst & VM Manager starten, Dockercontainer & laufende VMs wieder starten) Fertig. ====Hauptteil Ende === Ich erwähnte oben einen "Extraschritt wegen Dockerdienst Image mit btrfs": Per Default legt unraid das Dockerimage als btrfs an. Wenn man das auf xfs ändern möchte: - bei gestopptem Dockercontainern und gestopptem Dockerdienst - In den Settings / Docker / Docker data-root: umstellen von alt "btrfs vDisk" auf neu "xfs vDisk" - Apply Wenn man dann den Dockerdiesnt wieder startet legt er eine neue Imagedatei mit xfs an. Natürlich sind dann erst einmal alle Docker verschwunden, weil die Datei ja leer neu angelegt wurde Man kann die Docker mit der vorherigen Konfiguration neu installieren lassen, indem man bei Docker /Add Container /Template aufklappen und unten die bisherigen Templates, die man hatte einzeln auswählen und wieder neu installieren lassen. Dann sollte alles wieder wie zuvor sein, aber das Dateisystem im Dockerimage ist dann eben xfs. Wenn bei diesem Extraschritt etwas schief gehen und man das sehr kurz nach dem Wechsel zu xfs gemerkt haben: kein Problem. Man kann die Dockercontainer und Dienst wieder stoppen, zurück auf btrfs wechseln und damit wieder starten. Dann findet er beim Start die alte Imagedatei (die ja nicht gelöscht wurde) und läuft dann eben mit der btrfs Datei wieder los und da ist alles noch so drin, wie man es verlassen hatte. Sollte man aber mit der xfs Version zufrieden sein, kann man zu der Stelle manövrieren. an der die Images nun liegen und die alte btrfs-Imagedatei löschen. Der Standardwert des Dockerimages sind 20GB, somit macht man mit dem Löschen der alten Imagedatei wieder 20GB Platz im Pool frei. Und in dem Falle, daß bei dem wecshel des Pools von btrfs auf zfs wirklich absolut alles schief gegangen ist (weil zwischenzeitzlich ein Elefant auf den Server getreten ist oder die Aliens Deinen Server übernommen haben): naja, erwähnte ich oben Backups? 😁 4 hours ago, _alo_ said: Daten durch den mover auf's Array schieben lassen und pool löschen / neu anlegen und daten wieder zurückverschieben, richtig? Im Großen uns Ganzen: ja. (Siehe oben den Hauptteil) 4 hours ago, _alo_ said: Gibt es dabei irgendwas bestimmtes zu beachten? Backups sind Dein Ferund! und vielleicht die Überlegung ob man nicht gleich das Dockerimage auch wechselt, sofern man per Default eben ein btrsf Image nutzt. (Siehe Extraschritt oben).
January 24, 20251 yr Community Expert 5 hours ago, DataCollector said: Array stoppen Zuordnung Pools mit new config entfernen (Preserve current assignments: Array Slots). die betreffenden 2 ehemaligen Pool Datenträger per UD (Destructiove mode) von ihren Partitionen befreien. Vielleicht sogar die ersten paar Minuten mit Preclear den 'Anfangsbereich' der SSDs löschen. Dann alle Pools wieder korrekt zuordnen (Namen und deren Schreibweise beachten), bei dem betreffenden Pool die Formatierung korrekt wählen (zfs) und den gewünschten Modus (Raid1 oder 0 ähnliche Einstellung). Array starten. Ich habe am Anfang (ist/war mein erster unraid Server vor 1,5 Jahren) auch etwas rumgespielt mit RAID1 vs. nur eine SSD etc. aber ich kann mich nicht erinnern, jemals eine "new config" erstellt zu haben. Vielleicht ist das der sauberste weg, aber man kann doch eigentlich auch nur den cache-Pool löschen und neu anlegen, oder? 5 hours ago, DataCollector said: Ich erwähnte oben einen "Extraschritt wegen Dockerdienst Image mit btrfs": Per Default legt unraid das Dockerimage als btrfs an. Wenn man das auf xfs ändern möchte: - bei gestopptem Dockercontainern und gestopptem Dockerdienst - In den Settings / Docker / Docker data-root: umstellen von alt "btrfs vDisk" auf neu "xfs vDisk" - Apply Ich hab von Anfang an "directory" als data root, also kein image und bislang keine erkennbaren Probleme mit btrfs. Trifft das Thema dann noch auf mich zu, oder nicht? Ich habe nämlich auch etliche "btrfs"-Unterordner im system docker Verzeichnis .... dieser alte Beitrag bringt mich aber wieder zum grübeln, ob ich das überhaupt machen sollte.... naja, danke auf jeden Fall für die ausführliche Erklärung
January 24, 20251 yr Community Expert 5 hours ago, _alo_ said: Ich habe am Anfang (ist/war mein erster unraid Server vor 1,5 Jahren) auch etwas rumgespielt mit RAID1 vs. nur eine SSD etc. aber ich kann mich nicht erinnern, jemals eine "new config" erstellt zu haben. Vielleicht ist das der sauberste weg, aber man kann doch eigentlich auch nur den cache-Pool löschen und neu anlegen, oder? In den neueren Versionen kann man einen Pool löschen, indem man die Slots auf 0 setzt. ich weiß daß ich noch bei unraid 6.9.x Probleme hatte, einen Pool los zu werden. Aber das ist auch schon länger her. Mach es, wie Du willst. Meine wortreiche Beschreibung war ja nur ein gangbarer Weg. 👍 5 hours ago, _alo_ said: Ich hab von Anfang an "directory" als data root, also kein image und bislang keine erkennbaren Probleme mit btrfs. Der Extraschritt betritt nur, wenn man Docker in einer image vDisk nutzt, welche per Default ja btrfs ist. Wenn Du Directory nutzt, wird kein solches Image benutzt, dann betrifft Dich dieser Extraschritt auch nicht. 5 hours ago, _alo_ said: dieser alte Beitrag bringt mich aber wieder zum grübeln, ob ich das überhaupt machen sollte.... Ja, es gibt dazu unterschiedliche Meinungen und Es gibt Leute die damit nie Probleme haben oder auch wissen sie zu beheben. Es gibt aber immer auch wieder Berichte von problemen, die sich dann im Endeffekt auf btrfs Probleme zurückführen lasen. Die einzig richtige Antwort für alle Fälle gibt es aktuell nicht, deswegen hat man ja die Auswahl. Ich umgehe die btrfs Probleme, so weit wie möglich, indem ich es ebe nicht einsetze. Edited January 24, 20251 yr by DataCollector Typo
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.