Abbildung 1: Rclone hakt sich bei allen wichtigen Anbietern von Cloud-Festplatten unter.

Ein gutes Backup ist für Sysadmin-Kolumnist Charly Kühnast zwar selbstverständlich. Aber auch das könnte eines Tages Raubgut der Flammen oder eines Diebes werden. Da er genügend kostenlosen Platz auf Google Drive frei hat, muss er nicht lange nach einer Lösungsstrategie suchen. Fehlt nur das passende Tool.

Ich wollte nie in den Klagegesang über verlorene Daten einstimmen müssen und habe darum funktionierende Backups zu Hause. Für die Verkettung doofer Umstände, auch absoluter Katastrophenfall genannt, erscheint mir ein Offshore-Backup gleichwohl eine passende Sache zu sein. Als Android-Nutzer gibt mir Google 15 GByte seines Speicherplatzes ab, die ich derzeit nicht nutze. Aber noch fehlt das passende Tool: Rclone.

Unter [1] liegen fertige Binärpakete für Linux, Windows, Mac OS, die BSDs, Plan 9 und Solaris. Wer lieber selbst baut und einen Go-Compiler im System hat, bringt Rclone mit dem Kommando

go get -u -v github.com/ncw/rclone

an den Start. Die Konfiguration des Speicher-Backends starte ich mit »rclone config« und nehme mit »n« den Weg für »New remote«. Beim nun abgefragten Namen für die Remote-Verbindung nehme ich »mygdrive«. Abbildung 1 macht klar, dass bei den unterstützten Speicherdiensten für jeden etwas dabei sein müsste – sogar generisches FTP/SFTP, um auf einem gemieteten Server oder auf einem Webspace eine eigene Backup-Ecke einzurichten.

Nachdem ich mich für Google Drive und die automatische Konfiguration entschieden habe, öffnet sich ein Browser, damit ich Rclone bei Google erlaube auf meine Datei-Ablage zuzugreifen. Damit ist die Konfiguration durch.

Um nachzusehen, was ich auf der Remote-Seite gespeichert habe, genügt das Kommando:

rclone ls mygdrive:

Der Doppelpunkt ist Pflicht. Da mein Drive leer ist, kommt keine Ausgabe. Zum Ausprobieren kopiere ich meine Apache-Configfiles ins Drive:

rclone copy -L -v /etc/apache2/ mygdrive:backup

Das dauert einen Moment, denn Google praktiziert ein relativ aggressives Rate Limiting (auf ungefähr zwei Dateien pro Sekunde). In Googles Webinterface kontrolliere ich gleich, ob die Dateien angekommen sind (Abbildung 2).

Abbildung 1: Rclone hakt sich bei allen wichtigen Anbietern von Cloud-Festplatten unter.

Abbildung 2: Googles Webfrontend zeigt, dass die per Rclone übertragenen Beispieldateien gut angekommen sind.

Mit Geschichte

Google hat Drive eine kleine Versionsverwaltung spendiert. Lade ich geänderte Apache-Dateien erneut hoch, erkennt das Drive dies und behält beide Dateien – maximal 30 Tage oder 100 Änderungen, je nachdem, was zuerst eintritt. Ab nun verwende ich als Kommando »sync« statt »copy«:

rclone sync -L -v /etc/apache2/ mygdrive:backup

Jetzt gleicht Rclone die lokale und entfernte Seite ab und kopiert nur die geänderten Dateien. Files, die ich lokal lösche, ereilt im Drive das gleiche Schicksal – umgekehrt aber nicht. Wie Rsync beidseitig zu synchronisieren, das schafft Rclone nicht. Dafür kann ich Dateien verschlüsselt ablegen, indem ich nach »rclone config« noch »Encrypt/Decrypt« wähle.

Da Rclone noch in aktiver Entwicklung ist, schaue ich ihm bei der Arbeit lieber genau zu.