NAS Software gesucht - OMV, FreeNAS, xigmanas, oder was anderes?

Halus

Lt. Junior Grade
Registriert
Juli 2013
Beiträge
373
Keine Ahnung ob das hier reingehört.

Ich bin auf der Suche nach einer Software für:
Fileserver
Emby/Kodi
Backup Server

Rein kommen zumindest mal vier Festplatten, die bereits beschrieben sind.
Einfache Redundanz, wichtigste Daten werden auf externe HDD gesichert.

Jetzt habe ich hier das Problem mit zfs, oft heißt es nämlich, dass es nicht möglich ist eine neue einzelne Platte hinzuzufügen. Einzige Möglichkeit wäre die einzelne Platte als eigenen Pool laufen zu lassen, was mit zfs ziemlich sinnlos wäre.
Habe ich das richtig verstanden?

Ansonsten wäre wohl OMV mit mergerfs + snapraid die beste Option. Allerdings ist die Oberfläche ziemlich langsam, was eigentlich egal sein sollte, wenn alles läuft.
xigmaNas hat irgendwie eine kleinere Community.

Was gäbe es sonst noch interessantes? Ich habe noch unRaid gefunden aber bin mir nicht sicher.
 
Hab mir vor 2-3 Monaten ein unRaid NAS gebaut und kann es nur empfehlen.
Kostet zwar etwas aber ist dafür super einfach zu verwenden.
Hab mir dafür ein paar Tutorials von Spaceinvader One angeschaut. Gibt dort für fast alle Themen etwas.

Auf dem NAS laufen bei mir neben dem Fileshare noch zusätzlich ein Plex Server, Pihole, Wireguard VPN.
Gibt für die meisten Themen fertige Docker Container die man dann nur mehr auf die eigenen Bedürfnisse anpassen muss.
 
  • Gefällt mir
Reaktionen: HisN
Halus schrieb:
Habe ich das richtig verstanden?

Ja. Du kannst neue Festplatten zu einem neuen VDEV hinzufügen und dieses VDEV dann dem Pool.

Unraid ist auch eine super Software - aber kostet halt Geld. Würde einfach mal OMV testen. Wenn es dir zusagt: Passt. Wenn nicht: unRaid testen.
 
Einen bestehenden ZFS Pool kann man ohne weiteres nicht erweitern, das stimmt. Allerdings ist ZFS ein wirklich gutes FS mit Snapshots, Prüfsummen und wenn man die HW-Power hat Deduplikation.

Zu XigmaNas kann ich nichts sagen, ebenso Unraid. OMV hab ich selbst schon getestet und muss sagen, dass es in der Einrichtung sehr einfach ist. Auch gut mit Plugins erweiterbar. Ggf kann man aber auch noch normale Debian Repos hinzufügen, falls es kein Plugin gibt.
Wieso eigentlich Snapraid bei OMV? OMV kann auch mdadm ootb. Aber gut beides hat seine Vor- und Nachteile.
 
Ich nutze seit Jahren ein OMV-NAS mit verschlüsseltem ZFS-Pool (3x6 TB+SSD-Cache)
Die Plugin-Strategie wurde mit dem Wechsel von OMV4->OMV5 geändert, sodass es weniger Plugins via OMV-Extras gibt und mehr und mehr via Docker gelöst wird. Docker und Portainer als GUI dafür lassen sich einfach via Webinterface installieren; Container und Dienste in Betrieb nehmen ist wirklich leicht. Mit Watchtower lassen sich automatisierte Updates, falls gewünscht realisieren.
Ich nutze folgende Dienste/Docker:
  • Samba/NFS
  • DLNA
  • USB-Backup (Rsync)
Docker:
  • Letsencrypt Reverse Proxy
  • MariaDB
  • Bitwarden
  • Minecraft Paper + DynMap
  • RCON
  • Nextcloud
  • Calibre Server
  • Redis
  • Duplicati
  • motioneye (5 Kameras)
  • 4 Octoprint für 3D Drucker
  • Watchtower
@Chris_S04: Warum Snapraid? Wer kein ZFS nutzt kommt so an Snapshots, was Dir ein mdadm-Raid nicht bietet.

Einzige Möglichkeit wäre die einzelne Platte als eigenen Pool laufen zu lassen, was mit zfs ziemlich sinnlos wäre.
Warum? Hash-Files deiner Daten werden doch generiert, das Ziel von ZFS ist es Bit-Rot bzw. Silent Data Corruption vorzubeugen und deine sich langsam zersetzenden Daten mit ihren Hashfiles zu vergleichen und die Fehler zu korrigieren (Scrubs)
Leider ist es nicht so einfach ein ZRaid zu erweitern, aber seien wir ehrlich ist es wirklich sinnvoll eine weitere Platte dazuzuhängen? Tauscht man nicht sein altes 3x2TB-Raid bei enger Kapazität und Nutzung über einen längeren Zeitraum gegen einen komplett größeren Stack aus? Denn genau das geht bei ZFS. (Schon aus Energetischer Sicht ist es eher sinnvoll die Platten zu tauschen als immer mehr hinzuzufügen)
Dass die Oberfläche von OMV recht langsam ist habe ich nicht feststellen können (4C/8T Xeon, 32 GB ECC RAM), kommt wohl auch auf die Plattform an, die man nutzt.
 
Zuletzt bearbeitet:
Ich bin von XigmaNAS zu OMV gewechselt mit OpenZFS, da mich FreeBSD irgendwann einfach nur noch genervt hat und XigmaNAS auch mind. 1x im Jahr ("der eine Reboot" so ungefähr) seine Konfiguration verloren hat. Außerdem ist es mit Docker auf FreeBSD so eine Sache.
Bei Linux/Debian fühle ich mich einfach wohler. OMV läuft seitdem auch top. Docker kann ich nun endlich auch nutzen. Wurde ja schon beschrieben. Das ZFS läuft unter OMV auch gut, die Migration des bestehenden Pools lief problemlos. Lediglich um den SSD-Cache, den @riff-raff angesprochen hat, komme ich wohl nicht herum, da OpenZFS sich da bei großen Datenmengen "schwer tut" sag ich mal sehr vereinfacht. Das ist bis jetzt aber der einzige Nachteil von OMV ggü. XigmaNAS und die Vorteile überwiegen für mich klar, daran hat sich auch nach nun mehreren Monaten im Einsatz nichts geändert.
Die OMV Oberfläche läuft auf einem Turion II mit 8GB ECC RAM akzeptabel schnell.
 
Unraid anschauen.
So viele Platten wie man will, nachträglich mit oder ohne Resilenz. Platten dazuhängen kein Problem. Und wenn eine abkackt ist tatsächlich nur der Inhalt der Platte weg, wenn keine Resilenz vorhanden ist.
Fuse Dateisystem, d.h. Du hast am Ende eine Große Platte mit Ordnern und musst Dich nicht darum kümmern wo die Dateien physikalisch auf den Platten landen. Docker supersimpel. Userverwaltung Supersimpel. Natürlich mit SSD-Cache wenn man möchte. Guter Support/Foren. Preiswert. Einfach auszuprobieren.
 
Zuletzt bearbeitet:
gaym0r schrieb:
Ja. Du kannst neue Festplatten zu einem neuen VDEV hinzufügen und dieses VDEV dann dem Pool.

Okay, ich verstehe zfs einfach nicht. Da findet man so viel Zeug darüber und anscheinend auch viel Bullshit.
Wie genau fügt man jetzt eine neue Platte ein?

Chris_S04 schrieb:
Wieso eigentlich Snapraid bei OMV? OMV kann auch mdadm ootb

Kannst du mal verlinken? Ich finde zu ootb nichts.

riff-raff schrieb:
Warum? Hash-Files deiner Daten werden doch generiert, das Ziel von ZFS ist es Bit-Rot bzw. Silent Data Corruption vorzubeugen und deine sich langsam zersetzenden Daten mit ihren Hashfiles zu vergleichen und die Fehler zu korrigieren (Scrubs)
Leider ist es nicht so einfach ein ZRaid zu erweitern, aber seien wir ehrlich ist es wirklich sinnvoll eine weitere Platte dazuzuhängen?

Da brauch ich doch trotzdem eine zweite Platte dafür oO?

Ah, hatte gar nicht an PiHole gedacht. Kommt auch noch drauf.


Cai-pirinha schrieb:
Ich bin von XigmaNAS zu OMV gewechselt mit OpenZFS, da mich FreeBSD irgendwann einfach nur noch genervt hat und XigmaNAS auch mind. 1x im Jahr ("der eine Reboot" so ungefähr) seine Konfiguration verloren hat. Außerdem ist es mit Docker auf FreeBSD so eine Sache.

Ja, Linux kenne ich mich besser aus als BSD, daher habe ich irgendwie kein allzu großes Interesse an Xigma.

HisN schrieb:
So viele Platten wie man will, nachträglich mit oder ohne Resilenz.

Wenn, man mehr Geld zahlt ;)
 
Kostet weniger als ne 8TB Platte, als nicht gerade ein Weltuntergang :-)
Bei Deiner Plattenmenge kommste aber billiger davon^^
 
Halus schrieb:
Kannst du mal verlinken? Ich finde zu ootb nichts.
Bin mir gerade nicht sicher, was Du nicht verstanden hast. Also hier Mal der Link zu Raid in OMV

https://openmediavault.readthedocs.io/en/5.x/administration/storage/raid.html

ootb heißt einfach nur "out of the box", also ohne zusätzliche Pakete, Plugins, etc.. Ist alles schon im Kernel vorhanden.

Mdadm unter OMV ist halt einfach, aber beispielsweise OpenZFS natürlich unterlegen. Snapraid habe ich noch nie verwendet, weil ich immer den nachträglichen Sync nicht mochte, aber es hat seine Vorteile.
 
Halus schrieb:
Okay, ich verstehe zfs einfach nicht. Da findet man so viel Zeug darüber und anscheinend auch viel Bullshit.
Wie genau fügt man jetzt eine neue Platte ein?

Wieso denkst du, dass du es nicht verstanden hast? Es ist doch genau wie du sagst, ich hab dich nur bestätigt und das noch weiter aufgeführt.
Das ganze Paritiy-Gedöhns findet innerhalb des VDEV statt. Wenn du nun eine Platte dem Pool hinzufügen willst, brauchst du ein neues VDEV. In diesem VDEV gibt es nun eine Platte - komplett unabhängig von dem anderen VDEV. Du hast also keine Parity etc.
Und wenn ein VDEV failed, ist der ganze Pool im Eimer.

Vielleicht hilft das: https://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html

Fault-tolerance or redundancy is addressed within a VDEV. A VDEV is either a RAID-1 (mirror), RAID-5 (RAIDZ) or RAID-6 (RAIDZ2). It can even use tripple parity (RAID-Z3) but I doubt many of you will ever need that.


So it's important to understand that a ZFS pool itself is not fault-tolerant. If you lose a single VDEV within a pool, you lose the whole pool. You lose the pool, all data is lost.
 
Halus schrieb:
mergerfs + snapraid
Hatte ich mal funktioniert auch, ist aber hauptsächlich für write once read many geeignet. Also wenn die Daten sich ständig ändern, dann muß man sehr viel syncen, was die Platten stark belastet.

ZFS hatte ich auch mal. Bei ZFS on Luks mit 6 Platten braucht es eine starke CPU. Wegen dem Kernel Problemen, würd ich's aktuell nicht auf Linux einsetzen.

Ich werf mal BTRFS RAID1 in den Ring. Beliebig erweiterbar und mit snapshots.
 
  • Gefällt mir
Reaktionen: riff-raff
BTRFS leider nur via Terminal bedien- und konfigurierbar (zumindest unter OMV). Was spricht gegen ZFS und Linux? Anderes Lizenzmodell, aber das bis auf die Kernelmodule, die installiert werden müssen (automatisch) und nicht mitgeliefert werden seh ich da nichts was dagegen spricht.
Mit LUKS kombiniert braucht es auch keine starke CPU, sie muss nur AES beherrschen.
Unter OMV ist die Snapshot und Scrub-Konfiguration via Plugin im Webinterface möglich.
Was ich mir wünschen würde wäre unter Linux der native Support der ZFS-eigenen Verschlüsselungsmethodik.

Wenn BTRFS eine bessere Usability und Zugang zu seinen Komfortfeatures bekäme würde ich wechseln.
 
Chris_S04 schrieb:
ootb heißt einfach nur "out of the box", also ohne zusätzliche Pakete, Plugins, etc.. Ist alles schon im Kernel vorhanden.

hmm, hab wohl doch richtig verstanden.
Aso, ich habe extra nach ootb gesucht...

Achso, das hat ja schon einen eingebauten Software Raid, dachte das es nur eine Pooling Software wäre.
Level 1/4/5 sieht gut aus.


gaym0r schrieb:

Okay, habe es doch verstanden.
Aber riff raffs Kommentar lässt es so anhören als ob eine Platte ausreichend ist für Parity.

cgs schrieb:
Bei ZFS on Luks mit 6 Platten braucht es eine starke CPU. Wegen dem Kernel Problemen, würd ich's aktuell nicht auf Linux einsetzen.

Ich werf mal BTRFS RAID1 in den Ring. Beliebig erweiterbar und mit snapshots.
urgh, and die CPU hatte ich gar nicht gedacht. Die CPU, die ich drin habe, ist schon sehr schwach.
BTRFS habe ich bereits mehrmals angeschaut aber es wurde immer wieder angemerkt, dass es für normale Verwendung besser ist einfach ext4 zu nehmen.

riff-raff schrieb:
BTRFS leider nur via Terminal bedien- und konfigurierbar (zumindest unter OMV). Was spricht gegen ZFS und
Wenn BTRFS eine bessere Usability und Zugang zu seinen Komfortfeatures bekäme würde ich wechseln.

Wenn alles läuft dann wäre es doch recht egal ob es eine UI gibt oder nicht?


Es läuft wohl auf OMV hinaus.
Was ist da zu empfehlen: mdamd oder mergerfs + snapraid? Wenn ich das richtig sehe, dann sind unterschiedliche Platten in mdamd zwar möglich aber mit zusätzlichen schritten verbunden.
btrfs ist laut der Projektseite in Raid56 instabil.
 
Parität ist nicht mit Prüfsummen zu verwechseln.

Verteilte Paritätsinformationen sollen den Ausfall einer Platte kompensieren, Prüfsummen sollen Bit-Bot im Pool vermeiden.

Das sind zwei komplett verschiedene Dinge.
 
  • Gefällt mir
Reaktionen: gaym0r
Naja, aber um Bit rot wieder rückgängig zu machen sind die Prüfsummen allein ja nutzlos.
Ohne Parity wird es nicht möglich sein die Originaldateien wieder herzustellen, nur zu erkennen.
 
@Halus :
Oh mann,"Viele Köche verderben den Brei!".

Setz einfach einen OMV auf einem Raspi mit einen paar Platten auf und teste es. BananaPi oder OrangePi geht auch, und ein alter PC mit Sockel 755 würde es auch tun. Ordentliche und getestete Backups werden einfach vorausgesetzt!
 
Zuletzt bearbeitet:
Zurück
Oben