Automatische Backups unter Linux in die Cloud mit rclone

Veröffentlicht am Kategorisiert in Backups, Linux Keine Kommentare zu Automatische Backups unter Linux in die Cloud mit rclone

Wie man regelmäßige Backups mit borg auf einen externen Datenträger einrichtet, zeigt der jüngste Artikel Automatische Backups unter Linux mit borg und borgmatic. Man sollte aber stets auch Sicherungen auf weiteren Geräten und am besten auch an anderen Standorten ablegen. Cloud-Speicher erfüllt gleich beide Bedingungen.

Zwar kann borg nicht nativ WebDAV oder andere übliche Protokolle sprechen, aber man könnte entfernte Dateisysteme zunächst mit Zusatzsoftware wie zum Beispiel davfs2 einhängen und borg so gleich in den Cloud-Speicher schreiben lassen. Deutlich praktischer finde ich allerdings ein Programm, das speziell für das Kopieren in die Cloud entwickelt wurde: rclone.

Mit rclone lassen sich Dateien verschlüsselt kopieren, synchronisieren und auch wieder entfernen. Die Synchronisation ist bewusst unidirektional: Die entfernten Daten lassen sich also auf den gleichen Stand wie die lokalen Daten bringen, doch umgekehrt werden niemals lokale Daten gelöscht oder geändert, wenn die entfernten Daten sich ändern.

Speicheranbindung an rclone

Zunächst muss rclone zum Beispiel über die Paketverwaltung installiert werden. Danach macht man rclone mit dem Remote-Speicher bekannt. Ein einfacher Assistent führt durch die Einrichtung:

rclone config

Man wird mit folgenden Optionen begrüßt:

No remotes found - make a new one
n) New remote
s) Set configuration password
q) Quit config

Um einen neuen Speicher anzubinden, tippt man also n und bestätigt mit Enter. Man wird nach einem beliebigen Namen gefragt, unter dem der Speicher von rclone angesprochen werden soll, zum Beispiel next für NextCloud:

name> next

Nun muss man anhand einer Nummer den Anbieter oder das Protokoll auswählen, in diesem Fall WebDAV:

34 / Webdav
   \ "webdav"
Storage> 34

Ich nehme hier exemplarisch die manuelle Konfiguration vor und werde anschließend nach der Adresse des Speichers gefragt (die Adresse muss natürlich individuell angepasst werden:

url> https://nextcloudserver/remote.php/webdav/

Danach wird man nach dem Benutzernamen und dem Kennwort gefragt. Wichtig zu wissen: Die Anmeldeinformationen werden in leicht unkenntlicher Form lokal in der rclone-Konfigurationsdatei ~/.config/rclone/rclone.conf gespeichert, auf welche ausschließlich der Besitzer Lese- und Schreibrechte hat. Wem das noch zu unsicher ist, sollte ein Konfigurationskennwort setzen, mit dem der Inhalt der Datei verschlüsselt wird. Das Kennwort muss dann natürlich gut aufbewahrt und bei jedem rclone-Aufruf eingegeben werden:

rclone config
e/n/d/r/c/s/q> s

Für eine vollkommene Automatisierung kann das ein Hindernis sein, weshalb ich diesen Schritt nur der Vollständigkeit halber beschreibe. Im Folgenden gehe ich davon aus, dass kein Konfigurationskennwort gesetzt ist.

Mit einem initialen Copy-Befehl kann man sich davon überzeugen, dass rclone auf den Speicher zugreifen kann. Dabei wird der eingangs gewählte Name für den Speicher als Identifikator genutzt. In diesem Beispiel kopiere ich das bereits verschlüsselte borg-Repository /mnt/backups in den Ordner Backups in der Cloud:

rclone copy /mnt/backups next:Backups

In der Cloud sollten sich nun die Dateien wiederfinden. Um nicht nur zu kopieren, sondern Richtung Cloud zu synchronisieren, tauscht man einfach den Befehl clone gegen sync aus:

rclone sync /mnt/backups next:Backups

Geplante Aufgaben mit systemd

Genau wie im Artikel über borg möchte ich diesen Befehl nicht selber ausführen müssen, sondern die Synchronisation täglich zum Beispiel um 21 Uhr beginnen. Dazu greife ich erneut auf systemd zurück und erstelle nach dem gleichen Muster einen Timer und einen Service. Diesmal gehe ich aber davon aus, in Zukunft noch weitere Cloud-Speicher an denselben Timer binden zu wollen, weshalb ich den eigentlichen rclone-Befehl in einen zweiten Service verschiebe, der von dem ersten Service abhängt. So ist das System flexibel und anschlussfähig für weitere zukünftige rclone-Ziele.

Die erste Datei für den Timer ~/.config/systemd/user/rclone-daily.timer sieht wie folgt aus:

[Unit]
Description=Run daily rclone syncs

[Timer]
OnCalendar=*-*-* 21:00
Persistent=true

[Install]
WantedBy=default.target

Der dazugehörige Service ~/.config/systemd/user/rclone-daily.service hat folgenden Inhalt:

[Unit]
Description=rclone sync
Wants=network-online.target
After=network-online.target
ConditionACPower=true

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

Im Abschnitt [Unit] mache ich den Start des Service von einer aktiven Netzwerkverbindung und von einem angeschlossenen Netzteil abhängig. Unter [Service] nutze ich /bin/true als Dummy-Programm, das ausgeführt wird, weil ich eine ExecStart-Zeile benötige. Die Magie steckt in RemainAfterExit=yes, weil der Service so noch aktiv und für die davon abhängigen Services verfügbar bleibt.

Die dritte Unit-Datei ~/.config/systemd/user/rclone-backups-to-nextcloud.service führt schließlich die rclone-Synchronisierung aus:

[Unit]
Description=rclone sync backups to cloud
PartOf=rclone-daily.service
After=rclone-daily.service
ConditionPathIsMountPoint=/mnt/backups

[Service]
Restart=no
ExecStart=rclone sync /mnt/backups next:Backups

[Install]
WantedBy=rclone-daily.service

Nicht nur klinkt sich der Service mit WantedBy als Abhängigkeit bei rclone-daily.service ein, er macht sich mit PartOf auch zum Teil dieses Services und wird automatisch gestoppt oder neugestartet, wenn rclone-daily.service gestoppt bzw. neugestartet wird. Und natürlich soll der Service nur laufen, wenn der als Quelle definerte externe Datenträger /mnt/backups eingehängt ist.

Genau wie dieser letzte Service könnten auch weitere rclone-Jobs angelegt werden, die dann ebenfalls vom Timer mitgestartet würden.

Schließlich müssen die Units natürlich noch aktiviert werden, damit sie bei der nächsten Anmeldung gestartet werden:

systemctl --user enable rclone-daily.timer rclone-daily.service rclone-backups-to-nextcloud.service

Ich hoffe, hier waren wieder ein paar nützliche Informationen zur Automatisierung von Backups dabei!

Von Pascal Korz

IT Systems Engineer in und aus dem schönen Köln

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert