Warum Ihr NAS mit Docker laut ist – und wie Sie das Problem beheben

Ein Network Attached Storage (NAS) ist die stille Arbeitsbiene im Home-Netzwerk: Er speichert Daten, streamt Medien und sichert Backups – alles ohne Lärm. Doch wehe, wenn Docker ins Spiel kommt. Plötzlich surren die Festplatten ununterbrochen, klicken in der Nacht und stören den Schlaf. Was steckt dahinter – und wie bringt man das NAS wieder zur Ruhe?

Warum Docker mechanische Festplatten in die Knie zwingt

Mechanische Festplatten (HDDs) sind leise, solange sie sequenziell arbeiten – also große Dateien ohne Unterbrechung lesen oder schreiben. Doch Docker liebt das Gegenteil: Zufällige, verstreute Lese- und Schreiboperationen auf tausende kleine Dateien. Jedes Mal, wenn ein Container eine Datei aus einer unteren Schicht ändert, wird der Copy-on-Write-Mechanismus von Docker aktiviert. Dabei wird die Datei zunächst in eine höhere Schicht kopiert, bevor die Änderung geschrieben wird. Auf einer SSD ist das kein Problem, doch auf einer HDD bedeutet jeder Kopiervorgang:

• Suchvorgänge der Schreib-/Leseköpfe
• Lesezugriffe auf verstreute Datenblöcke
• Schreiboperationen an neuen Positionen

Das Ergebnis? Ein ununterbrochener Strom an zufälligen I/O-Operationen, der die Festplatten permanent beschäftigt und laute Geräusche verursacht.

Der Hauptübeltäter: Docker’s Overlay2-Speichertreiber

Docker nutzt standardmäßig den Speichertreiber overlay2, der auf einem Schichtsystem basiert. Jeder Container erhält eine dünne, beschreibbare Ebene über den unveränderlichen Imageschichten. Doch diese Architektur hat einen entscheidenden Nachteil für HDDs:

• Metadaten in tiefen Verzeichnisbäumen: Docker speichert Konfigurationsdateien und Statusinformationen in einem komplexen Verzeichnisbaum. Selbst einfache Container-Operationen wie Startup, Logrotation oder Health Checks erzeugen ständige Schreibzugriffe auf diese kleinen Dateien.
• Kaskadierende I/O-Muster: Jeder Container – ob Media-Server, Datenbank oder Automatisierungstool – generiert eigene zufällige I/O-Operationen. Multipliziert mit der Anzahl der Container summiert sich das zu einer nie endenden Lärmkulisse.
• Systemprozesse als Verstärker: Neben Docker laufen typischerweise Systemüberwachungstools (z. B. Cron-Jobs alle 5–10 Minuten), das systemd-Journal, das regelmäßige Logs schreibt, und das NAS-Betriebssystem selbst mit seinen Hintergrundaufgaben. Allein wären diese Prozesse unauffällig – doch auf den durch Docker bereits belasteten Festplatten potenzieren sie das Problem.

Diagnose: Welcher Prozess macht die Festplatten zum Trommelwirbel?

Bevor Sie Änderungen vornehmen, sollten Sie identifizieren, welcher Prozess die Festplatten tatsächlich belastet. Zwei Tools helfen dabei, die I/O-Aktivität in Echtzeit zu überwachen:

# Zeigt laufende I/O-Operationen pro Prozess an (benötigt sysstat)
sudo iotop -o

# Misst die Festplattenauslastung über einen Zeitraum
# (z. B. 10 Messungen im Abstand von 2 Sekunden)
iostat -x 2 10

In den meisten Docker-Setups wird der Docker-Daemon als Hauptverursacher auftauchen, gefolgt von periodischen Spitzen durch Cron-Jobs oder Systemprozesse. Die Diagnose bestätigt oft, was Betroffene ohnehin ahnen: Die Festplatten sind ständig aktiv.

Die Lösung: Docker auf eine SSD auslagern

Der Kern des Problems ist simpel: HDDs sind für zufällige I/O-Operationen nicht ausgelegt, während SSDs damit ausgezeichnet umgehen können. Die Lösung besteht also darin, Docker und alle damit verbundenen Daten auf ein externes Speichermedium zu verlagern, das keine Geräusche verursacht – eine USB-angeschlossene SSD.

Warum eine SSD die perfekte Lösung ist

• Lautlosigkeit: SSDs haben keine beweglichen Teile und erzeugen daher keinen Lärm.
• Geringe Zugriffszeiten: Selbst über USB 3.0 erreicht eine SATA-SSD Geschwindigkeiten von über 400 MB/s – mehr als ausreichend für Docker-Container.
• Energieeffizienz: SSDs verbrauchen weniger Strom als HDDs und schonen so die Lebensdauer der Festplatten.

Schritt-für-Schritt-Anleitung zur Migration

#### 1. Docker-Datenverzeichnis auf die SSD verschieben

Der wichtigste Schritt ist die Verlagerung des Docker-Datenverzeichnisses (data-root), das die Overlay2-Schichten, Image-Caches und Container-Daten enthält. Bearbeiten Sie die Docker-Konfiguration unter /etc/docker/daemon.json:

{
  "data-root": "/mnt/external-ssd/@docker"
}

Speichern Sie die Datei und starten Sie Docker neu:

sudo systemctl restart docker

#### 2. Bind-Mounts auf die SSD verschieben

Viele Container nutzen Bind-Mounts, um auf Daten auf der HDD zuzugreifen – etwa Datenbanken, Konfigurationsdateien oder Medienbibliotheken. Diese sollten ebenfalls auf die SSD wandern, um zufällige I/O-Operationen zu vermeiden.

Eine elegante Lösung ist die Verwendung von Symbolischen Links, die die Pfade für Container transparent halten. Angenommen, Ihre Container greifen unter /volume1/docker/volumes auf Daten zu:

# Erstellen eines Ordners auf der SSD für die Container-Daten
sudo mkdir -p /mnt/external-ssd/volumes

# Verschieben der ursprünglichen Daten (optional, aber empfohlen)
sudo mv /volume1/docker/volumes /mnt/external-ssd/

# Symbolischen Link erstellen, der auf den neuen Speicherort zeigt
sudo ln -s /mnt/external-ssd/volumes /volume1/docker/volumes

Container müssen nun keine Änderungen vornehmen – sie greifen weiterhin auf dieselben Pfade zu, doch die tatsächlichen Daten liegen auf der SSD.

#### 3. SSD korrekt einbinden und optimieren

Damit die SSD nach einem Neustart automatisch verfügbar ist, tragen Sie sie in die fstab-Konfiguration ein:

UUID=<ihre-uuid> /mnt/external-ssd ext4 defaults,noatime,nofail 0 2

Zwei wichtige Optionen:

• `noatime`: Deaktiviert das Aktualisieren der Zugriffszeit bei jedem Lesevorgang. Das spart unnötige Schreiboperationen.
• `nofail`: Verhindert, dass das System beim Bootvorgang hängen bleibt, falls die SSD nicht verfügbar ist.

#### 4. UGOS Pro: Besonderheiten bei Dateikopien

Nutzen Sie ein UGREEN-NAS mit UGOS Pro (basierend auf Debian), gibt es eine bekannte Einschränkung: `rsync` kann Berechtigungen und erweiterte Attribute (xattr) beschädigen, wenn Dateien von der NAS-Festplatte auf ein externes Laufwerk kopiert werden. Der Grund liegt in proprietären Kernel-Erweiterungen von UGOS Pro.

Die Lösung ist einfach: Verwenden Sie stattdessen *`tar` mit der Option `--xattrs-exclude='ug.'`**:

tar --xattrs-exclude='ug.*' -cvf backup.tar /pfad/zur/quelle

Eine detaillierte Anleitung zu diesem Problem finden Sie in einem technischen Artikel auf DEV Community: "Warum rsync Berechtigungen auf UGOS Pro zerstört – und die einzige funktionierende Lösung".

Das Ergebnis: Ein NAS, das endlich leise bleibt

Nach der Migration ist der Unterschied frappierend. Vorher: ein konstantes Klicken und Surren, das selbst durch geschlossene Türen drang. Jetzt? Stille. Die HDDs arbeiten nur noch gelegentlich – etwa beim Schreiben von Systemprotokollen oder beim Ausführen von Cron-Jobs. Der Hintergrundlärm ist verschwunden, und das NAS erfüllt wieder seinen ursprünglichen Zweck: eine unsichtbare, zuverlässige Datenbank.

Docker läuft weiterhin auf dem NAS, aber die Festplatten atmen auf. Sie müssen sich keine Sorgen mehr über nächtliche Lärmbelästigung machen oder darüber, dass die Lebensdauer Ihrer HDDs durch ständige Aktivität leidet. Stattdessen genießen Sie eine saubere, effiziente und vor allem leise NAS-Erfahrung.

In Zukunft lohnt es sich, solche I/O-Muster im Auge zu behalten – besonders, wenn Sie planen, weitere Container oder Dienste auf Ihrem NAS zu betreiben. Denn nicht jedes Speichermedium ist für jeden Workload geeignet. Doch mit der richtigen Konfiguration kann Docker auch auf einem NAS harmonisch mit HDDs zusammenarbeiten – ohne dass die Festplatten zur Lärmquelle werden.