Rclone mit Google Drive auf einem Headless-Server einrichten

Rclone kann Dateien von einem Server ohne grafische Oberfläche auf Google Drive kopieren. Die Anmeldung erfolgt einmal über einen Rechner mit Browser. Danach arbeitet der Server mit der gespeicherten Konfiguration. Ein erfolgreicher Upload ersetzt allerdings keine Wiederherstellungsprobe.

Diese Anleitung richtet einen eigenen OAuth-Client ein und zeigt eine Dateisicherung, die bei Fehlern abbricht. Voraussetzungen sind ein Google-Konto mit genügend freiem Speicher, SSH-Zugang und Rclone auf Server und lokalem Rechner. Das Beispiel sichert ein Webverzeichnis, kein vollständiges Betriebssystem und keine laufende Datenbank.

Phase 1: Eigenen Google-Client vorbereiten

Die aktuelle Rclone-Dokumentation kündigt das Ende der gemeinsam genutzten Google-Drive-Client-ID im Jahr 2026 an. Eine eigene Client-ID vermeidet diese Abhängigkeit. Google-Quoten und Drosselung bleiben trotzdem möglich; ein eigenes Projekt hebt keine API-Limits auf.

1. In der Google Cloud Console ein Projekt anlegen oder auswählen und die Google Drive API aktivieren.
2. In der Google Auth Platform die Angaben unter Branding und Zielgruppe ausfüllen. Für ein gewöhnliches privates Google-Konto ist die Zielgruppe „Extern“ vorgesehen.
3. Den benötigten Drive-Zugriffsbereich konfigurieren. Das folgende Beispiel verwendet https://www.googleapis.com/auth/drive und erhält damit weitreichenden Dateizugriff. Engere Bereiche sind möglich, decken aber andere Anwendungsfälle ab.
4. Einen OAuth-Client vom Typ „Desktop-App“ anlegen. Client-ID und Client-Secret für die Rclone-Konfiguration bereithalten.
5. Bei einer externen Anwendung im Status „Testing“ verfallen Refresh-Tokens mit diesem Drive-Bereich nach sieben Tagen. Für dauerhaften Betrieb den passenden Produktionsstatus und die Verifizierungsanforderungen prüfen. „In Produktion“ verhindert diese spezielle Testfrist, garantiert aber kein dauerhaft gültiges Token.

Publikation und Google-Verifizierung sind unterschiedliche Schritte. Bei persönlicher Nutzung können Ausnahmen von der Verifizierung gelten. Warnhinweise, Nutzergrenzen und organisatorische Vorgaben bleiben gesondert zu beachten.

Phase 2: Autorisierung auf dem Server starten

Rclone auf beiden Rechnern installieren und mit rclone version die Versionen vergleichen; für die Autorisierung empfiehlt Rclone dieselbe Version. Unter Debian oder Ubuntu ist ein Paket über sudo apt install rclone verfügbar. Die Dialogtexte können zwischen Versionen abweichen.

1. Auf dem Server rclone config starten und ein neues Remote namens gdrive vom Typ drive anlegen.
2. Die eigene Client-ID, das Client-Secret und den vorgesehenen Zugriffsbereich eintragen. Für diesen Ablauf kein Servicekonto auswählen.
3. Die Frage nach der automatischen Anmeldung im Browser mit n beantworten. Rclone zeigt einen passenden rclone authorize-Befehl für den lokalen Rechner an und wartet auf config_token.

Phase 3: Im lokalen Browser anmelden

Den vom Server ausgegebenen Autorisierungsbefehl auf dem Rechner mit Browser ausführen. Nach der Google-Anmeldung und Freigabe liefert rclone authorize ein Ergebnis zum Kopieren. Dieses Ergebnis am wartenden Serverdialog einfügen und die Remote-Konfiguration bestätigen. Ein gewöhnlicher lokaler rclone config-Durchlauf ist nicht mit diesem Token-Ausgabeschritt gleichzusetzen.

Mit rclone lsd gdrive: lässt sich der Zugriff auf die Ordner prüfen. Ein leeres Drive kann eine leere Liste liefern; entscheidend sind auch Rückgabewert und Fehlermeldungen. rclone config file zeigt den Speicherort der Konfiguration. Die Datei enthält Zugangsdaten und muss für den späteren Backup-Benutzer lesbar und aktualisierbar sein, ohne anderen Konten Zugriff zu geben.

Phase 4: Dateien kopieren und den Lauf prüfen

Das folgende Skript benötigt Bash, GNU tar, flock und Rclone. Quellpfad, Backup-Verzeichnis und Remote sind vor dem ersten Lauf anzupassen. Das Zielverzeichnis liegt außerhalb des gesicherten Webverzeichnisses. Derselbe Benutzer muss Zugriff auf die Quelldateien und die Rclone-Konfiguration haben.

#!/bin/bash
set -euo pipefail
umask 077

SOURCE_DIR="/var/www/html"
BACKUP_DIR="$HOME/backups/www"
REMOTE="gdrive:ServerBackups"

mkdir -p -- "$BACKUP_DIR"
exec 9>"$BACKUP_DIR/.backup.lock"
flock -n 9 || { printf 'Backup already running\n' >&2; exit 1; }

NAME="www_$(date -u +%Y%m%dT%H%M%S%NZ).tar.gz"
ARCHIVE="$BACKUP_DIR/$NAME"
PART="$ARCHIVE.part"
trap 'rm -f -- "$PART"' EXIT

tar -czf "$PART" -C "$SOURCE_DIR" .
mv -- "$PART" "$ARCHIVE"
rclone copyto --immutable "$ARCHIVE" "$REMOTE/$NAME"
rclone check "$BACKUP_DIR" "$REMOTE" --include "/$NAME" --one-way

printf 'Archive uploaded and checked: %s\n' "$NAME"

Das Skript erzeugt zunächst eine temporäre Archivdatei. Erst nach erfolgreichem tar erhält das Archiv den endgültigen Namen. Upload oder Vergleich mit rclone check müssen ebenfalls erfolgreich sein, bevor die Erfolgsmeldung erscheint. Die Sperre verhindert zwei gleichzeitige Läufe mit demselben Backup-Verzeichnis. Der Vergleich prüft Dateieigenschaften beziehungsweise verfügbare Prüfsummen, nicht die Funktionsfähigkeit einer wiederhergestellten Website.

Eine laufende Website kann während des Archivierens Dateien verändern. Für einen konsistenten Stand ist deshalb ein geeigneter Snapshot oder ein abgestimmtes Sicherungsfenster nötig. Eine Datenbank benötigt einen eigenen konsistenten Export; tar /var/www/html sichert deren laufenden Inhalt nicht automatisch.

Nach einem manuellen Probelauf kann ein Cronjob das ausführbare Skript unter einem festen absoluten Pfad starten. Rückgabewerte und Protokolle gehören in eine Fehlerbenachrichtigung. Automatisches Löschen ist bewusst nicht enthalten: Lokale und entfernte Archive wachsen an, bis eine Aufbewahrungsregel eingerichtet wird. Diese Regel sollte Mindestbestand, fehlgeschlagene Läufe, Speicherplatz und nachgewiesene Wiederherstellbarkeit berücksichtigen.

Quellen und Stand

2026-10-24

• rclone.org — remote_setup
• rclone.org — drive
• developers.google.com — identity
• developers.google.com — identity
• rclone.org — commands
• rclone.org — crypt