Cloudron-Backup auf eine Hetzner Storage Box

Anlass und Voraussetzungen

Vor ein paar Tagen habe ich an meinem Cloudron endlich einen Off-Site-Backup-Standort eingerichtet. Cloudron läuft bei mir als VM in der Hetzner Cloud, der Speicher ist eine Hetzner Storage Box im selben Hetzner-Backbone. Traffic intern, Latenz niedrig, der naheliegende Schritt.

Wenn du dasselbe vorhast, brauchst du:

• ein aktuelles Cloudron auf einem Host, von dem aus Port 445 ausgehend offen ist
• eine Hetzner Storage Box (Plan beliebig, eine BX11 reicht für die meisten Homelabs)
• cifs-utils auf dem Cloudron-Host (bei Standard-Cloudron-Hosts vorinstalliert)
• Root-Shell-Zugang auf dem Cloudron-Host für Probe-Mount und Diagnose

Eine Stolperfalle vorweg. Die Hetzner Storage Box ist in Cloudrons Backup-Provider-Dropdown nicht als eigener Eintrag enthalten. Cloudron bietet Filesystem, S3 (und Kompatible), GCS, EFS, CIFS Mount, NFS Mount. Der Weg führt über CIFS Mount. SSHFS unterstützt Cloudron nicht direkt, und einen Hetzner-spezifischen Provider gibt es im UI nicht.

Outbound auf Port 445 ist bei Hetzner Cloud nicht gesperrt. Bei manchen anderen Anbietern (AWS standardmäßig, einige GCP-Setups) ist der Port aus Anti-Wurm-Gründen geblockt. Wer von dort aus auf eine Storage Box will, braucht entweder eine Tunnel-Lösung oder einen anderen Backup-Pfad.

Storage Box: Sub-Account mit Samba

In der Hetzner-Console unter console.hetzner.com deine Storage Box öffnen und in den Reiter „Sub-accounts” wechseln. Dort „Create sub-account”:

• Home-Verzeichnis: zum Beispiel /home/cloudron
• Passwort: eigenes, nicht das Hauptaccount-Passwort
• Samba support: Haken setzen. Ohne diesen Haken kann Cloudron später nicht mounten.
• SSH und WebDAV können aus bleiben, wenn du sie nicht brauchst

Den Username notieren. Er hat das Format u<id>-sub1 und ist im Folgenden gleichzeitig Hostname-Präfix, Share-Name und Login.

Erreichbarkeit und Probe-Mount

SSH auf den Cloudron-Host, dann zwei Sekunden Sanity-Check:

nc -zv u123456-sub1.your-storagebox.de 445
apt list --installed 2>/dev/null | grep cifs-utils

Die nc-Antwort muss „succeeded” sein. Wenn das fehlschlägt, blockiert etwas zwischen deinem Host und Hetzner den Port 445 ausgehend. Erst das klären, dann weiter im Cloudron-UI. cifs-utils muss installiert sein, falls nicht: apt install cifs-utils.

Anschließend ein manueller Mount, um Credentials und Share-Pfad zu verifizieren. Credentials in eine Datei statt direkt auf die Kommandozeile, damit das Passwort nicht in der Shell-History landet:

mkdir -p /mnt/sb-test
cat > /root/.smb-sb-test <<'EOF'
username=u123456-sub1
password=DEIN_SUB_PASSWORT
EOF
chmod 600 /root/.smb-sb-test

mount -t cifs 
  -o credentials=/root/.smb-sb-test,vers=3.1.1,uid=0,gid=0,file_mode=0600,dir_mode=0700 
  //u123456-sub1.your-storagebox.de/u123456-sub1 /mnt/sb-test

touch /mnt/sb-test/cloudron-touch && rm /mnt/sb-test/cloudron-touch
umount /mnt/sb-test
rm /root/.smb-sb-test

Beachte den Share-Pfad //<host>/<username>. Bei Hetzner Storage Box ist der Share-Name gleich dem Username. Kein Wunschpfad, kein sprechender Name wie backup. Der touch muss durchlaufen, das umount sauber zurückkommen. Wenn dabei „Permission denied”, „mount error(13)” oder „Bad authentication” auftaucht, ist es entweder das Passwort oder der fehlende Samba-Haken am Sub-Account.

Cloudron-Dashboard konfigurieren

Im Cloudron-Dashboard auf System → Backups → Datensicherungsstandort hinzufügen. Felder so:

Zwei Felder sind erklärungsbedürftig.

Remote-Verzeichnis. Cloudron baut daraus die Mount-Source //<Server>/<Remote-Verzeichnis>. Das Feld bezeichnet also den Share-Pfad, keinen Unterordner innerhalb eines Shares. Bei Hetzner Storage Box heißt der Share wie der Username, also /u123456-sub1. Wer hier ein selbst ausgedachtes Verzeichnis wie /Cloudron_Backup einträgt, bekommt einen Mount-Fehler. Den Share gibt es nicht.

Prefix. Der Unterordner für die Snapshots innerhalb des Shares. cloudron ist eine sinnvolle Vorbelegung. Cloudron legt diesen Ordner beim ersten Backup automatisch an.

Den Encryption-Key direkt auf dem Cloudron-Host erzeugen und parallel in einem Passwort-Manager ablegen:

openssl rand -base64 48

Den String einmal nach Bitwarden (oder vergleichbar), einmal in das Cloudron-Feld. Ohne diesen Key ist kein Restore möglich, auch nicht mit Cloudron-Support. Cloudron verschlüsselt clientseitig.

Hardlink-Hinweis: die Option „Verwende Hardlinks” funktioniert beim rsync-Format mit Hetzner Storage Box, weil Samba auf der Box Hardlinks unterstützt. Bei anderen CIFS-Servern (manche NAS-Implementierungen, ältere Samba-Versionen) ist das nicht immer der Fall. Wer dort landet, schaltet Hardlinks aus und akzeptiert größeren Speicherverbrauch.

Retention nach Geschmack, zum Beispiel 7 daily, 4 weekly, 6 monthly. Schedule auf eine bandbreiten-ruhige Uhrzeit, etwa 03:00. Speichern.

Wenn alles passt, meldet Cloudron den Mount als „active”. Wenn nicht: „Failed to mount (inactive): Could not determine mount failure reason.” Diese Meldung ist generisch und sagt nichts. Der echte Grund steht auf dem Host:

systemctl --all | grep -iE 'mnt|cifs'
journalctl -u '<gefundene-mount-unit>' -n 50 --no-pager
dmesg | grep -i cifs | tail -30

Häufigste Ursachen, wenn der Probe-Mount oben funktioniert hat: Tippfehler im Remote-Verzeichnis oder eine doppelt verwendete Mount-Quelle aus einem früheren Versuch.

Erstsicherung und Test-Restore

Im Cloudron-Dashboard Backup Now drücken. Bei mehreren Apps dauert die Erstsicherung ein paar Stunden. Auf dem Host parallel:

tail -f /home/yellowtent/platformdata/logs/box.log | grep -iE 'backup|snapshot'

Nach dem ersten Lauf eine Stichprobe direkt auf der Box. Manuell wie oben mounten und nachsehen:

mount -t cifs -o credentials=/root/.smb-sb-test,vers=3.1.1 
  //u123456-sub1.your-storagebox.de/u123456-sub1 /mnt/sb-test
ls -la /mnt/sb-test/cloudron/snapshot/
umount /mnt/sb-test

Pro App muss ein Snapshot-Verzeichnis zu sehen sein.

Letzter Schritt, ohne den ein Backup kein Backup ist: ein Test-Restore. Eine unkritische App wählen (eine zweite Heimdall-Instanz, ein leerer Wiki-Container, irgendetwas Entbehrliches), im Dashboard auf App → Backups → Snapshot → Restore. Wenn der Restore sauber durchläuft, weißt du, dass Encryption-Key, Mount-Konfiguration und Speicherformat zusammenpassen.