Vor etwa zehn Jahren habe ich mit der Synology DS-1515+ mein erstes NAS angeschafft. Die Idee, lokal (und souverän!) jede Menge Daten irgendwo speichern zu können und nur sehr selten ausmisten zu müssen, ist sehr verlockend. Auch 2026 noch. Allerdings gibt es einige Learnings, die ich gerne früher gewusst hätte.

1 - Hardware ist wichtig, OS ist entscheidend

Jahrelang habe ich mit dem vermeintlichen Klassenbesten DSM von Synology gearbeitet. Auch, als ich mein zweites NAS (ein Terramaster F6-424) angeschafft habe, war der erste Schritt, mittels ARC Loader DSM auf die Hardware zu bringen. Die Software ist extrem user-friendly, man kann sogar Docker-Container laufen lassen, alles mit einer einfachen Web-UI. Das Betriebssystem sorgt für ein unglaublich stabiles System und erlaubt dank SHR auch, Festplatten unterschiedlicher Größe gemeinsam zu einem Speicherpool zusammenzufassen. Das ist für die meisten Home-Labber sicher notwendig, wer hat schon das Geld fünf oder gar sechs Platten mit derselben Größe auf einmal zu kaufen, schon gar nicht Ende 2026, wo 12 TB schon über 500 Euro kosten.

Das OS verteilt sich über alle Platten und ist damit auch maximal ausfallsicher, mit einer wesentlichen Auswirkung: Idle-Mode für Festplatten, also einzelne Drives in den Schlaf zu versetzen, ist praktisch unmöglich. Da das OS bei Aktivitäten immer auf allen Drives aktiv ist, kommt es niemals zu einem HDD-Spindown. Mir ist im Home Lab aber überaus wichtig, dass trotz Balkonkraftwerk der Stromverbrauch minimiert wird. Gerade fünf Festplatten, die 24/7 laufen brauchen im Jahr doch eine ansehnliche Menge - die erzeugte Wärme muss auch gekühlt werden!

OS im Überblick

In der Konsequenz habe ich mir verschiedene Alternativen angesehen. DSM ist easy, verlässlich, top. Bis auf den Stromverbrauch. Als richtiger Geek wollte ich doch gerne auf TrueNAS gehen, aber hier braucht es dank ZFS viel RAM und Platten schlafen auch eher nie. Ich brauche also eher etwas heimtauglicheres. TOS von Terramaster ist ebenfalls nicht in der Lage, die Platten einzeln schlafen zu schicken. Bleiben nur noch zwei Lösungen: unRAID oder OpenMediaVault. unRAID ist vermutlich die absolut beste Wahl. Ease-of-Use, Features, gut maintained, riesige User-Basis. Einziger Haken: Es kostet jedes Jahr, wenn man up-to-date bleiben möchte. Prinzipiell wäre das kein Problem, aber mit sechs Platten und einer SSD bin ich im teuersten Plan, die Features brauche ich quasi nicht, technisch bin ich versiert genug, also ein Blick auf OMV. Das ist Debian-basiert und tatsächlich eher nur für Power User. Man darf einiges per Hand machen, die Weboberfläche ist optisch noch in den 90ern und praktisch, aber nicht stylisch. Mein NAS soll aber eh in der Ecke stehen und laufen, daher brauche ich nicht mehr. Verschiedene HDD-Größen werden zu einem Pool zusammengefasst, mit mergerfs und SnapRAID baue ich genau, was ich brauche selbst. Und ein wenig Unterstützung von Mistral schadet nicht ;)

2 - Klare Aufgabenteilung

Es ist zwar irgendwie toll, wenn das NAS auch Docker-Host ist und noch diverse Nebenaufgaben übernimmt, aber inzwischen bin ich Fan einer klaren Aufgabenteilung.

Klare Aufgabenteilung im Home Lab

Compute und Storage trenne ich inzwischen eindeutig auf. Ein Intel NUC sorgt dafür, dass Anwendungen via Docker laufen, ein nginx-Proxy den Zugriff steuert und die Daten auf das NAS via NFS Mount geschrieben werden. Das NAS stellt nur Daten bereit, hier findet keine große Unterscheidung von Berechtigungskonzepten oder ähnlichen statt. Ein lokales (altes) NAS fährt einmal die Woche hoch und sichert alles vom NAS mittels rsnapshot via ssh und schaltet sich wieder ab. Es ist nur ein normales Backup, RAID-0 reicht aus, hier geht es nur darum, für den Fall der Fälle gewappnet zu sein. Und weil es eben noch da war, auch für etwas sinnvolles genutzt zu werden. Die Backup-Regel lautet aber 3-2-1 und es braucht einen anderen Standort für alles, was wirklich wichtig ist. Dazu gibt es eine Storage Box von Hetzner, die inzwischen via BorgBackup (früher auch rsnapshot) einmal täglich die wichtigsten Daten verschlüsselt ins Off-Site sichert.

3 - Ohne ein Restore bleibt es Schrödingers Backup

Die schönste Backup-Strategie funktioniert nicht, wenn man nicht gelegentlich mal testet, ob ein Restore auch funktioniert. Ich habe mir ein Backup/Restore für meine lokalen Docker-Container geschrieben, Restic ist toll, aber Datenbank-Backups brauchen beispielsweise einen Stop der Datenbank bzw. des Containers, um konsistent gesichert zu werden. Ohne einen Test, der die Daten zurückspielt, weiß man jedoch nie, ob das Backup auch wirklich funktioniert, speziell bei Datenbanken. Gerade wenn man das OS eines ganzen NAS ändert und die Art, wie die Platten miteinander ver-poolt werden zeigt sich dann beim Restore, ob alles einwandfrei läuft.

Wenn man die Kiste öffnet, weiß man, ob die Katze lebt. Exakt so verhält es sich mit Backups und Restores. Auch mit schnellen Platten bleibt das Bottleneck aber oft das Netzwerk, manchmal auch das Protokoll. Erst wollte ich meine Terabytes mittels NFS Mount einfach vom Backup-NAS an das aktualisierte Terramaster schicken, aber dank Overhead wäre es deutlich langsamer gewesen als meine Alternative. LACP im Home Lab wäre natürlich toll, aber ist im Detail tricky und nutzt im schlimmsten Fall dann auch nur einen NIC. Bei der 1515+ ist die maximale Geschwindigkeit hier eben 1GB. Statt also mittels NFS zu kopieren und Overhead abzuziehen, habe ich drei parallele rsync+ssh Sessions laufen - die laufen dann nämlich auch in drei Threads.

Traffic auf dem NAS beim Restore

Die Grafik zeigt es ganz gut. Bei (1) habe ich erstmal nur mit einem simplen rsync gearbeitet. (2) ist ein paralleles BorgBackup, das nach außen geht und etwas Konversation mit dem lokalen NUC. Hat keinen Einfluss auf das, was im Restore reinkommt. Parallel hatte ich einen zweiten rsync-Prozess angestoßen und der lief eine Weile bis (3), dann war es nur noch einer. Während der parallelen Threads wurde der NIC fast komplett ausgenutzt. Am Morgen (4) habe ich dann drei Sessions parallel zum Restore gestartet, damit ist das 1G komplett saturiert oder gesättigt. So werden aus mehreren Tagen Restores etwas weniger Tage ;)