Als Betreiberin kleiner Digitalprojekte und Beraterin für Selbstständige habe ich oft gesehen, dass Backups als lästige Aufgabe behandelt werden — bis etwas schiefgeht. In diesem Artikel teile ich meine praktische Lösung: wie ich rsync, restic und Cloud-Speicher kombiniere, um automatisierte, sichere und wiederherstellbare Backups für kleine Businesses aufzusetzen. Ich erkläre, warum ich diese Tools bevorzuge, wie ich sie konfiguriere und welche Fallstricke du vermeiden solltest.

Warum Kombination aus rsync + restic + Cloud?

Jedes Tool hat seine Stärken. rsync ist einfach, schnell und ideal für die Replikation von Dateibäumen (z. B. Webroot, gemeinsame Dateifreigaben). restic ist ein modernes, deduplizierendes Backup-Tool mit Verschlüsselung, Snapshots und effizienten Uploads in S3-kompatible Clouds. Die Cloud sorgt für Offsite-Speicherung.

Meine Kombination läuft so: rsync erstellt schnelle lokale Spiegelungen (inkl. Snapshots für schnelle Wiederherstellung), restic übernimmt versionierte, verschlüsselte Sicherungen dieser Spiegel auf einen Cloud-Storage wie Backblaze B2, Wasabi oder ein S3-kompatibler Anbieter. Das Ergebnis: lokale Performance + sichere, versionierte Offsite-Backups.

Worauf ich beim Backup-Design achte

  • Automatisierung: Backups laufen automatisch per systemd-timer oder cron.
  • Verschlüsselung: restic verschlüsselt automatisch; Cloud-Anbieter sehen keine Klartextdaten.
  • Versionierung & Aufbewahrung: Aufbewahrungsrichtlinien (z. B. 7 Tage täglich, 4 Wochen wöchentlich, 12 Monate monatlich).
  • Testbarkeit: Regelmäßige Restore-Tests sind Pflicht — ein Backup ist erst dann zuverlässig, wenn es sich wiederherstellen lässt.
  • Kostenkontrolle: Deduplizierung durch restic und Auswahl kostengünstiger S3-Backends minimieren Storage-Kosten.

    • Grundarchitektur meiner Backups

    So setze ich das in der Praxis um:

  • Quellserver: Produktionsdaten (Web, Datenbanken, Dateifreigaben).
  • Lokaler Backup-Server / NAS: rsync spiegelt täglich wichtige Pfade in einen strukturierten Ordner /backups/sources/project.
  • Backup-Agent: Auf dem Backup-Server läuft restic, das die /backups/sources in ein remote Repository (S3/B2) sichert.
  • Monitoring: Logs per syslog, einfache E-Mail-Benachrichtigung bei Fehlern, und gelegentliche Restore-Checks.

    • Beispiel: rsync für lokale Spiegel

    Ich nutze rsync für inkrementelle Spiegel und behalte die Originalrechte. Ein typischer Befehl:

    rsync -aAXv --delete --exclude='node_modules' --exclude='tmp' /var/www/my-site/ /backups/sources/my-site/

    Optionen, die ich häufig nutze:

  • -a (archive: rekursiv, Besitzer, Rechte erhalten)
  • -A und -X (ACLs und Extended Attributes, wichtig bei Linux-Dateisystemen)
  • --delete um gelöschte Dateien auf dem Backup-Spiegel zu entfernen (nützlich, aber mit Vorsicht einsetzen)

    • Option: rsync mit Snapshots (hardlink-basierend)

    Für sehr schnelle lokale Restore-Punkte verwende ich rsync + hardlink trick (ähnlich zu rsync+cp --link-dest). Ein einfaches Skript erzeugt tägliche Snapshots ohne doppelte Dateikopie.

    Prinzip: Du hast /backups/sources/my-site/current und /backups/snapshots/day-YYYYMMDD; cp --link-dest verlinkt unveränderte Dateien, rsync aktualisiert die geänderten.

    restic konfigurieren und Backup in die Cloud

    restic ist mein bevorzugtes Tool für verschlüsselte, versionierte Offsite-Backups. Setup-Beispiel für Backblaze B2:

    1) Repository initialisieren:

    export B2_ACCOUNT_ID=yourAccountId
    export B2_ACCOUNT_KEY=yourAccountKey
    restic -r b2:my-bucket:/crest-backups init

    2) Backup ausführen (Beispiel für das lokale Spiegel-Verzeichnis):

    restic -r b2:my-bucket:/crest-backups backup /backups/sources/my-site --tag my-site --files-from /etc/restic/excludes.txt

    3) Aufbewahrungsregel (Prune/Forget):

    restic -r b2:my-bucket:/crest-backups forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12

    Scheduling: systemd-timer vs cron

    Für moderne Linux-Server empfehle ich systemd-timer (bessere Logging, leichteres Debugging). Ein einfaches systemd-Service+Timer-Paar startet das Backup-Skript täglich.

  • service: /etc/systemd/system/crest-backup.service
  • timer: /etc/systemd/system/crest-backup.timer (z. B. OnCalendar=daily)

    • cron ist in Ordnung, z. B. täglich um 02:00:

    0 2 * * * /usr/local/bin/crest-backup.sh >> /var/log/crest-backup.log 2>&1

    Monitoring & Alerts

    Fehler müssen auffallen. Ich leite die Ausgabe an ein zentrales Log und nutze simple E-Mail-Benachrichtigung bei Nicht-Null-Exit-Code. Für größere Setups lohnt sich ein Monitoring-Tool (Prometheus + Alertmanager oder ein SaaS wie UptimeRobot/StatusCake für grundlegende Checks).

    Wiederherstellung — so teste ich Restores

    Regelmäßige Tests sind nicht verhandelbar. Ein einfacher Restore-Test mit restic:

    restic -r b2:my-bucket:/crest-backups restore latest --target /tmp/restore-test --include my-site/path/to/critical/file

    Ich führe monatlich einen vollständigen Restore in eine isolierte Umgebung durch, um Datenintegrität, Dateirechte und Applikationskompatibilität zu prüfen.

    Sicherheitsaspekte

  • Schütze Zugangsdaten: B2/ S3-Credentials niemals im Klartext in öffentlich lesbaren Skripten speichern — benutze Umgebungsvariablen oder HashiCorp Vault/KMS.
  • Verschlüsselung: restic verschlüsselt automatisch; das Repository ist safe, solange das Password sicher ist.
  • Least Privilege: Erstelle Cloud-Zugangsdaten nur mit den nötigen Rechten (write/read für den spezifischen Bucket).

    • Vergleich: rsync vs restic (Kurzüberblick)

    Funktionrsyncrestic
    Best fürSchnelle lokale ReplikationVerschlüsselte, versionierte Offsite-Backups
    DeduplizierungNeinJa
    VerschlüsselungNeinJa (AES)
    Restore GranularitätDatei/OrdnerSnapshot-basiert, Datei/Ordner
    Cloud IntegrationDirekt möglich, aber ineffizientNative S3/B2/etc. Unterstützung

    Praxis-Tipps aus meinen Projekten

  • Starte klein: Backup eines kritischen Ordners und ein Test-Restore — dann ausweiten.
  • Automatisiere Prüfroutinen: Nach jedem Backup ein kurzer SHA-Check wichtiger Dateien.
  • Dokumentation: Schreibe ein kurzes Runbook für Emergency-Restores (wer macht was, wie lange dauert es, wo liegen Passwörter).
  • Kosten beachten: Prüfe Bandbreitenlimits und Cloud-Egress-Kosten; testweise Backups vorab durchführen.

    • Wenn du möchtest, kann ich dir ein kleines Starter-Skript für rsync + restic zusammenstellen, angepasst an deine Infrastruktur (Linux-Server, NAS oder Docker-Umgebung). Sag mir kurz, welche Datenmengen und welchen Cloud-Provider du planst — dann mache ich dir ein konkretes Beispiel, das du direkt einsetzen kannst.