Rclone mit Google Drive auf einem Headless-Server einrichten

Inhalt
Die direkte Sicherung eines Remote-Servers (z. B. eines Raspberry Pi) auf Google Drive ist eine hervorragende Möglichkeit, die Datensicherheit zu gewährleisten. Das beste Werkzeug dafür ist Rclone. Die Einrichtung auf einem „Headless“-Server (ohne grafische Oberfläche oder Browser) kann jedoch knifflig sein.
Diese Anleitung beschreibt die sicherste Methode: Erstellung eines eigenen Google Cloud Platform (GCP) Projekts, Autorisierung auf dem lokalen PC und Übertragung der Konfiguration auf den Server.
Phase 1: GCP-Projekt erstellen (Rate-Limits vermeiden)
Wer die Standard-Client-ID von Rclone verwendet, teilt sich die Bandbreite mit Tausenden anderen, was zu Drosselung führt. So entsteht eine eigene:
- Projekt erstellen: In der Google Cloud Console die Projektauswahl öffnen und auf Neues Projekt klicken. Als Projektname eignet sich etwa „Rclone Backup“.
- API aktivieren: Nach Google Drive API suchen und auf Aktivieren klicken.
- OAuth-Zustimmungsbildschirm konfigurieren:
- Zu APIs & Dienste > OAuth-Zustimmungsbildschirm wechseln.
- Unter Zielgruppe den Nutzertyp Extern wählen.
- Unter Branding die Pflichtfelder ausfüllen.
- Unter Datenzugriff (Data Access) den Bereich
.../auth/drivehinzufügen. - Unter Zielgruppe die eigene Google-E-Mail-Adresse als Testnutzer eintragen.
- App veröffentlichen: Ebenfalls unter Zielgruppe mit App veröffentlichen den Veröffentlichungsstatus von Test auf In Produktion umstellen. Solange er auf Test steht, verfällt das Refresh-Token nach sieben Tagen, und das nächtliche Backup aus Phase 4 bricht wöchentlich ab. Die Ausnahme von dieser Regel gilt nur für die Basisbereiche Name, E-Mail und Profil, nicht für
.../auth/drive. Die App bleibt unbestätigt, daher erscheint bei der Freigabe einmalig ein Warnhinweis, der über Erweitert zu bestätigen ist.
- Anmeldedaten generieren:
- Zum Reiter Clients der Google Auth Platform wechseln.
- Dort über Client erstellen (Create client) eine neue OAuth-Client-ID anlegen.
- Wichtig: Als Anwendungstyp Desktop-App wählen. Das vermeidet spätere Probleme mit den Weiterleitungs-URLs.
- Client-ID und Client-Secret kopieren.
Phase 2: Lokale Autorisierung
Da der Server keinen Browser hat, entsteht das Token auf dem Hauptrechner (Windows/Mac/Linux).
- Rclone auf dem lokalen PC installieren.
- Ein Terminal öffnen und
rclone configeingeben. n(New remote) drücken und einen Namen vergeben (z. B.gdrive).driveals Speichertyp wählen.- Client-ID und Client-Secret einfügen.
- Bei der Frage
Use auto config?y(Ja) eingeben. - Der Browser öffnet sich. Dort einloggen und die Freigabe erteilen.
- Im Terminal erscheint nun ein JSON-Code-Block. Diesen gesamten Token-Block kopieren.
Phase 3: Server-Konfiguration
Weiter geht es auf dem Headless-Server (über SSH).
- Rclone installieren (
sudo apt install rclone). rclone configstarten.- Ein neues Remote (
n) erstellen, exakt wie lokal benennen (gdrive),drivewählen und ID/Secret einfügen. - Bei
Use auto config?diesmaln(Nein) wählen. - Bei der Frage nach dem Token den kopierten JSON-Block einfügen.
- Mit
rclone lsd gdrive:testen. Nun sollten die Ordner erscheinen.
Phase 4: Backups automatisieren
Ein Skript namens backup.sh anlegen:
#!/bin/bash
BACKUP_DIR="/pfad/zum/lokalen/backup"
DATE=$(date +%Y-%m-%d)
REMOTE="gdrive:ServerBackups"
# Archiv erstellen
tar -czf "$BACKUP_DIR/data_$DATE.tar.gz" /var/www/html
# Auf Google Drive kopieren (Rclone erstellt den Ordner automatisch)
rclone copy "$BACKUP_DIR/data_$DATE.tar.gz" "$REMOTE"
# Nur die letzten 7 Tage aufheben
rclone delete "$REMOTE" --min-age 7d
Das Skript ausführbar machen (chmod +x backup.sh) und als nächtlichen Cronjob eintragen (crontab -e). Der Server ist damit sicher in der Cloud gesichert.
2 Kommentare
Der Hinweis auf den Veröffentlichungsstatus hat mir vermutlich einige Wochen Fehlersuche erspart — dass ein Token im Testbetrieb nach sieben Tagen verfällt, steht an keiner Stelle, an der es auffallen würde.
Zur letzten Zeile des Skripts habe ich allerdings ein ungutes Gefühl:
rclone delete --min-age 7dläuft auf dem Remote-Pfad, unabhängig davon, ob dertar-Lauf davor erfolgreich war. Ist das so gemeint?Das Gefühl ist berechtigt, und es sind sogar zwei Punkte an derselben Zeile.
Der erste:
rclone deletekennt nur den Pfad und das Alter, nicht die Herkunft. Alles unterServerBackups, was älter als sieben Tage ist, verschwindet — auch Dateien, die dort aus anderem Anlass liegen. Der Ordner gehört deshalb ausschließlich diesem Skript.Der zweite wiegt schwerer: Die Aufbewahrung ist als Alter formuliert, nicht als Anzahl. Fällt der Cronjob zwei Wochen aus oder scheitert das Archivieren, löscht der nächste Lauf trotzdem alles, was die Frist überschritten hat — und im ungünstigen Fall ist das der letzte verbliebene Stand. Zwischen Erzeugen und Löschen gehört daher eine Abbruchbedingung (
tar ... || exit 1), und wo eine Mindestanzahl gefordert ist, ersetzt eine Zählung perrclone lsfdie Altersregel. Sicherungen scheitern selten laut; sie scheitern still und fallen erst auf, wenn sie gebraucht werden.