News openmediavault 6.0: Neues NAS-Betriebssystem mit Debian 11 und neuem GUI

Hannibal Smith schrieb:
Ein wirklicher Laie dürfte das nicht installiert und eingerichtet bekommen
Denke schon das ein Laie das mit etwas Arbeit hinbekommt. Gibt da sicher genug Anleitungen im Internet für.

Die meisten haben nur zuwenig Lust und zu wenig Geduld sich damit zu beschäftigen und sind schnell frustriert wenns nicht geht.
 
Naja. Wenn man der Anleitung folgt kommt man bestimmt weit aber ich glaube tatsächlich nicht, dass ein Laie der die Anleitung und das technische dahinter nicht versteht überhaupt auf die Idee kommt das umzusetzen. Er kann ja nicht nachvollziehen, ob das nun schwer ist oder nicht
 
Wollte mir die Tage tatsächlich mal Openmediavault anschauen. Hab keine Lust mehr, nfs, smb, dazugehörige Service Discovery, Monitoring usw selbst einrichten zu müssen. Ich hoffe, dass Openmediavault mir da ein bisschen Arbeit abnehmen kann. TrueNAS fällt ja leider raus, da ich bestehende MD-Raids übernehmen will. :)

Blub0r2k schrieb:
die bneutzen einfach mdadm als unterbau für raids und packen dann ext4 oder btrfs als dateisystem drauf.
funzt und ist erprobt, wobei zfs schon deutlich flexibler ist und mehr möglichkeiten bietet.
Also gerade im Heimbereich finde ich ZFS definitiv nicht flexibler. Platten zum bestehenden Raid hinzufügen? Ging bis vor kurzem gar nicht und ist jetzt auch noch nicht auf dem Level eines md-Raids (stripe width wird nicht angepasst) und wird es wahrscheinlich auch nie sein. Raid-Level ändern geht genauso wenig. Aber ansonsten: Ja, ich würde ZFS auch bevorzugen, wenn ich weiß, dass meine Festplattenkonfiguration final ist. ZFS hat den Vorteil, dass es weiß, welche Daten wo auf Platte liegen, hat Checksums zu den Daten und kann so bei einem Rebuild im Fehlerfall bessere Entscheidungen treffen. md-Raid kann das leider nicht, btrfs könnte es, da ist nur leider alles außer Raid 0 und 1 broken by design. Allerdings wird das "Feature" meine ich sowieso überbewertet, da es hauptsächlich bei Bitrot und Bitflips helfen würde und da sollte die HDD mit ihren eigenen Checksums eigentlich einen URE liefern.
 
  • Gefällt mir
Reaktionen: SeppoE
Ist es wirklich so kompliziert das System als Laie aufzusetzen?
Oder mal anders gefragt: Hat Jemand der eine Linux-Distribution installieren kann genug Erfahrung OMV zu installieren?
Ergänzung ()

@ -=XoDuS=-
Die Idee eine RPI in ein NAS-Gehäuse zu bauen finde ich echt gut. Darf ich fragen, wie du die Festplatten an den RPI angebunden hast?

 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: -=XoDuS=-
@sylvio2000 klar, das setup ist insofern kein großes Ding. Die Basiskonfiguration lässt sich nach der Installation komplett im Webinterface durchführen. Nutzer anlegen, smb/nfs shares zuteilen und verwalten, Cronjobs anlegen, Protokolle lesen, Hardwareüberwachung…ist alles da integriert. Der Charme aus meiner Sicht ist, dass drunter ein Debian läuft, das man noch sehr nach eigenen Bedürfnissen anpassen kann. Ich hab mir da zB über Docker einen Nextcloud Server aufgesetzt mit DynDNS und Zertifikat Erneuerung und so, nebenher läuft ein Valheim Server. Dafür muss man dann in die Konsole schauen.
 
@ -=XoDuS=-
Vielen Dank schon mal.
Wie viele Festplatten hängen an dem rpi? Und wie hast du sie angebunden und mit Strom versorgt?
 
  • Gefällt mir
Reaktionen: Maj0r Muffin und -=XoDuS=-
Hab die 6er schon ein paar Monate im Betrieb, und kann mich soweit nicht beschweren.
Ich hatte anfangs kleinere Konfigurationsprobleme, lag aber eher an meinem kruden Setup als an OMV selbst.
11x8TB HDDs mit ext4 als Dateisystem, drüber dann ein SnapRAID mit 2 Parity-Platten, und zum ansprechen ein mergerfs drüber.
Ist etwas exotisch, aber man kann aktiv sehr gut selbst Fehler finden und fixen, wenn was nicht klappt. Wenn mir Snapraid kaputt geht, sind meine Daten auch nicht direkt weg, wie es bei einem ZFS/BTRFS wäre, weil das Snapraid auf dem Dateisystem sitzt und die Parity nur Dateiübergreifend generiert, also die einzelnen Dateien auch nur als ganzes auf den HDDs liegen. Fliegt mit das Snapraid mal um die Ohren, sind meine Daten immer noch 1:1 auf den Platten. Recover einer Platte habe ich getestet - funktioniert.
Allerdings eignet sich das Setup so nur für Systeme, auf denen wenig geändert wird. Bei mir ist es ein reiner Media-Server, da ändert sich nicht viel, insofern reicht mir da ein täglicher Sync, statt einem Live-Sync wie es ja bei ZFS/BTRFS/MD-Raid/Hardware-Controller der Fall wäre.
 
....wenn SnapRAID für'n Pi noch funkt., wäre dies im privaten Umfeld wohl eh die bessere RAID alternative, ansonsten über Debian selbst realisieren.. Schade finde ich dass die meiner Ansicht nach hässliche Leistungsanzeige keine Überarbeitung spendiert bekommen hat, TrueNAS kann das hübscher.
 
Paddy0293 schrieb:
Trau mich dennoch nicht upzugraden, da ich Angst habe das es mir etwas zerschießt, aber bis Ende Juni muss ich wohl upgraden :(
ich sag's mal so: mein NAS habe ich ursprünglich auf OMV 3 aufgebaut, seitdem wurde es kontinuierlich weiterentwickelt (bei der Hardware ist nur noch wenig vom Original übrig) sowie von Release zu Release per Upgrade hochgezogen.
Ja, ich hatte auch Probleme dabei. Beim letzten Upgrade gab es zwei Fehler, einen im Kernsystem und einer bzgl. der omv-extras. Beide haben zu keinem Zeitpunkt eine Gefahr für meine Daten bedeutet, und beide konnte ich mit Forumshilfe lösen.
 
  • Gefällt mir
Reaktionen: Paddy0293
@kane70 dann werde ich mich mal am WE dran wagen :)
 
  • Gefällt mir
Reaktionen: kane70
sylvio2000 schrieb:
@ -=XoDuS=-
Vielen Dank schon mal.
Wie viele Festplatten hängen an dem rpi? Und wie hast du sie angebunden und mit Strom versorgt?
Ich hab aktuell nur eine angehängt. Mehr als zwei geht bei einem RPI ja nicht weil gar ja nur zwei USB 3.0 Ports hat. Kann ja mal Fotos einstellen.
 
Paddy0293 schrieb:
Backup habe ich, dennoch bringt mir ja das Backup nichts, da ich ja upgraden muss (zwecks Sicherheitspatches). Mit dem Upgrade würde ich das Backup wieder zerstören ^^

Aber du kannst ja zumindest mal schauen, ob das Upgrade sauber durchläuft. Wenn's dir das Ding zerschießt, hast du zumindest ein Rollback und weißt, dass du OMV leider sauber neu aufsetzen musst.

Bei mir lief es übrigens problemlos. Plugins wurden auch alle übernommen, selbst die KVM-Instanzen sind noch da.

Screenshot_20220511_131917.png


Das neue Webinterface ist schicker, aber gefühlt auch noch verschachtelter als vorher. Aber gut, da schau ich eh relativ selten rein.
 
Ich habe selber viele Jahre OMV verwendet, meiner Meinung nach ein klasse Projekt, speziell für die Verwendung mit älterer und/oder weniger leistungsfähiger Hardware. Der Debian-Unterbau ist toll, wenn man selber ein bisschen frickeln kann oder mag, und es ist weit weniger wählerisch was (Netzwerk)hardware angeht als FreeBSD (TrueNAS). OMV würde ich jedem Einsteiger sofort empfehlen, es ist meiner Meinung nach auch mit der alten Oberfläche bereits deutlich einsteigerfreundlicher gewesen als TrueNAS.

Nachdem ich aber nun seit einiger Zeit ZFS einsetze, möchte ich dennoch nicht mehr zurück. Raid 5/6 ist halt einfach keine Alternative und Mirroring ist was den nutzbaren Festplattenplatz angeht nun einmal nicht gerade sehr effizient.
 
Bevor ich nen Thread aufmache, dachte ich, ich frag erstmal hier :)
Wo ich hier die Kommentare mit Ext4 und ZFS gelesen habe, kam gleich wieder das Thema Datenintegrität bei mir hoch ^^

Aktuell benutze ich immer noch ext4, weil es mir damals auch hier empfohlen wurde(Forumsbeitrag müsste ich raussuchen), da BTRFS nur seine Vorteile mit ECC Ram ausspielen kann und ohne ECC sogar gegenüber EXT4 schlechter ist.

Dabei ist mein NAS in allen Formen meine Quelle -> also zuerst kommen neue Dokumente auf die NAS und vom NAS auf die Backups

Mein Ablauf was neuen Daten betrifft ist folgender
  • Dokument einscannen -> wird direkt auf NAS abgelegt
  • Backups auf alle HDDs + halbjährlich Backup auf die HDD im Schliessfach
  • Backup auf Cloud
  • Datenintegrität via Personalbackup aller Daten überprüfen

Mit diesem Verfahren müsste ich doch sicher vor einem Bitflip sein bzw. müsste dieser doch dann durch Personal Backup rausgefunden werden oder liege ich da falsch ?

Das einzige was passieren könnte wäre das mein Scanner ein Bitflip erzeugt wären der Übertragung.
Vielleicht könnt ihr ja ein wenig Licht ins Dunkle bringen :)
 
Paddy0293 schrieb:
Aktuell benutze ich immer noch ext4, weil es mir damals auch hier empfohlen wurde(Forumsbeitrag müsste ich raussuchen), da BTRFS nur seine Vorteile mit ECC Ram ausspielen kann und ohne ECC sogar gegenüber EXT4 schlechter ist.
BTRFS finde ich etwas schwierig, ich hatte 2x ein RAID5 mit BTRFS, und beide sind mir nach einer gewissen Zeit "gestorben", bzw. waren mehrfach am Stück kaputt, und da möchte ich meine Daten nicht drauf haben, zumal ich auf meinem NAS mit 11x8TB Platten kein Backup fahre. Dafür sind mir die Daten zu "unwichtig", allerdings auch wieder nicht so unwichtig, dass ich nochmal BTRFS verwende. Vielleicht ist es aber mittlerweile stabiler, meine Erfahrung damit ist schon 2+ Jahre alt.
Ext4 ist aber so alt und abgehangen, da hab ich keine Angst, dass mir das Dateisystem abhanden kommt.

Paddy0293 schrieb:
Mit diesem Verfahren müsste ich doch sicher vor einem Bitflip sein bzw. müsste dieser doch dann durch Personal Backup rausgefunden werden oder liege ich da falsch ?
Bits können dir auch auf der Platte mal "umfallen", ohne dass du etwas änderst. Insofern: Nein zur ersten Frage.
Wenn du mit deinem Backup immer die Checksummen prüfst und ggf. die Dateien ersetzt/reparierst, ja. Aber ich habe meine Zweifel, dass die Software die du einsetzt, das tut. Also vermutlich eher nein.

Paddy0293 schrieb:
Das einzige was passieren könnte wäre das mein Scanner ein Bitflip erzeugt wären der Übertragung.
Vielleicht könnt ihr ja ein wenig Licht ins Dunkle bringen :)
Könnte auch, ist aber eher unwahrscheinlich, da die Protokolle i.d.R. auch mit Checksummen arbeiten.

Das flippen von einzelnen Bits erkennt man am besten über Checksums / Prüfsummen, also zB CRC32 o.ä. BTRFS und ZFS bieten beide Checksummen auf Dateisystemebene an, und das scrubben prüft dann die Checksummen und versucht ggf. die Datei zu reparieren. Ext4 nicht, und auch andere NAS Lösungen implementieren es dann nur ggf. "oben drauf". Ist bei Snapraid zB auch so - das setzt ja auf Ext4 (Oder besser gesagt auf irgendeinem Dateisystem, ist Snapraid eigentlich egal was du da nutzt) auf, wo die Dateien auch normal liegen, und generiert darauf aufbauend die Parität und Checksummen. Also komplett unabhängig vom Dateisystem.
Das würde ich dir da auch raten, falls du nicht sicher bist, ob dein NAS das von sich aus tut. So wie sich das liest, tut es das nicht.
Aber dazu müsste man auch wissen: Was für ein NAS nutzt du? Selbstbau/Server mit TrueNAS, OMV oder so? Oder ein "fertiges NAS" von QNAP oder Synology?
Je nachdem bietet die Software das Feature ja auch selbst an. Müsste man nur wissen, was du einsetzt :)
 
  • Gefällt mir
Reaktionen: DFFVB
Paddy0293 schrieb:
da BTRFS nur seine Vorteile mit ECC Ram ausspielen kann und ohne ECC sogar gegenüber EXT4 schlechter ist.
Das musst du mir erklären. ECC RAM ist klar immer besser, aber doch keine Pflicht. Alleine durch die Checksums ist für mich BTRFS ext4 weit überlegen und sorgt dafür, dass das, was gespeichert wird, auch so wieder gelesen wird - oder alternativ ein Fehler erzeugt wird. Alternativ gäbe es für Datenintegrität auf Filesystemebene oder tiefer auch noch dm-integrity oder halt ZFS.
Paddy0293 schrieb:
Mit diesem Verfahren müsste ich doch sicher vor einem Bitflip sein bzw. müsste dieser doch dann durch Personal Backup rausgefunden werden oder liege ich da falsch ?
Personal Backup hat recht viele Optionen und ist sehr flexibel. Wo genau kommt es bei dir zum Einsatz? Mit welchen Einstellungen?

@Snowi: Raid 5 und 6 war unter btrfs nie stabil und hat einen schwerwiegenden Bug, der auch in der Doku genannt wird. Durch deine Erfahrungen mit dem Raid 5 würde ich nicht aufs komplette restliche Dateisystem schließen. Ich habe btrfs bspw. auf diversen PCs und Servern täglich im Einsatz - ohne Probleme, aber auch ohne btrfs Raid 5 und 6. :)
 
  • Gefällt mir
Reaktionen: mdPlusPlus
WilliTheSmith schrieb:
@Snowi: Raid 5 und 6 war unter btrfs nie stabil und hat einen schwerwiegenden Bug, der auch in der Doku genannt wird. Durch deine Erfahrungen mit dem Raid 5 würde ich nicht aufs komplette restliche Dateisystem schließen. Ich habe btrfs bspw. auf diversen PCs und Servern täglich im Einsatz - ohne Probleme, aber auch ohne btrfs Raid 5 und 6. :)
Ok, das war mir so auch nicht bekannt - hatte es damals irgendwo gelesen incl Anleitung zum einrichten, da war dazu kein Wort. Aber schwierig, dass viele Leute es so bewerben, das Feature auch angeboten wird bzw. implementiert ist, obwohl man weiß, dass es kaputt ist. Dann sollte man es mMn. als "stable" Version die geshipped wird gar nicht erst anbieten.
 
Zurück
Oben