Hi, ich habe 2 NVME als Cache im Raid 1 mit BTRFS.

Ich ermute, dass eine meiner beiden NVMEs defekt ist, hätte aber gerne, bevor ich jetzt loslaufe und mir ne neue hole, gerne eine kompetente Zweitmeinung ob meine Annahme korrekt ist.

Dazu auch anbei die Diagnostics: skynet-diagnostics-20250623-1229.zip

4 minutes ago, HGWBLN said:

Ich ermute, dass eine meiner beiden NVMEs defekt ist, hätte aber gerne, bevor ich jetzt loslaufe und mir ne neue hole, gerne eine kompetente Zweitmeinung ob meine Annahme korrekt ist.

massig btrfs Fehler, ja

zumindest mal scrub ausgeführt ?

bevor ich wegen btrfs Fehlern ne neue SSD kaufen würde, Daten sind gesichert ? wenn ja, Platt machen, neu aufsetzen, Sicherung einspielen ...

wenn Nein, Daten sichern !!! außer .../system/docker/... das ist schneller wiederhergestellt als eine Sicherung vor / retour.

btrfs crasht halt gerne mal (leider) auf vielen Systemen ... gerne nach unclean shutdowns ... aber auch so passiert das leider häufiger.

2 minutes ago, alturismo said:

massig btrfs Fehler, ja

zumindest mal scrub ausgeführt ?

bevor ich wegen btrfs Fehlern ne neue SSD kaufen würde, Daten sind gesichert ? wenn ja, Platt machen, neu aufsetzen, Sicherung einspielen ...

wenn Nein, Daten sichern !!! außer .../system/docker/... das ist schneller wiederhergestellt als eine Sicherung vor / retour.

btrfs crasht halt gerne mal (leider) auf vielen Systemen ... gerne nach unclean shutdowns ... aber auch so passiert das leider häufiger.

Vielen Dank für die schnelle Antwort. Wenn ich die SSDs eh komplett platt machen sollte, wäre dann ZFS das bessere Format oder sollte ich die beiden NVMEs als Single Disk laufen lassen ohne Raid 1?

Edited June 23, 20251 yr by HGWBLN

Zu Deinem Problem: der Datenträger mag okay sein, aber zumindest das btrfs basierte Dateisystem hat 'nen Schlag weg.

22 minutes ago, HGWBLN said:

Wenn ich die SSDs eh komplett platt machen sollte, wäre dann ZFS das bessere Format oder sollte ich die beiden NVMEs als Single Disk laufen lassen ohne Raid 1?

Meine persönliche Meinung: bei einzelnen Datenträgern und im Array: xfs

Bei Verbund mehrerer Datenträger bei unraid 6.12.x oder höher: zfs

Bei Problemen mit unraid hat sich zu oft btrfs als Auslöser oder zumindest beteiligt gezeigt. btrfs = böse. :)

Und: man sollte genau überlegen ob man überhaupt sowas wie Raid1 braucht.

Ich würde im privaten Umfeld ohne wirklich lebenswichtige Anwendungen xfs Single Disk bevorzugen, von dem je nach Notwendigkeit ein Backup erstellt wird.

Edited June 23, 20251 yr by DataCollector

47 minutes ago, HGWBLN said:

Vielen Dank für die schnelle Antwort. Wenn ich die SSDs eh komplett platt machen sollte, wäre dann ZFS das bessere Format oder sollte ich die beiden NVMEs als Single Disk laufen lassen ohne Raid 1?

meine Meinung hierzu, siehe beispielsweise hier ;) aber kurz, ist analog @DataCollector 🙂

moin, um der "raid 1" Sache auch noch mal die sinlosigkeit zu zeigen. Würde nur helfen, wenn eine Platte von jetzt auf gleich stirbt. In den meisten Fällen wird erstmal "Grütze" geschrieben und die ist parallel auch dem Verbundlaufwerk .... hilft dir kein Stück. Eventuel wäre es ein Thema in Bezug auf "hochverfügbar"

Zum Thema "ZFS" kann ich nicht beitragen, aber mit der Lösung eine 2. cacheplatte mit Backups im System zu haben, fühl ich mich eigenermassen safe. Hatte aber noch keine nennenswerten Probleme übe die Zeit ..... ooooh gott, jetzt habe ich es ausgeprochen/ geschrieben ☠️ ;)

2 hours ago, trebeis said:

moin, um der "raid 1" Sache auch noch mal die sinlosigkeit zu zeigen. Würde nur helfen, wenn eine Platte von jetzt auf gleich stirbt. In den meisten Fällen wird erstmal "Grütze" geschrieben und die ist parallel auch dem Verbundlaufwerk .... hilft dir kein Stück. Eventuel wäre es ein Thema in Bezug auf "hochverfügbar"

Zum Thema "ZFS" kann ich nicht beitragen, aber mit der Lösung eine 2. cacheplatte mit Backups im System zu haben, fühl ich mich eigenermassen safe. Hatte aber noch keine nennenswerten Probleme übe die Zeit ..... ooooh gott, jetzt habe ich es ausgeprochen/ geschrieben ☠️ ;)

Also auf die Begründung bin ich jetzt aber gespannt, warum die zweite Platte bei einem RAID 1 "Grütze" schreiben sollte, wenn es es die erste tut. Vorab: Ein RAID (außer RAID0) dient immer nur der Redundanz und ist kein Backup!

Ein RAID Verbund immer von einem Controller gesteuert. Ob Hardware- oder Softwarebasis ist dabei erst Mal egal. Der Controller verteilt die Daten auf die Platten gemäß RAID Config (RAID1 = spieglen, RAID5 usw. = Striping.

Wenn jetzt eine Platte aus welchen Gründen auch immer nur noch "Grütze" schreibt, erkennt dass der RAID Controller und schmeißt diese Platte aus dem RAID, womit dieser "degraded" ist. Die Daten sind jedoch immer noch durch die anderen Platten verfügbar.

Nach deiner Logik (sofern ich dies richtig verstanden habe) werden die Daten erst auf eine Platte geschrieben und dann von dort auf die zweite Platte kopiert. Dies ist nicht der Fall.

Macht ein RAID Pool für den Cache Sinn?

• Wenn es einem Wichtig ist, dass Docker, VMs und Daten verfügbar bleiben, wenn ein Cache Drive ausfällt, dann definitiv ja (dennoch nie die Backups vergessen!).

• Wenn es einem egal ist, dass für die Zeit bis zum Austausch der defekten Cache Disk und dem zurückspielen des Backups gewisse Dienste und Daten solange nicht verfügbar sind, dann brauch man definitiv keinen RAID.

Bei einem RAID ist zudem noch eine USV zu empfehlen. BTRFS und RAID reagieren gerne empfindlich bei plötzlichem Stromverlust.

Edited June 26, 20251 yr by Gorosch

15 minutes ago, Gorosch said:

Also auf die Begründung bin ich jetzt aber gespannt, warum die zweite Platte bei einem RAID 1 "Grütze" schreiben sollte, wenn es es die erste tut.

das hatte mich auch zum Grübeln gebracht...

Mit der Begründung (wenn ich die richtig verstanden habe) wäre ja sonst eine parity beim Array auch irgendwie sinnlos 🤔

15 minutes ago, Gorosch said:

Macht ein RAID Pool für den Cache Sinn?

• Wenn es einem Wichtig ist, dass Docker, VMs und Daten verfügbar bleiben, wenn ein Cache Drive ausfällt, dann definitiv ja (dennoch nie die Backups vergessen!).

• Wenn es einem egal ist, dass für die Zeit bis zum Austausch der defekten Cache Disk und dem zurückspielen des Backups gewisse Dienste und Daten solange nicht verfügbar sind, dann brauch man definitiv keinen RAID.

die Liste würde ich noch erweitern:

• wenn es einem wichtig ist, möglichst keine Daten zu verlieren (die zwischen Mover/Backup und Ausfall), dann definitiv ja

• wenn es einem egal ist, dass man bei einer defekten Cache-Disk diese Daten verliert, dann braucht man kein RAID

Der Punkt "Schreibcache" fehlt mir hier öfter in den Diskussionen, weil viele sich immer auf docker/VM beziehen und ja, die wenigen Daten, die da pro Tag anfallen sind ggf. zu reproduzieren (z.b. paperless: neu einscannen) oder zu verschmerzen (z.B. fehlende Verlaufsdaten in Homeassistant/grafana). Ob fehlende Dienste (Heimautomatisierung) jetzt wichtig sind oder nicht, ist natürlich erst recht sehr individuell.

Aber was mich wundert: Viele sehen RAID auf dem (Schreib-)Cache als sinnlos an, haben aber 1-2 parity Laufwerke im Array.

Daher meine Frage an euch aus Interesse: Wie arbeitet ihr mit eurem unraid-NAS?

• habt ihr keinen Schreibcache auf den Shares für "wichtige" Daten konfiguriert?

• wenn doch, wie oft läuft euer Mover oder ein anderes Backup solcher Daten?

• verschiebt ihr keine Daten auf den Server, sondern kopiert erstmal nur und löscht später auf der Quelle, wenn die Daten sicher(er) auf dem Array oder im Backup liegen?

• oder ist unraid bei euch eh nur Backup für Daten, die noch woanders liegen? (DANN wäre mir die Schreibcache Redundanz auch egal, aber dann hätte ich auch keine parity)

• oder habt ihr keine für euch "wichtigen" Dateien?

Also ich verstehe die Herangehensweise "single-Schreibcache + Array mit parity" irgendwie nicht....

9 minutes ago, _alo_ said:

Der Punkt "Schreibcache" fehlt mir hier öfter in den Diskussionen

Deswegen ja der Punkt mit den "gewissen Diensten und Daten". Alles, was auf dem Cache ist, ist natürlich weg, wenn keine Redundanz vorhanden ist. Sowohl Appdata, Docker und Daten, welche noch nicht im Array liegen oder bewusst nur um Cache liegen.

Zu deinen Fragen und wie es bei mir ist:

• habt ihr keinen Schreibcache auf den Shares für "wichtige" Daten konfiguriert?

  • Ich habe zwei Cache Pools: 2x 256 GB SSDs für Docker und Appdata, 2x 4TB SSDs als Cache für das Array (alles SATA SSD mit jeweils RAID1 pro Pool

  • Alle Shares führen immer zuerst auf den großen Cache. Manche Shares liegen auch nur auf dem Cache, wie z.B. meine Musik Sammlung für den Roon Server.

  • Ziel ist es, so wenig wie möglich die Plattten hoch drehen zu lassen.

• wenn doch, wie oft läuft euer Mover oder ein anderes Backup solcher Daten?

  • ich Nutze das Mover Tuning Plugin. Sobald der Cache auf 85% Vollläuft, werden die älteren Daten auf dem Cache in Array geschoben, bis der Cache wieder auf unter 60% fällt. Dies wird jeden Tag geprüft.

  • Alle drei Monate wird jedoch alles immer zum 28. des Monats auf das Array verschoben, was da hin soll. Somit blieben neue Daten länger im Cache liegen, womit sie schneller abrufbar sind und ebenfalls wieder Spinups vermeidet.

• verschiebt ihr keine Daten auf den Server, sondern kopiert erstmal nur und löscht später auf der Quelle, wenn die Daten sicher(er) auf dem Array oder im Backup liegen?

  • Ich verschiebe immer. Sowohl Linux als auch Windows kopiert ja im Hintergund dennoch erst mal nur und löscht die Quelle erst dann, wenn der "kopier" Vorgang erfolgreich war. Spart einem das manuelle löschen.

• oder ist unraid bei euch eh nur Backup für Daten, die noch woanders liegen? (DANN wäre mir die Schreibcache Redundanz auch egal, aber dann hätte ich auch keine parity)

  • Unraid läuft bei als Datengrab für Mediensammlung, Bilder und Dokumente und auch als Medienserver. Somit sind für mich alle Daten wichtig, wen manche auch wichtiger, als andere. Gehen mal ein paar Filme verloren, kommt die BluRay aus dem Keller und wird neu gerippt. Bilder und Dokumente sind daher für mich wichtiger, da diese nicht einfach "neu" gemacht werden können.

• oder habt ihr keine für euch "wichtigen" Dateien?

  • Wie oben schon erwähnt, ist für mich alles wichtig. Daher fahre ich diverse Backups, welche sich an die 3-2-1 Regel orentieren:

    • 1 Backup auf einen extra NAS bei mir Zuhause - komplettes Array - jeden tag

    • 1 Backup auf eine NAS bei meinen Eltern - Nur Dokumente, Bilder und Musiksammlung - jeden Tag

    • 1 Backup verschlüsselt auf B2 Backblaze - Wöchentlich

    • 1 Backup auf eine 5 TB USB HDD, ebenfalls jeden Tag. Wenn es im Notfall schnell gehen muss, wird die eben abgezogen und mitgenommen. Leicht Paranoid, wird hoffentlich nie solch einen Notfall geben. :)

Danke für Deine Antworten

Das läuft bei mir fast identisch 😉

• ich hab auch zwei Cache Pools: 2x 1TB für docker/VM und wenige docker-relevanten Shares, 2x 4TB für Arbeitsdaten, die ich anschließend manuell verschiebe ins Array und shares, die mehr Platz brauchen als Schreibcache

• Wenn ich größere Datenmengen auf den Server schiebe, stell ich auch schonmal den Schreibcache für einzelne shares temporär aus

• Ziel ist es auch bei mir, dass die Platte möglichst selten anlaufen

• das mover tuning plugin hab ich allerdings (noch🤔) nicht in Verwendung, mir reicht aktuell der standardmäßige nächtliche Moverlauf sowie das appdata-Backup Plugin, was auch nachts läuft

• wie die Betriebssysteme "verschieben" ist mir schon klar, es ging mit darum, ob vielleicht jemand kopiert, einen Tag wartet, und dann erst auf seinem PC löscht

• ich verschiebe auch, sonst bräuchte ich ja kein NAS!

• genau, meine selbst erstellte Filmesammlung sichere ich aktuell nur zum Teil, dafür hab ich aktuell zu wenig Plattenplatz im BackupServer, die kann man im Ernstfall ja "einfach" neu erstellen, aber die persönlichen Dokumente und vor allem Fotos sind mir da auch wichtiger

• ok, Dein Backupkonzept ist mal sehr umfassend 👍

leude, leude ... das letzte was ich wollte, hier ne Grundsatzdiskussion anzuzetteln.

Mich hat das mit der Raid1 getriggert und wollte niemanden auf die Füsse tretten.

Letztendlich, kommt es doch drauf an, wieso jemand einen Server betreibt und was der Zweck ist. Gut, klar ... wer zB eine Nextcloud Instanz betreibt, wo einige andere mit dranhängen hat andere Schwerpunkte, als (wie bei mir) wo die Kiste hauptsächlich als Medienserver vor sich hindümpelt.

Und das Thema Backup ist doch gar nicht relevant gewesen, weils eben ein eigenes Thema ist.

also, in diesem Sinne ... wünsch Euch einen schönen Tag