Skip to main content

rclone Backup: Local Server → NAS (WebDAV)

Das folgende Beispiel zeigt eine einfache Sicherung von einem lokalen Gerät (192.168.10.5) auf ein NAS unter 192.168.10.10 mittels eines WebDAV-Freigabepfads namens backup.

rclone Konfiguration

Führe aus:

rclone config

Neuen Remote-Speicher anlegen:

  • Name: nasbackup
  • Storage: webdav
  • URL: http://192.168.10.10/backup
  • Vendor: other
  • User: <nas-benutzername>
  • Pass: <nas-passwort>

Referenz-Konfigurationsblock (wird automatisch erstellt):

[nasbackup]
type = webdav
url = http://192.168.10.10/backup
vendor = other
user = <nas-benutzername>
pass = <verschlüsseltes-passwort>

Backup-Befehle

Für die NPM-Daten:

rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data --progress --transfers=4 --checkers=4

Für die Let’s Encrypt Zertifikate:

rclone sync /opt/nginx-proxy-manager/letsencrypt nasbackup:/npm-letsencrypt --progress

Erklärung der wichtigsten Parameter

sync
Sorgt dafür, dass das Ziel exakt wie die Quelle wird. Neue und geänderte Dateien werden kopiert, im Ziel nicht mehr existierende Dateien werden gelöscht. Das ist ein echter Spiegel, birgt aber das Risiko von Datenverlust, falls das Ziel falsch ist.

--progress
Zeigt während der Übertragung Live-Informationen an (aktuelle Datei, Geschwindigkeit, voraussichtliche Restzeit). Beeinflusst die Übertragung nicht.

--transfers=4
Legt fest, wie viele Dateien gleichzeitig hochgeladen werden. Höhere Werte beschleunigen die Übertragung bei schneller Netzwerkverbindung, können aber ein schwaches NAS überlasten. 4 ist ein guter Standardwert im lokalen Netz.

--checkers=4
Anzahl der parallelen Prüfungen, ob Dateien geändert wurden. Mehr Checker beschleunigen das Scannen großer Verzeichnisse deutlich.

--quiet
Unterdrückt fast alle Ausgaben. Sehr sinnvoll bei Cron-Jobs, damit die Logdateien nicht unnötig vollgeschrieben werden.

Einfacher Cron-Job (täglich um 03:00 Uhr)

0 3 * * * rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data --quiet

Erweiterte und sichere Backup-Strategien mit rclone

Um versehentlichen Datenverlust zu vermeiden (z. B. durch falsche Pfade, fehlerhafte Synchronisation oder versehentliches Löschen), lohnt es sich, einige Sicherheits- und Komfort-Optionen von rclone zu nutzen.

1. Wichtige Sicherheits-Flags

Diese Parameter solltest du besonders bei sync-Befehlen immer im Hinterkopf haben:

  • --dry-run oder -n
    Führt eine Simulation durch – zeigt genau, was passieren würde, ohne irgendeine Datei zu verändern.
    Sehr empfehlenswert vor dem ersten echten Lauf oder nach größeren Änderungen!

    rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data --dry-run --progress
    
  • --max-delete (z. B. --max-delete 10 oder --max-delete 5%)
    Begrenzt die maximale Anzahl (oder Prozentzahl) von Dateien, die auf einmal gelöscht werden dürfen.
    Schützt vor Katastrophen, wenn z. B. die Quelldaten plötzlich fehlen.

    rclone sync ... --max-delete 20 --max-delete 10%
    
  • --retries 5 und --retries-sleep 10s
    Wiederholt fehlerhafte Übertragungen automatisch (Standard ist 3). Sehr nützlich bei instabilen Netzwerken oder NAS.

  • --low-level-retries 10
    Noch tiefere Wiederholungen auf Protokollebene (gut bei WebDAV).

  • --backup-dir nasbackup:/npm-data-backup/$(date +%Y-%m-%d)
    (siehe nächster Abschnitt – sehr mächtig in Kombination)

Empfohlener „sicherer“ Sync-Befehl zum Testen / Alltag:

rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data \
  --progress \
  --transfers=4 \
  --checkers=8 \
  --retries 6 \
  --max-delete 50 \
  --dry-run    # ← erst ohne, dann mit löschen

2. Versionierte Backups (empfohlene Methode für mehr Sicherheit)

Es gibt zwei gängige Ansätze, um alte Versionen zu behalten:

Variante A – Mit --backup-dir (sehr elegant, rclone-intern)

Dateien, die auf dem Ziel gelöscht oder überschrieben werden würden, landen stattdessen in einem versionsspezifischen Ordner.

rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data \
  --backup-dir nasbackup:/npm-data-versions/$(date +%Y-%m-%d_%H-%M) \
  --suffix .bak-$(date +%Y%m%d-%H%M%S) \
  --progress \
  --max-delete 100

→ Alte Versionen landen z. B. in
nasbackup:/npm-data-versions/2026-02-04_03-00/

Variante B – copy statt sync + --backup-dir

Wenn du gar nichts löschen möchtest, sondern nur hinzufügen und alte Dateien umbenennen:

rclone copy /opt/nginx-proxy-manager/data nasbackup:/npm-data \
  --backup-dir nasbackup:/npm-data-old/$(date +%Y-%m) \
  --suffix "-$(date +%Y%m%d-%H%M%S)" \
  --progress

→ Das Ziel wird nie gelöscht, sondern nur ergänzt. Alte Dateien werden automatisch umbenannt und in den Backup-Ordner verschoben.

Tipp: Monatliche Ordner (%Y-%m) oder wöchentliche (%Y-%W) helfen, den Speicherbedarf langfristig zu kontrollieren.

3. Cron-Beispiele mit mehr Sicherheit

Täglicher Sync mit Sicherheitsnetz (empfohlen):

0 3 * * * rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data \
  --backup-dir nasbackup:/npm-data-versions/$(date +\%Y-\%m-\%d) \
  --max-delete 40 \
  --retries 5 \
  --quiet --log-file /var/log/rclone-npm.log

Wöchentlicher vollständiger Check + Versionierung (sonntags):

0 4 * * 0 rclone sync /opt/nginx-proxy-manager/data nasbackup:/npm-data \
  --backup-dir nasbackup:/npm-data-weekly/$(date +\%Y-\%W) \
  --max-delete 200 \
  --progress >> /var/log/rclone-weekly.log 2>&1

Kurze Entscheidungshilfe

Ziel Empfohlener Befehl Löscht im Ziel? Behält alte Versionen?
Exakter Spiegel, wenig Speicher sync Ja Nein
Spiegel + Versionssicherung sync --backup-dir Ja Ja (verschoben)
Nur hinzufügen, nie löschen copy --backup-dir Nein Ja (umbenannt)
Erster Test / Überprüfung sync --dry-run Nein

Falls du möchtest, kann ich dir auch noch zeigen, wie man:

  • eine verschlüsselte Schicht (crypt) darüber legt
  • nach dem Backup eine Healthcheck-URL aufruft (z. B. healthchecks.io)
  • alte Versionen automatisch nach 30/60 Tagen löscht

… sag einfach Bescheid! 😄