Snoopy – Unser TS-253D

Liebe Maike, diese Seite ist für dich: Für all die Tage mit Tee, Telefon am Ohr und zwei geöffneten NAS-Oberflächen: eines in meinem Wohnzimmer, eines irgendwo am anderen Ende der Leitung. Für die Momente, in denen wir gemeinsam ausprobiert, gesucht, geflucht, verstanden und am Ende meistens auch eine Lösung gefunden haben.

Unsere NAS sind längst mehr als nur viel Speicherplatz. Es ist unser kleines Stück digitale Selbstbestimmung — eine eigene Wolke, ein Spielplatz für Ideen, ein Ort zum Lernen und Ausprobieren. Und hier gibt es nun unsere kleine Gedankenstütze: was haben wir eingerichtet und für gut befunden? Wo sind die Fallstricke, an die wir uns immer wieder erinnern müssen? Und vielleicht gibt es da draußen noch andere wie uns, die einen Kaffee oder Tee haben und sich denken „Lass uns mal schauen, ob das geht.“ Und denen das ganze hier vielleicht sogar hilft.

Einer der hinterhältigsten Fallstricke beim QNAP ist das manuelle Anlegen eines cron-Jobs: funktioniert wie bei jedem Unixoid und läuft. Aber irgendwann stellt man dann fest, dass der regelmäßige backup-Job nicht mehr läuft. In der crontab findet sich keine Spur von ihm.

Der Hintergrund ist, dass QNAP die aktive Crontab aus eigenen Konfigurationsdateien generiert. Änderungen über crontab -e sind daher nicht persistent und gehen spätestens beim nächsten Neustart verloren. Es gibt Kontroll- und Persistenzgründe, die das erklären – aber wenn man das rausgefunden hat, ist man schon mindestens einmal in die Falle getappt.

Will man die crontab ändern, muss man die zugrunde liegende Kofiguration in /etc/config/crontab ändern. Dann überleben die eigenen Jobs auch den Neustart.

Der TS-253D ist nicht unser erster NAS. Davor gab es BRAIN (TS‑231P) und davor einen namenlosen TS-210 Turbo. Mittlerweile haben wir seit über 15 Jahren ein QNAP im Haus.

Anfangs ging es vor allem um Datensicherheit – ein RAID‑System, yeah. Dann die ersten Schritte mit eigener Software: ownCloud, direkt auf dem NAS installiert. Was für ein Gefrickel.

Mit BRAIN kam dann die große Neuerung: die Container Station – und damit die Möglichkeit, Dienste in Docker‑Containern laufen zu lassen. Aber als wir richtig losgelegt haben, kam der TS‑231P schnell an seine Grenzen: 1 GB RAM und ein ARM‑Prozessor sind nicht gerade die beste Grundlage für Docker. Die Auswahl der Images war begrenzt, die Performance noch mehr.

Seit 2022 bereichert nun SNOOPY unser Heimnetzwerk: Intel-Prozessor, 8TB-RAID und mittlerweile 16GB RAM und eine kleine SSD für Logs. Und damit ging das Dockern richtig los.

Warum wie heute uns ein Leben ohne Docker nicht mehr vorstellen können:

1. Einfache Software‑Updates
Ein Update des Docker-Containers ist schnell gemacht. Was früher Stunden dauerte, geht heute in Minuten – wenn überhaupt. Und die Gefahr, ein System durch ein Update zu beschädigen, ist gering: Zur Sicherheit vorher einfach den aktuellen Container komplett sichern. (Brauchten wir bisher nie.)

2. Dienste laufen autark
Jeder Container arbeitet für sich. Keine Port‑Konflikte, keine Abhängigkeiten, kein „dieser Dienst hat den anderen kaputt gemacht“. Ein Container ist ein kleines Labor: sauber, isoliert, reproduzierbar.

Vertrauenswürdige SSL‑Zertifikate für die QNAP wären schön – aber myQNAPcloud kommt für uns nicht in Frage. Und alle 90 Tage daran denken, ein Let’s‑Encrypt‑Zertifikat zu erneuern? Das funktioniert schon beim ersten Mal nicht zuverlässig. Ganz davon ab, dass die Erneuerung über Port 80 läuft – was wir aus Sicherheitsgründen nicht offen haben wollen.

Die Lösung: AdGuard Home + Caddy als Docker‑Duo.

AdGuard Home übernimmt den internen DNS:
Eigene Subdomains für jeden Dienst, saubere Namensauflösung, keine Fritzbox‑Sonderlogik.

Caddy ist der Reverse Proxy:
Er generiert und erneuert Zertifikate automatisch, routet sauber zu den Diensten und nutzt dafür Port 80. Der Unterschied zu QNAP: Caddy ist genau für diesen Zweck gebaut und bietet dabei minimalste Angriffsfläche. Port 80 wird ausschließlich für die Let’s‑Encrypt‑Challenge verwendet, sonst für nichts. Jede Anwendung bekommt ihre eigene Domain, und Caddy kümmert sich um den Rest.

Damit haben wir stabile Zertifikate, ohne myQNAPcloud, ohne manuelle Erneuerung, ohne QNAP‑Eigenheiten.

https://hub.docker.com/_/caddy

https://hub.docker.com/r/adguard/adguardhome

Mittlerweile laufen mehrere Datenbanken auf unserem QNAP für unterschiedliche Dienste. Und wer kennt das nicht: mal eben noch schnell was ändern, und am nächsten Tag geht irgendwas nicht mehr. Dann ist es schön, wenn man vorgesorgt hat und ein regelmäßiges Backup hat, das einfach läuft.

Damit wir uns keinen Kopp machen müssen, wenn eine neue Anwendung dazukommt, nutzen wir überall mariaDB. Das Backup‑Skript prüft alle laufenden Container, erkennt automatisch, ob es sich um eine mariaDB‑Instanz handelt, und erzeugt ein Backup mit Rotation nach dem Grandfather‑Father‑Son‑Prinzip (GFS).

Einmal eingerichtet, läuft das komplett ohne unser Zutun — und rettet uns, falls mal wieder ein Schicht-8-Problem auftritt.

https://github.com/kindermaenner/qnap-snippets/tree/main/backup_mariadb

Jellyfin und Audiobookshelf sind das Herzstück unseres kleinen Heim‑Entertainments. Über diese beiden Docker‑Container läuft alles, was sich bewegt oder Töne von sich gibt: Musik, Videos und Hörbücher.

Für den Pöcks können wir bequem ein Kinderprofil anlegen und steuern, was er sehen darf.
Das funktioniert erstaunlich gut – und vor allem ohne Cloud‑Zwang, ohne Tracking, ohne „wir wissen besser, was dein Kind sehen sollte“.

https://hub.docker.com/r/advplyr/audiobookshelf

https://hub.docker.com/r/jellyfin/jellyfin