Raspberry Pi mit Docker: Home Lab einrichten, sichern und wiederherstellen

Kurz erklärt: Beginnen Sie mit einem unterstützten Raspberry Pi OS in 64 Bit, funktionierendem SSH und einem kleinen Compose-Dienst. Binden Sie den Webport an localhost, greifen Sie per SSH-Tunnel zu und prüfen Sie ein Backup, bevor wichtige Daten hinzukommen. Ein laufender Container ist der Anfang, kein Wiederherstellungsnachweis.

Das Beispiel bleibt bewusst überschaubar: nginx liefert eine statische Seite aus. So werden Host, Container, Netzwerk und Daten verständlich, ohne zunächst Datenbank, Passwortmanager oder öffentliches Verwaltungsportal zu betreiben. Die Befehle sind vorgeschlagene Einrichtungsschritte, kein Beleg eines AYXWORKS-Hardwaretests dieser exakten Konfiguration.

1. Einen sauberen Host mit klarem Umfang vorbereiten

Benötigt werden eine zur Last passende Raspberry Pi, modellgerechtes Netzteil und Kühlung, zuverlässiger Speicher und Netzwerkzugang. Eine Pi 4 oder Pi 5 mit unterstütztem 64-Bit-System ist ein vernünftiger Einstieg für dieses kleine Beispiel, aber keine Kapazitätszusage für alle späteren Dienste. Beachten Sie die Boarddokumentation zu Speicher und Boot-Kompatibilität.

Richten Sie mit Raspberry Pi Imager und den offiziellen Fernzugriffshinweisen Ihr Benutzerkonto und SSH ein. Hier heißen Beispielnutzer und Host labuser und lab; ersetzen Sie sie durch Ihre Werte. Prüfen Sie SSH im vertrauenswürdigen Heimnetz vor der App-Installation. Löst .local nicht auf, finden Sie die Geräteadresse im Router.

Schreiben Sie für diese Anleitung kein neues Image auf einen bestehenden Server. Das Imaging löscht den gewählten Datenträger. Verwenden Sie Ersatzmedien oder ausdrücklich gesicherte Daten und kontrollieren Sie das Ziel. Existieren Docker oder Dienste bereits, prüfen Sie die vorhandene Installation, statt sie mit diesen Befehlen zu ersetzen.

2. Betriebssystem und Architektur kontrollieren

Prüfen Sie auf der Pi:

cat /etc/os-release
dpkg --print-architecture
uname -m

Die folgende Einrichtung gilt für unterstütztes, Debian-basiertes Raspberry Pi OS in 64 Bit. dpkg muss arm64 melden; prüfen Sie außerdem den tatsächlichen Debian-Codenamen. Die herangezogene Docker-Anleitung führt unter anderem Bookworm und Trixie als unterstützt auf. Ein 64-Bit-Kernel allein beweist noch keinen 64-Bit-Userspace.

Bei 32 Bit, einer nicht unterstützten Version oder einer anderen Distribution stoppen Sie und verwenden deren offizielle Anleitung. Setzen Sie keinen beliebigen Codenamen ein, nur damit das Repository die Installation akzeptiert.

3. Docker aus dem unterstützten Paket-Repository installieren

Nutzen Sie auf dem sauberen, geeigneten Host das offizielle Docker-Verfahren für Debian. Lesen Sie Paketmanager-Rückfragen und stoppen Sie bei Fehlern. Der Block schreibt eine Repositorydatei; überschreiben Sie damit keine bestehende Sonderkonfiguration ohne Prüfung.

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run --rm hello-world
sudo docker compose version

Erwartet werden eine erfolgreiche hello-world-Ausgabe und eine Compose-Version, keine hier erfundene Versionsnummer. Die Anleitung verwendet weiterhin sudo zur Docker-Verwaltung. Wie Docker dokumentiert, gewährt die docker-Gruppe Root-äquivalente Rechte; sie ist nicht bloß eine harmlose Erleichterung.

4. Ein isoliertes Compose-Projekt erstellen

Der nächste Block verweigert das Überschreiben von ~/homelab/web, wenn es bereits existiert. Er erzeugt Beispielseite und Compose-Datei. Die Fehlerbehandlung in der Subshell stoppt bei vorhandenem Verzeichnis oder fehlgeschlagenem Befehl.

(
  set -eu
  test ! -e "$HOME/homelab/web"
  mkdir -p "$HOME/homelab/web/site"
  cd "$HOME/homelab/web"
  printf '%s\n' '<!doctype html><title>Home lab</title><h1>Home lab is running</h1>' > site/index.html
  cat > compose.yaml <<'YAML'
name: lab-web
services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./site:/usr/share/nginx/html:ro
    restart: unless-stopped
    logging:
      driver: local
YAML
)

Das Image liefert den Webserver; die Seite liegt im Hostverzeichnis site, das im Container nur lesbar eingebunden wird. Der Port lauscht ausschließlich auf der Loopback-Adresse der Pi. Das ist Absicht: Der Dienst ist weder im LAN noch im Internet veröffentlicht. Der lokale Logging-Treiber begrenzt Logs durch Rotation, statt unbegrenzte Standardprotokolle wachsen zu lassen.

Der Image-Tag ist ein bequemer Start, aber keine unveränderliche Version. Erfassen Sie nach dem Test den aufgelösten Digest und pinnen Sie ihn für reproduzierbaren Betrieb. Derselbe Tag kann Monate später andere Software liefern.

5. Starten und die tatsächliche Seite prüfen

Führen Sie im neuen Projekt die folgenden Befehle aus und untersuchen Sie Fehler vor dem Fortfahren:

cd "$HOME/homelab/web" || exit 1
sudo docker compose config --quiet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
curl --fail http://127.0.0.1:8080/

Die Konfigurationsprüfung sollte fehlerfrei sein, der Dienst laufen und curl das Beispiel-HTML ausgeben. „Running“ allein beweist keine funktionierende Anwendung. Scheitert curl, prüfen Sie Logs, Portbindung und Dateimount, bevor weitere Software hinzukommt.

6. Vom Laptop zugreifen, ohne den Port zu veröffentlichen

Öffnen Sie auf dem Laptop den Tunnel mit dem zuvor eingerichteten Benutzer und Host:

ssh -N -l labuser -L 127.0.0.1:8080:127.0.0.1:8080 lab.local

Lassen Sie das Terminal offen und besuchen Sie im Laptop-Browser http://127.0.0.1:8080/. SSH läuft absichtlich ohne Shell weiter. Beenden Sie es mit Strg+C. Ist Port 8080 auf dem Laptop belegt, ändern Sie den ersten lokalen Port im Weiterleitungsargument und verwenden diesen im Browser.

Richten Sie dafür keine Portweiterleitung am Router ein und geben Sie keinen Docker-Socket frei. Veröffentlichte Docker-Ports können mit Host-Firewallregeln interagieren; eine Firewall macht nicht automatisch jeden veröffentlichten Container privat. Zugriff von außerhalb benötigt ein gesondertes Zugangskonzept, kein offenes Adminportal.

7. Logs, Speicher und getestetes Image ansehen

cd "$HOME/homelab/web" || exit 1
sudo docker compose ps
sudo docker compose logs --tail=50 web
df -h
sudo docker image inspect nginx:stable-alpine --format '{{index .RepoDigests 0}}'

Compose-Logs helfen bei Anwendungsfehlern, die Datenträgerbelegung bei Hostkapazität. Der letzte Befehl zeigt die aufgelöste Imagereferenz. Bewahren Sie sie mit Compose auf, wenn Sie eine getestete Version festlegen. Prüfen Sie Logs vor dem Teilen auf private Informationen.

Starten Sie nicht sofort einen großen Stack, weil die erste Seite funktioniert. Ergänzen Sie jeweils einen Dienst und prüfen Sie CPU-Architektur, Speicherbedarf, persistente Daten, Zugangsdaten, Netzwerk und Wiederherstellung. Container machen inkompatible Software nicht automatisch ARM-fähig.

8. Ein Backup des Beispiels erstellen und kontrollieren

Für die statische Beispielseite enthält der Projektordner Daten und Konfiguration. Ohne gleichzeitige Dateiänderungen führen Sie aus:

(
  set -eu
  umask 077
  mkdir -p "$HOME/backups"
  backup="$HOME/backups/lab-web-$(date +%Y%m%d-%H%M%S).tar.gz"
  test ! -e "$backup"
  tar -C "$HOME/homelab" -czf "$backup" web
  gzip -t "$backup"
  sha256sum "$backup"
  restore=$(mktemp -d "$HOME/lab-restore.XXXXXX")
  tar -xzf "$backup" -C "$restore"
  cmp "$HOME/homelab/web/site/index.html" "$restore/web/site/index.html"
  cmp "$HOME/homelab/web/compose.yaml" "$restore/web/compose.yaml"
  printf 'Backup: %s\nRestored copy: %s\n' "$backup" "$restore"
)

Das Archiv wird geprüft, in ein neues temporäres Verzeichnis entpackt und mit den Quelldateien verglichen. Erfolgreiche cmp-Aufrufe bleiben still; ein Fehler stoppt den Block. Das ist ein Dateiwiederherstellungstest, keine vollständige Notfallprobe einer laufenden Anwendung. Behalten Sie das entpackte Verzeichnis bis zur Kontrolle.

Kopieren Sie das Archiv auf ein anderes Gerät oder geschütztes Backupziel. Eine Sicherung ausschließlich auf der Pi fällt mit deren Speicher aus. Datenbanken brauchen ein konsistentes, anwendungsgerechtes Backup oder einen Dump; das Kopieren eines laufenden Datenverzeichnisses reicht nicht automatisch. Auch Docker-Volumes verlangen einen Plan, wie die Volume-Dokumentation beschreibt.

9. Geplant aktualisieren und gezielt stoppen

Sichern Sie vor Updates Compose-Datei, getestete Imagereferenz und Daten. Lesen Sie Release Notes, laden Sie das vorgesehene Image, erstellen Sie den Dienst neu und prüfen Sie die Seite. Bei Schemaänderungen macht das alte Image allein eine Migration möglicherweise nicht rückgängig; befolgen Sie den Wiederherstellungsweg der Anwendung.

So stoppen Sie dieses Beispiel und entfernen seine Compose-Container und sein Netzwerk:

cd "$HOME/homelab/web" || exit 1
sudo docker compose down

Das vom Host eingebundene Verzeichnis site wird nicht gelöscht. Ergänzen Sie bei anderen Projekten nicht beiläufig -v und verwenden Sie Volume-Pruning nicht statt eines Verständnisses der Datenhaltung. Das Beispiel lässt sich mit der behaltenen Compose-Datei und up -d erneut erstellen.

Was erst nach den Grundlagen hinzukommt

Authentifizierung, TLS, externe Sicherungen, Überwachung und Updatepolitik sind wichtig, bevor unersetzliche Informationen einziehen. Richten Sie sie passend zur tatsächlichen Anwendung ein. Halten Sie Geheimnisse aus der Versionsverwaltung heraus und beschränken Sie Docker- und SSH-Administration.

Der erste Meilenstein ist bescheiden: erklären können, wo die Seite liegt, wie sie erreichbar ist, welches Image läuft, was eine Containerlöschung überlebt und wie das Backup geprüft wurde. Das ist wertvoller als ein Dashboard voller Dienste ohne erprobten Rückweg.

Quellen und Prüfgrenzen

Die verlinkten Raspberry-Pi- und Docker-Dokumentationen wurden am 14. Oktober 2026 geprüft. Hardwarekapazität, Imageverfügbarkeit und Installationskompatibilität müssen für den gewählten Host bestätigt werden. Der Artikel ersetzt unbelegte persönliche Aufbaugeschichten durch eine konkrete Anleitung; er behauptet weder eine ausgeführte AYXWORKS-Hardwareinstallation noch gemessene Zuverlässigkeitsgewinne.