Umfrage: NAS-Betriebssystem

Welches NAS-Betriebssystem benutzt ihr?

  • DSM / Synology

    Stimmen: 41 35,7%
  • QTS / QNAP

    Stimmen: 15 13,0%
  • UGOS / Ugreen

    Stimmen: 9 7,8%
  • TrueNAS Core

    Stimmen: 3 2,6%
  • TrueNAS Scale

    Stimmen: 18 15,7%
  • UnRaid

    Stimmen: 23 20,0%
  • Open Media Vault

    Stimmen: 14 12,2%
  • XigmaNAS

    Stimmen: 0 0,0%
  • eine "normale" Linux Distribution wie Debian, Redhat und Co.

    Stimmen: 12 10,4%
  • FreeBSD

    Stimmen: 1 0,9%
  • Windows

    Stimmen: 5 4,3%

  • Umfrageteilnehmer
    115
  • Umfrage geschlossen .
Wenn man besonderen Schutz vor Datenverlust durch bitrot oder Abstürze möchte, dann immer was mit ZFS

Wenn es mit ZFS außergewöhnlich stabil sein soll: Solaris/OmniOS
Wenn es das gängigste mit ZFS sein soll: TrueNAS
Wenn man ein Fertig NAS sucht: Ein Qnap mit ZFS

Wenn man besondere VM Fähigkeiten mit NAS kombinieren möchte: Proxmox
dazu ein howto: https://napp-it.org/doc/downloads/proxmox.pdf

Wenn man besonders einfach und detailliert ACL Rechte verwalten möchte:
Was mit nfs4/ntfs (Windows, Solaris, OmniOS, mit leichten Einschränkungen Free-BSD)

Gerade am Werden: Windows mit OpenZFS, fast fertig als Ergänzung zu Storage Spaces (Pools mit Platten unterschiedlicher Art und Größe) mit Tiering. Zusammen mit Windows Server (Essentials) zusätzlich mit Active Directory und SMB Direct (kann SMB mit 3-10 Gbyte/s auch für Multiuser z.B. 4K Videoediting)
 
gea schrieb:
Wenn man besonderen Schutz vor Datenverlust durch bitrot oder Abstürze möchte, dann immer was mit ZFS
Welche Abstürze?
Also bei einem Kernel Panic etc. kann kein Dateisystem der Welt was retten. Im Gegenteil, umso komplexer umso mehr kann theoretisch kaputt gehen.

Was so Datensicherheit durch Prüfsumme etc. angeht, ist ZFS beileibe nicht das einzige Dateisystem, welches solche Features bietet.
Was man höchstens sagen kann, das es ZFS halt schon sehr lange gibt und es dementsprechend abgehangen ist.

gea schrieb:
Wenn es mit ZFS außergewöhnlich stabil sein soll: Solaris/OmniOS
Irgendwann hat sich ZFS ja mal aufgespalten in das, was heute eben noch in Solaris zum Einsatz kommt und das, was via zfsonlinux dann in OpenZFS aufgegangen ist.
Inwiefern ist dieses ZFS stabiler?

gea schrieb:
mit leichten Einschränkungen Free-BSD
Worin bestehen denn die Einschränkungen?

gea schrieb:
Windows mit OpenZFS, fast fertig als Ergänzung zu Storage Spaces (Pools mit Platten unterschiedlicher Art und Größe) mit Tiering. Zusammen mit Windows Server (Essentials) zusätzlich mit Active Directory und SMB Direct (kann SMB mit 3-10 Gbyte/s auch für Multiuser z.B. 4K Videoediting)
Windows will man doch eigentlich nicht wirklich als Server einsetzen. :-)
 
1. ZFS hat neben Prüfsummen eine weitere Innovation: Copy on Write
Das sorgt dafür dass eine atomare Schreiboperation immer vollständig ist z.B. Daten + Metadaten schreiben oder Raid-Stripe über alle Platten schreiben. Das muss immer ganz oder garnicht geschehen. Nur btrfs und ReFS (oder Netapp Wafl) bieten das auch, ntfs oder ext4 können das nicht.

2. Seit ein paar Jahren gibt es 4 getrennte ZFS Entwicklungszweige
die unabhängig voneinander weiterentwickelt werden

  • Oracle Solaris, der Ursprung (mit "nativ ZFS v.54, inkompatibel zu Illumos oder OpenZFS)
  • Illumos, damit startete das freie ZFS, Vater von OpenZFS als fork von OpenSolaris
  • OpenZFS, bis 2019 = Illumos, seither eigenständig
  • Qnap ZFS, basiert auf einem früheren OpenZFS

Wenn man Illumos mit OpenZFS vergleicht, so stellt man fest dass Illumos in 10 Jahren nicht soviel Probleme hatte wie OpenZFS im letzten Jahr. Illumos ist viel konservativer als OpenZFS was die Integration neuer OpenZFS Features angeht. Stabilität geht da vor. Bei OpenZFS reift manches beim Kunden.

3. nfs4 ACL wurde bei Sun/Solaris als Reaktion auf ntfs ACL entwickelt und ist bei Solaris/Illumos am ausgereifsten. Hinzu kommt dass der Solaris/Illumos SMB Server SMB Gruppen (mit Gruppen in Gruppen) kann und weltweit eindeutige Windows SID als Dateireferenz (statt uid/gid) kann. Free-BSD und Linux haben das nicht.

4. Es gibt unterschiedliche Lösungen für unterschiedliche Anforderungen.
 
  • Gefällt mir
Reaktionen: andy_m4
gea schrieb:
ZFS hat neben Prüfsummen eine weitere Innovation: Copy on Write
Das sorgt dafür dass eine atomare Schreiboperation immer vollständig ist z.B. Daten + Metadaten schreiben
Auch das ist kein Alleinstellungsmerkmal.

gea schrieb:
Nur btrfs und ReFS
Ich würde da auch noch Dateisysteme wie bcachefs und HAMMER2 mit dazu tun.

gea schrieb:
Bei OpenZFS reift manches beim Kunden.
Ja. Naja.
Kommt drauf an, wer ZFS benutzt. Von dem data corruption bug in OpenZFS 2.2 beispielsweise war FreeBSD nicht betroffen (zumindest nicht, wenn man nicht an den defaults gedreht hat).

gea schrieb:
Illumos ist viel konservativer als OpenZFS was die Integration neuer OpenZFS Features angeht. Stabilität geht da vor.
Wobei das Hit&Miss ist. Weil OpenZFS führt ja durchaus auch sinnvolle Neuerungen wie Fast-Dedup oder RAIDZ-Expansion ein.

Aber ja. Generell ist ja eine konservative Entwicklung bezüglich der Datensicherheit nicht verkehrt.
 
ZFS bietet halt von allen guten Optionen mit Abstand die meisten Features und ist ziemlich ausgereift. Dazu gibt es OpenZFS auf Free-BSD, Illumos (Unix, OpenZFS kompatibel), Linux, OSX (released) und Windows (release candidate 8, fast fertig - kaum noch Probleme).

Mit Linux habe ich das Problem der vielen Distributionen, jede mit einem anderen ZFS Versionsstand, damit anderen Problemen. Ein Update erfolgt bei jeder gerne mal anders und neuestes wird nicht immer sofort angeboten. Ob ein Bug auf die eigene Distribution schon oder noch zutrifft, ist fast nicht nachvollziehbar.
 
Naja man kann es ja auch unter Linux fast überall vergleichsweise einfach kompilieren wenn man immer das aktuellste haben will.

https://openzfs.github.io/openzfs-docs/Developer Resources/Building ZFS.html
Ergänzung ()

andy_m4 schrieb:
Auch das ist kein Alleinstellungsmerkmal.


Ich würde da auch noch Dateisysteme wie bcachefs und HAMMER2 mit dazu tun.


Ja. Naja.
Kommt drauf an, wer ZFS benutzt. Von dem data corruption bug in OpenZFS 2.2 beispielsweise war FreeBSD nicht betroffen (zumindest nicht, wenn man nicht an den defaults gedreht hat).

Hmm meines Wissens war der Bug schon seit extrem vielen Jahren drin (seit über 15 Jahren evtl sogar 20) es gab nur Einstellungen in denen er wahrscheinlicher auftrat. z.B. eine aktuellere Version der coreutils.
 
Zuletzt bearbeitet:
Ich möchte nicht für jeden Anwendungsfall ein anderes Linux, dann da ZFS kompilieren um der erste zu sein der ein Problem in dieser Kombination entdeckt und der einzige der eine Lösung sucht.

Der Grund, dass ich immer Proxmox nehme, auch. als barebone ZFS Storagerver. Gut gepflegtes Debian mit ZFS immer´dabei und dazu überragende VM Fähigkeiten.
 
Das ja auch nuir dann notwendig wenn man unbedingt jetzt ein neues Feature will oder ein wirklich krirtischer Bug entdeckt wurde der zu Datenverlust führen kann.

Den 15+ oder 20 Jahre alten ZFS Bug hatte Proxmox sicher auch drin.

Truenas überarbeitet sein VM System aktuell deutlich mal schauen

https://www.truenas.com/docs/scale/25.04/scaletutorials/instances/

Wenn man viel mit VMs und Co macht ist Proxmox sicher die bessere Wahl bei TrueNAS ist das mehr so nen rangebasteltes Addon xD
 
Zuletzt bearbeitet:
Am großen Filer hab ich ein Unraid am laufen.
Am kleinen 6W 24/7 NVMe-Server läuft ein Mini-Debian mit Samba-Freigabe.
Allerdings brauch ich bei dem auch kein Schnulli, den einen die NAS-OS abnehmen. Ich hatte erst ein OMV drauf, aber das ist viel zu fett dafür, was das Ding leisten muss.
 
Zuletzt bearbeitet:
gea schrieb:
Mit Linux habe ich das Problem der vielen Distributionen, jede mit einem anderen ZFS Versionsstand, damit anderen Problemen.
Ist halt die Frage, inwieweit das wirklich ein Problem ist. Das wäre ja nur eines, wenn Du ein Pool zwischen mehreren Linux-Distributionen teilen würdest. Das macht ja (außer zu Testzwecken) keiner. Sondern man entscheidet sich für eine Distribution und betreibt damit dann sein ZFS.

gea schrieb:
um der erste zu sein der ein Problem in dieser Kombination entdeckt und der einzige der eine Lösung sucht.
Das Problem kann Dir aber auch bei OmniOS/ZFS passieren, ganz einfach, weil das System von vergleichsweise wenigen Leuten eingesetzt wird.

Uzer1510 schrieb:
Hmm meines Wissens war der Bug schon seit extrem vielen Jahren drin
Ja. Aber erst mit OpenZFS 2.2.0 wurde er wirklich relevant, weils ab da das Block Cloning-Feature gab, welches den Fehler eher provoziert:
https://github.com/openzfs/zfs/issues/15526
Und das Block Cloing war in FreeBSD nicht angeknipst.

Der eigentlich Bug lag dann aber woanders und wurde ja dann auch mit OpenZFS 2.2.2 gefixt.

Generell sind natürlich data corruption bugs in einem Dateisystem eine üble Sache.
Die eigentliche Frage ist aber, ob da konservativ entwickelte ZFS-Zweige wirklich besser dran sind. Da passiert zwar entwicklungstechnischer weniger dran, was Sachen kaputt machen kann. Allerdings sind die auch nicht so weit verbreitet wie OpenZFS und da sind auch nicht so viele Entwickler involviert. Bugs fallen da möglicherweise gar nicht so auf.
 
Zuletzt bearbeitet:
DocSilly schrieb:
Bei mir läuft seit langem OmniOS + napp-it Oberfläche zur Verwaltung. OmniOS kommt aus der Solaris-Linie. Als Filesystem natürlich ZFS, Backups laufen über ZFS-Replication.

Hier ein Bild vom NAS (rechts) und dem Backup (links).

Anhang anzeigen 1620898

Beide Fileserver sind direkt verkabelt über je eine der zwei 10 GBbit Karten (für Replakation Replikation), die jeweils andere hängt am 10 Gbit Switch (der ist passiv gekühlt aber leider auch unmanaged). Dazu ein 1 Gbit für die Verwaltungs NICs, Router, den zwei Raspis und einem Sat-IP Empfänger. Vom 10 Gbit Switch läuft dann ein Kabel Richtung Zockerbude,
Lustig, habe auch 2 von den Cases. Bei mir ist nur das eine aktuell genutzt. Ich bin noch am Überlegen, ob ich das zweite als Backup oder als Erweiterung zum ersten nutzen möchte.
 
@user324543 Entweder man hat schon eine andere Backup-Lösung oder nicht, im letzteren Fall gibt es eigentlich nur eine richtige Antwort (keine Backups = kein Mitleid).

Mein NAS ist mit 24x 16TB bestückt, da gibt es nicht viele Optionen neben einem gleich bestückten Backupsystem. Höchstens irgendwas mit LTO, was aber weniger flexibel ist.

Hab erst letzte Woche den Ernstfall geplant durchgeführt, hat gut 4 Tage gedauert bei durchschnittlich 460MB/s für die initiale Replikation.
 
  • Gefällt mir
Reaktionen: lochmueller
DocSilly schrieb:
Hab erst letzte Woche den Ernstfall geplant durchgeführt
Was übrigens eine sehr gute Idee ist. Ein Backup ist halt nur wirklich ein Backup, wenn auch das Recovery zuverlässig funktioniert. Und das sollte man daher auch mal zumindest angetestet haben.

DocSilly schrieb:
Hab erst letzte Woche den Ernstfall geplant durchgeführt, hat gut 4 Tage gedauert bei durchschnittlich 460MB/s für die initiale Replikation.
Das macht noch auf eine weitere Problematik aufmerksam.
Bei der Filmchensammlung ist das vielleicht egal, ob das Recovery nun 4 Stunden oder 4 Tage dauert.
Aber unter Umständen hat man ja auch wichtige Dateien dabei die man zeitnah braucht. Das Backup sollte also auch die Möglichkeit haben, einzelne Dateien unkompliziert/schnell rauszuziehen. Und das sollte natürlich nicht nur auf dem NAS selbst funktionieren (weil das hat man ja möglicherweise nicht, weil es kaputt gegangen ist), sondern auf jedem Rechner.
 
andy_m4 schrieb:
Das Backup sollte also auch die Möglichkeit haben, einzelne Dateien unkompliziert/schnell rauszuziehen. Und das sollte natürlich nicht nur auf dem NAS selbst funktionieren (weil das hat man ja möglicherweise nicht, weil es kaputt gegangen ist), sondern auf jedem Rechner.
ich nutze dafür einen 2. Unraid mit Replication, sprich, auch alle Docker, Dienste ... laufen dann nahtlos weiter.

Server a/ down, Watchdog (2x vorhandene RPi welche parallel KVM sind) startet per wol Server b/ inkl. Dienste, ist Server a/ wieder up, stoppt Server b/ die Dienste und geht wieder schlafen ...

daher auch zig2mqtt auf einem der externen kvm RPi, SatIP TV Tuner, ... damit die nicht Server gebunden sind, usw usw .. sprich, egal ob Server a/ oder b/ läuft, alle Dienste und Daten da (Medien werden allerdings nur 1x wöchentlich backupped).

es gibt zig Szenarien wie man seine Backups gestalten kann, daher braucht es für mich bei einem NAS auch kein inkludiertes ...
 
  • Gefällt mir
Reaktionen: andy_m4
alturismo schrieb:
daher braucht es für mich bei einem NAS auch kein inkludiertes ...
Ja. Das verstehe ich. Ich mein, es ist gut, wenn es eines gibt. Aber wie Du schon sagst: Die Bedürfnisse sind da recht individuell und es sollte auf jeden Fall die (unkomplizierte) Möglichkeit geben, sich auch selbst darum zu kümmern.
 
Das gleiche System ist halt mehr oder weniger die einzige Backupmöglichkeit. sobald man eine gewisse Grösse überschreitet.

Wir haben unseren Server einfach auch 2x komplett als Backup alle RAIDZ2 und verschiedene Softwarestände undf an verschiedenen Orten.

LTO und Co sind halt einfach als Backup ab 50 TB zu teuer finde ich - ein nicht ausgenudeltes Laufwerk kostet ja dann schon so 3000+?
 
Zudem ist das verfügbare größte LTO 9 mit 18 TB unkomprimiert (45 TB mit Kompression ... aber Filmchen sind schon komprimiert). Dazu kommt die Geschwindigkeit von 400 MB/s (1000MB(s mit Kompr.). Da braucht man schnell nen Superloader, der kommt mit 8 Tapes immerhin auf 144 TB unkomprimiert (360 TB komprimiert).

Im Juni sollen dann die ersten LTO 10 kommen mit 30/75 TB aber wohl "nur" fast gleicher Geschwindigkeit.

Für viele Firmen immer noch eine gängige Offline(Coldstorage) Backup Lösung. Aber nix wenn man schnell an Backupdaten ran muss.

p.s. Sorry wenn ich etwas vom Hauptthema abdrifte
 
DocSilly schrieb:
Entweder man hat schon eine andere Backup-Lösung oder nicht, im letzteren Fall gibt es eigentlich nur eine richtige Antwort (keine Backups = kein Mitleid).
Ich habe einen Backup Tower, allerdings nicht für alles (nur die wichtigsten Sachen).
LTO habe ich mir mal angeschaut, aber für mich als Privatperson zu teuer.
 
Man muss halt beim NAS schon auch das Backup gleich mitbedenken ausser es sind nur Temp Daten.
 
Zurück
Oben