Backups mit Rclone und Backblaze B2 – sicher, verschlüsselt, automatisiert

Wer selbst hostet, trägt die volle Verantwortung für seine Daten. Ein Backup-Konzept ist keine Kür, sondern Pflicht. Rclone in Verbindung mit Backblaze B2 ist dabei eine der besten Kombination für selbstverwaltete Server: kosteneffizient, zuverlässig und mit echter Ende-zu-Ende-Verschlüsselung. Dieser Artikel zeigt, wie man das konkret am Beispiel einer Kirby-CMS-Instanz umsetzt.

Was ist Rclone, was ist Backblaze B2?

Rclone ist ein Open-Source-Kommandozeilenwerkzeug zum Synchronisieren, Kopieren und Verschlüsseln von Daten zwischen lokalen Systemen und Cloud-Speichern. Es unterstützt über 70 Backends – darunter S3, Google Drive, SFTP und eben Backblaze B2.

Backblaze B2 ist ein S3-kompatibler Objektspeicher mit sehr günstigen Preisen (aktuell ca. 0,006 USD/GB/Monat). Download-Traffic ist bis zu einem bestimmten Limit kostenlos, was B2 besonders für Backup-Szenarien attraktiv macht.

Warum eine zusätzliche Verschlüsselungsschicht?

Backblaze verschlüsselt Daten serverseitig – der Anbieter hält jedoch die Schlüssel. Wer das nicht akzeptieren will (oder aus DSGVO-Gründen muss), braucht clientseitige Verschlüsselung. Rclone bringt genau das mit: das crypt-Backend legt einen verschlüsselten Layer über einen beliebigen Remote – transparent für den Nutzer, undurchdringlich für den Anbieter.

Voraussetzungen

Rclone installiert (apt install rclone oder über rclone.org)
Backblaze-Account mit einem Bucket und einem Application Key
Eine laufende Kirby-Instanz mit typischer Verzeichnisstruktur

Schritt 1: Backblaze B2 als Remote einrichten

rclone config

Auswahl: n (New remote) → Name: b2 → Provider: Backblaze B2

Benötigt werden:

Account ID (= Key ID aus dem Backblaze-Dashboard)
Application Key (nicht der Master-Key, sondern ein eingeschränkter Key für den Bucket)

Empfehlung: Application Key mit Rechten nur auf einen Bucket und nur für readFiles, writeFiles, deleteFiles anlegen – keine Bucket-Verwaltungsrechte.

Nach der Konfiguration testen:

rclone lsd b2:

Der Bucket sollte in der Ausgabe erscheinen.

Schritt 2: Verschlüsseltes Crypt-Remote einrichten

rclone config

Auswahl: n → Name: b2-crypt → Provider: Crypt

Einstellungen:

Remote: b2:dein-bucket-name/backups (Unterordner empfohlen)
Filename encryption: standard (verschlüsselt auch Dateinamen)
Directory name encryption: true
Password: sicheres Passwort wählen und offline sichern – geht es verloren, sind die Backups unwiederbringlich
Password 2 (Salt): zweites Passwort für den HMAC-Salt – ebenfalls sichern

Das Crypt-Remote legt alle Daten vor dem Upload verschlüsselt ab. Backblaze sieht nur unleserlichen Binärblob.

Testen:

rclone lsd b2-crypt:

Schritt 3: Kirby-Instanz sichern

Eine typische Kirby-Installation hat folgende relevante Verzeichnisse:

/var/www/kirby-site/
├── content/        ← Inhalte (Pflicht)
├── site/           ← Templates, Plugins, Konfiguration
├── media/          ← Cache, wird automatisch regeneriert (optional)
└── kirby/          ← Core, kann aus Git/Composer wiederhergestellt werden (optional)

Sinnvolles Backup: content/ und site/ sind unersetzlich. Der kirby/-Core und media/ sind verzichtbar, wenn das Deployment dokumentiert ist.

Backup-Befehl:

rclone sync /var/www/kirby-site/content b2-crypt:content \
  --backup-dir b2-crypt:versions/$(date +%Y-%m-%d) \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO \
  --transfers 4 \
  --checksum

Erklärung der Optionen:

Option	Bedeutung
`sync`	Ziel wird dem Quellstand angeglichen (Löschungen inklusive)
`--backup-dir`	Überschriebene/gelöschte Dateien landen versioniert im Archiv
`--checksum`	Vergleich per Hash statt Timestamp – zuverlässiger
`--transfers 4`	Parallele Uploads (je nach Bandbreite anpassen)

Für site/ analog:

rclone sync /var/www/kirby-site/site b2-crypt:site \
  --backup-dir b2-crypt:versions/$(date +%Y-%m-%d)-site \
  --log-file /var/log/rclone-backup.log \
  --log-level INFO \
  --checksum

Schritt 4: Automatisierung per Cron

crontab -e

Tägliches Backup um 02:30 Uhr:

30 2 * * * /usr/bin/rclone sync /var/www/kirby-site/content b2-crypt:content --backup-dir b2-crypt:versions/$(date +\%Y-\%m-\%d) --log-file /var/log/rclone-backup.log --log-level INFO --checksum
30 2 * * * /usr/bin/rclone sync /var/www/kirby-site/site b2-crypt:site --backup-dir b2-crypt:versions/$(date +\%Y-\%m-\%d)-site --log-file /var/log/rclone-backup.log --log-level INFO --checksum

Wichtig: % in Cron-Dateien muss als \% escaped werden.

Alternativ: Ein Wrapper-Skript unter /usr/local/bin/kirby-backup.sh anlegen und nur dieses per Cron aufrufen – übersichtlicher und leichter zu testen.

Schritt 5: Versionierung und Retention

Backblaze B2 unterstützt nativ Lifecycle Rules (Aufbewahrungsfristen). Im Bucket-Dashboard lassen sich ältere Versionen automatisch nach N Tagen löschen. Empfehlung:

backups/ (aktueller Stand): unbegrenzt oder 90 Tage
versions/ (Archiv): 30 Tage

Alternativ lassen sich alte --backup-dir-Verzeichnisse per Rclone selbst aufräumen:

rclone purge b2-crypt:versions/$(date -d '30 days ago' +%Y-%m-%d)

Wichtige Hinweise

Passwörter niemals im Skript im Klartext. Die Rclone-Konfigurationsdatei (~/.config/rclone/rclone.conf) speichert Passwörter verschleiert (nicht verschlüsselt). Zugriff auf die Datei absichern:

chmod 600 ~/.config/rclone/rclone.conf

Für erhöhte Sicherheit: Konfiguration mit rclone config → s (Set configuration password) zusätzlich mit Passwort schützen. Dann muss Rclone bei jedem Lauf das Konfigurationspasswort kennen – für Cron-Jobs via Umgebungsvariable RCLONE_CONFIG_PASS.

Wiederherstellung testen. Ein Backup, das nie getestet wurde, ist kein Backup. Mindestens einmal probeweise wiederherstellen:

rclone copy b2-crypt:content /tmp/kirby-restore-test

Datenbank. Kirby ist flat-file und braucht keine Datenbank – das ist ein echtes Vorteil hier. Wer andere CMS mit Datenbank sichert, muss den Dump separat einplanen (z.B. mysqldump vor dem Rclone-Lauf).

Logs überwachen. /var/log/rclone-backup.log sollte in eine Log-Rotation eingebunden sein (logrotate) und idealerweise auf Fehler überwacht werden – per einfachem grep im Cron-Job oder einem Monitoring-Tool.

Fazit

Rclone mit Backblaze B2 und aktiviertem Crypt-Remote ist eine praxiserprobte, kostengünstige Backup-Lösung für selbstverwaltete Webprojekte. Die clientseitige Verschlüsselung stellt sicher, dass der Anbieter keine Einsicht in die Daten hat. Für Kirby ist das Setup besonders unkompliziert, weil das CMS keine Datenbank mitbringt – content/ und site/ genügen für eine vollständige Wiederherstellung.

Der kritische Punkt bleibt immer derselbe: Die Crypt-Passwörter müssen sicher und getrennt vom Server gespeichert werden. Ohne sie sind die Backups unlesbar – was Sicherheit ist, wenn der Server kompromittiert wird, aber zum Problem wird, wenn die Passwörter verloren gehen.