lionbackup im Container: /data sichern mit Docker Compose

Schritt 1: Projekt und Write-Token anlegen

Legen Sie im Portal ein Projekt für diesen Server an und erzeugen Sie darin ein Write-Token. Ein Write-Token kann ausschließlich sichern; es kann weder lesen noch wiederherstellen. Selbst wenn jemand den Container kompromittiert und das Token abgreift, bleiben Ihre Backups für ihn unlesbar.

Notieren Sie sich zwei Werte aus dem Portal: die Projekt-UUID und das Token. Das Token wird nur ein einziges Mal angezeigt.

Schritt 2: Verzeichnisse auf dem Host anlegen

Der Container braucht drei Dinge von außen: die Konfiguration, den öffentlichen Schlüssel und einen Arbeitsbereich. Wir legen dafür ein Stammverzeichnis an. Die zu sichernden Daten unter /data bleiben, wo sie sind.

sudo mkdir -p /opt/lionbackup/conf /opt/lionbackup/keys
cd /opt/lionbackup

Das Image läuft als nicht privilegierter Benutzer mit der festen UID 65532. Damit der Container gleich das Schlüsselpaar hineinschreiben kann, gehört ihm das Schlüsselverzeichnis:

sudo chown 65532:65532 /opt/lionbackup/keys

Schritt 3: Schlüsselpaar erzeugen

Die Verschlüsselung passiert vollständig auf Ihrem Server, bevor irgendetwas das Haus verlässt. Dafür brauchen Sie ein Schlüsselpaar. Der Container bringt den Generator mit:

docker run --rm \
  -v /opt/lionbackup/keys:/keys \
  git.lionbackup.cloud/lionbackup/lionbackup-client:0.1.3 \
  --generate-key --key-name /keys/backup

Danach liegen zwei Dateien in /opt/lionbackup/keys: backup.pub ist der öffentliche Schlüssel und kommt gleich in die Konfiguration. backup.key ist der private Schlüssel. Verwendet wird er ausschließlich bei einer Wiederherstellung.

Verwendet wird ein Post-Quanten-Hybridverfahren aus ML-KEM-768 und X25519. Aufgezeichnete Chiffrate bleiben damit auch dann unlesbar, wenn in einigen Jahren ein hinreichend großer Quantenrechner existiert.

Schritt 4: Konfiguration anlegen

Die Konfiguration ist eine einzelne YAML-Datei. Alle Pfade darin sind Pfade im Container, nicht auf dem Host.

sudo tee /opt/lionbackup/conf/lionbackup.yaml >/dev/null <<'EOF'
lionbackup:
  project: <Projekt-UUID aus dem Portal>
  storagezone: de01-1
  token: <Write-Token aus dem Portal>

  # Was gesichert wird. Der Host-Pfad /data ist unten in die
  # docker-compose.yml als /data eingehaengt.
  files:
    - /data

  compression_method: ZSTD     # ZSTD (empfohlen), GZIP oder LZMA2
  compression_level: 5

  # Nur der OEFFENTLICHE Schluessel. Der private gehoert nicht auf diesen Server.
  encryption_keyfile: /keys/backup.pub

  # Arbeitsbereich: das Docker-Volume aus Schritt 5.
  tmp_directory: /tmp

  chunksize: 64
  log_level: INFO
EOF

Die Datei enthält ein gültiges Token und sollte entsprechend geschützt sein:

sudo chmod 600 /opt/lionbackup/conf/lionbackup.yaml

Bewusst nicht gesetzt ist log_directory. Ohne diesen Eintrag schreibt der Client seine Ausgabe nach stdout, wo der Docker-Logging-Treiber sie einsammelt. Das ist der Weg, den man in einer Container-Umgebung will: docker compose logs statt einer Logdatei in einem Volume.

Schritt 5: docker-compose.yml schreiben

Das Backup ist ein Auftrag mit Anfang und Ende, kein Dienst. Entsprechend beschreibt die Compose-Datei einen Container, der einmal läuft und sich beendet.

sudo tee /opt/lionbackup/docker-compose.yml >/dev/null <<'EOF'
services:
  backup:
    image: git.lionbackup.cloud/lionbackup/lionbackup-client:0.1.3
    command: ["--config", "/conf/lionbackup.yaml"]
    restart: "no"
    # Das Image ist ein scratch-Image ohne Shell und ohne Paketmanager;
    # geschrieben wird ausschliesslich in den Arbeitsbereich unten.
    read_only: true
    volumes:
      # Quelldaten und Konfiguration schreibgeschuetzt,
      # Arbeitsbereich als benanntes Volume.
      - /data:/data:ro
      - ./conf:/conf:ro
      - ./keys:/keys:ro
      - lionbackup-tmp:/tmp

volumes:
  lionbackup-tmp:
EOF

Zwei Details lohnen einen zweiten Blick. /data wird schreibgeschützt eingehängt: Ein Backup-Programm hat keinen Grund, die Daten zu verändern, die es sichert. Und der Arbeitsbereich liegt auf einem benannten Volume statt in einem Host-Verzeichnis. Docker übernimmt dabei die Rechte des Verzeichnisses aus dem Image, sodass der nicht privilegierte Benutzer ohne weiteres Zutun schreiben darf.

Schritt 6: Erstes Backup starten

Weil der Container ein einmaliger Auftrag ist, wird er mit run gestartet, nicht mit up. Das --rm räumt ihn danach weg.

cd /opt/lionbackup && sudo docker compose run --rm backup

Der Client meldet seinen Fortschritt in drei Phasen: Quellen prüfen, dann je Quelle archivieren, komprimieren und verschlüsseln, dann hochladen. Bei größeren Datenmengen erscheint alle zwei Sekunden eine Fortschrittszeile mit Durchsatz und geschätzter Restzeit.

Läuft der Auftrag durch, taucht das Backup im Portal unter „Letzte Backups“ auf. Bricht er ab, sagt die letzte Zeile warum. Der häufigste Fall bei der Ersteinrichtung ist ein zu kleiner Arbeitsbereich; dann meldet der Client das Verzeichnis aus tmp_directory namentlich.

Schritt 7: Täglich automatisieren

Für die Wiederholung nimmt man unter Linux einen systemd-Timer. Er kennt im Gegensatz zu cron nachgeholte Läufe, falls die Maschine zum geplanten Zeitpunkt aus war.

sudo tee /etc/systemd/system/lionbackup.service >/dev/null <<'EOF'
[Unit]
Description=lionbackup - Sicherung von /data
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
WorkingDirectory=/opt/lionbackup
ExecStart=/usr/bin/docker compose run --rm backup
EOF

sudo tee /etc/systemd/system/lionbackup.timer >/dev/null <<'EOF'
[Unit]
Description=lionbackup taeglich um 01:00

[Timer]
OnCalendar=*-*-* 01:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now lionbackup.timer
systemctl list-timers lionbackup.timer

Persistent=true holt einen verpassten Lauf nach dem nächsten Start nach. RandomizedDelaySec streut den Startzeitpunkt um bis zu 15 Minuten, damit nicht alle Ihre Server gleichzeitig loslegen.

Und der Weg zurück?

Für eine Wiederherstellung erzeugen Sie im Portal ein Read-Token, legen den privaten Schlüssel bereit und starten denselben Container mit --restore, --identity und --target. Die Schritte im Einzelnen stehen im Beitrag Restore mit lionbackup; die Aufrufe sind unter Linux identisch.