LW IT Solutions
« Blog Overview /IT & Networks / Rclone mit Google Drive auf einem Headless-Server...
This post in other languages:

Rclone mit Google Drive auf einem Headless-Server einrichten

Rclone mit Google Drive auf einem Headless-Server einrichten
Inhalt
  1. Phase 1: GCP-Projekt erstellen (Rate-Limits vermeiden)
  2. Phase 2: Lokale Autorisierung
  3. Phase 3: Server-Konfiguration
  4. Phase 4: Backups automatisieren
  5. Quellen

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.

Diagramm zum Artikel: Phase 1: GCP-Projekt erstellen, Phase 2: Lokale Autorisierung, Phase 3: Server-Konfiguration …
Der Ablauf aus dem Artikel in 4 Schritten: Phase 1: GCP-Projekt erstellen, Phase 2: Lokale Autorisierung, Phase 3: Server-Konfiguration, Phase 4: Backups automatisieren.

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:

  1. Projekt erstellen: In der Google Cloud Console die Projektauswahl öffnen und auf Neues Projekt klicken. Als Projektname eignet sich etwa „Rclone Backup“.
  2. API aktivieren: Nach Google Drive API suchen und auf Aktivieren klicken.
  3. 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/drive hinzufü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.
  4. 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).

  1. Rclone auf dem lokalen PC installieren.
  2. Ein Terminal öffnen und rclone config eingeben.
  3. n (New remote) drücken und einen Namen vergeben (z. B. gdrive).
  4. drive als Speichertyp wählen.
  5. Client-ID und Client-Secret einfügen.
  6. Bei der Frage Use auto config? y (Ja) eingeben.
  7. Der Browser öffnet sich. Dort einloggen und die Freigabe erteilen.
  8. 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).

  1. Rclone installieren (sudo apt install rclone).
  2. rclone config starten.
  3. Ein neues Remote (n) erstellen, exakt wie lokal benennen (gdrive), drive wählen und ID/Secret einfügen.
  4. Bei Use auto config? diesmal n (Nein) wählen.
  5. Bei der Frage nach dem Token den kopierten JSON-Block einfügen.
  6. 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.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

2 Kommentare

  1. Christoph Wenninger

    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 7d läuft auf dem Remote-Pfad, unabhängig davon, ob der tar-Lauf davor erfolgreich war. Ist das so gemeint?

    1. Lukas Wojcik Autor

      Das Gefühl ist berechtigt, und es sind sogar zwei Punkte an derselben Zeile.

      Der erste: rclone delete kennt nur den Pfad und das Alter, nicht die Herkunft. Alles unter ServerBackups, 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 per rclone lsf die Altersregel. Sicherungen scheitern selten laut; sie scheitern still und fallen erst auf, wenn sie gebraucht werden.

Kommentar schreiben

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.

ALL ARTICLES & CATEGORIES

CCTV

Diese Rubrik per RSS verfolgen

Cloud & AI

Diese Rubrik per RSS verfolgen

Data Privacy

Alle 12 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Analytics

Alle 45 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Digital Marketing

Alle 25 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

IT & Networks

Alle 15 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Raspberry Pi

Diese Rubrik per RSS verfolgen

Smart Home

Alle 13 Artikel dieser Rubrik Diese Rubrik per RSS verfolgen

Web Entwicklung

Diese Rubrik per RSS verfolgen

WordPress-Plugins & Tricks

Diese Rubrik per RSS verfolgen