{"id":116,"date":"2026-07-16T22:58:22","date_gmt":"2026-07-16T20:58:22","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=116"},"modified":"2026-10-24T00:57:43","modified_gmt":"2026-10-23T22:57:43","slug":"rclone-mit-google-drive-auf-einem-headless-server-einrichten","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/it-networks-de\/rclone-mit-google-drive-auf-einem-headless-server-einrichten\/","title":{"rendered":"Rclone mit Google Drive auf einem Headless-Server einrichten"},"content":{"rendered":"

Rclone kann Dateien von einem Server ohne grafische Oberfl\u00e4che auf Google Drive kopieren. Die Anmeldung erfolgt einmal \u00fcber einen Rechner mit Browser. Danach arbeitet der Server mit der gespeicherten Konfiguration. Ein erfolgreicher Upload ersetzt allerdings keine Wiederherstellungsprobe.<\/p>\n

Diese Anleitung richtet einen eigenen OAuth-Client ein und zeigt eine Dateisicherung, die bei Fehlern abbricht. Voraussetzungen sind ein Google-Konto mit gen\u00fcgend freiem Speicher, SSH-Zugang und Rclone auf Server und lokalem Rechner. Das Beispiel sichert ein Webverzeichnis, kein vollst\u00e4ndiges Betriebssystem und keine laufende Datenbank.<\/p>\n

\"Rclone:<\/figure>\n

Phase 1: Eigenen Google-Client vorbereiten<\/h2>\n

Die aktuelle Rclone-Dokumentation k\u00fcndigt das Ende der gemeinsam genutzten Google-Drive-Client-ID im Jahr 2026 an. Eine eigene Client-ID vermeidet diese Abh\u00e4ngigkeit. Google-Quoten und Drosselung bleiben trotzdem m\u00f6glich; ein eigenes Projekt hebt keine API-Limits auf.<\/p>\n

    \n
  1. In der Google Cloud Console<\/a> ein Projekt anlegen oder ausw\u00e4hlen und die Google Drive API aktivieren.<\/li>\n
  2. In der Google Auth Platform die Angaben unter Branding und Zielgruppe ausf\u00fcllen. F\u00fcr ein gew\u00f6hnliches privates Google-Konto ist die Zielgruppe \u201eExtern\u201c vorgesehen.<\/li>\n
  3. Den ben\u00f6tigten Drive-Zugriffsbereich konfigurieren. Das folgende Beispiel verwendet https:\/\/www.googleapis.com\/auth\/drive<\/code> und erh\u00e4lt damit weitreichenden Dateizugriff. Engere Bereiche sind m\u00f6glich, decken aber andere Anwendungsf\u00e4lle ab.<\/li>\n
  4. Einen OAuth-Client vom Typ \u201eDesktop-App\u201c anlegen. Client-ID und Client-Secret f\u00fcr die Rclone-Konfiguration bereithalten.<\/li>\n
  5. Bei einer externen Anwendung im Status \u201eTesting\u201c verfallen Refresh-Tokens mit diesem Drive-Bereich nach sieben Tagen. F\u00fcr dauerhaften Betrieb den passenden Produktionsstatus und die Verifizierungsanforderungen pr\u00fcfen. \u201eIn Produktion\u201c verhindert diese spezielle Testfrist, garantiert aber kein dauerhaft g\u00fcltiges Token.<\/li>\n<\/ol>\n

    Publikation und Google-Verifizierung sind unterschiedliche Schritte. Bei pers\u00f6nlicher Nutzung k\u00f6nnen Ausnahmen von der Verifizierung gelten. Warnhinweise, Nutzergrenzen und organisatorische Vorgaben bleiben gesondert zu beachten.<\/p>\n

    Phase 2: Autorisierung auf dem Server starten<\/h2>\n

    Rclone auf beiden Rechnern installieren und mit rclone version<\/code> die Versionen vergleichen; f\u00fcr die Autorisierung empfiehlt Rclone dieselbe Version. Unter Debian oder Ubuntu ist ein Paket \u00fcber sudo apt install rclone<\/code> verf\u00fcgbar. Die Dialogtexte k\u00f6nnen zwischen Versionen abweichen.<\/p>\n

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

      Phase 3: Im lokalen Browser anmelden<\/h2>\n

      Den vom Server ausgegebenen Autorisierungsbefehl auf dem Rechner mit Browser ausf\u00fchren. Nach der Google-Anmeldung und Freigabe liefert rclone authorize<\/code> ein Ergebnis zum Kopieren. Dieses Ergebnis am wartenden Serverdialog einf\u00fcgen und die Remote-Konfiguration best\u00e4tigen. Ein gew\u00f6hnlicher lokaler rclone config<\/code>-Durchlauf ist nicht mit diesem Token-Ausgabeschritt gleichzusetzen.<\/p>\n

      Mit rclone lsd gdrive:<\/code> l\u00e4sst sich der Zugriff auf die Ordner pr\u00fcfen. Ein leeres Drive kann eine leere Liste liefern; entscheidend sind auch R\u00fcckgabewert und Fehlermeldungen. rclone config file<\/code> zeigt den Speicherort der Konfiguration. Die Datei enth\u00e4lt Zugangsdaten und muss f\u00fcr den sp\u00e4teren Backup-Benutzer lesbar und aktualisierbar sein, ohne anderen Konten Zugriff zu geben.<\/p>\n

      Phase 4: Dateien kopieren und den Lauf pr\u00fcfen<\/h2>\n

      Das folgende Skript ben\u00f6tigt Bash, GNU tar, flock<\/code> und Rclone. Quellpfad, Backup-Verzeichnis und Remote sind vor dem ersten Lauf anzupassen. Das Zielverzeichnis liegt au\u00dferhalb des gesicherten Webverzeichnisses. Derselbe Benutzer muss Zugriff auf die Quelldateien und die Rclone-Konfiguration haben.<\/p>\n

      #!\/bin\/bash\nset -euo pipefail\numask 077\n\nSOURCE_DIR="\/var\/www\/html"\nBACKUP_DIR="$HOME\/backups\/www"\nREMOTE="gdrive:ServerBackups"\n\nmkdir -p -- "$BACKUP_DIR"\nexec 9>"$BACKUP_DIR\/.backup.lock"\nflock -n 9 || { printf 'Backup already running\\n' >&2; exit 1; }\n\nNAME="www_$(date -u +%Y%m%dT%H%M%S%NZ).tar.gz"\nARCHIVE="$BACKUP_DIR\/$NAME"\nPART="$ARCHIVE.part"\ntrap 'rm -f -- "$PART"' EXIT\n\ntar -czf "$PART" -C "$SOURCE_DIR" .\nmv -- "$PART" "$ARCHIVE"\nrclone copyto --immutable "$ARCHIVE" "$REMOTE\/$NAME"\nrclone check "$BACKUP_DIR" "$REMOTE" --include "\/$NAME" --one-way\n\nprintf 'Archive uploaded and checked: %s\\n' "$NAME"\n<\/code><\/pre>\n
      Das Skript erzeugt zun\u00e4chst eine tempor\u00e4re Archivdatei. Erst nach erfolgreichem tar<\/code> erh\u00e4lt das Archiv den endg\u00fcltigen Namen. Upload oder Vergleich mit rclone check<\/code> m\u00fcssen ebenfalls erfolgreich sein, bevor die Erfolgsmeldung erscheint. Die Sperre verhindert zwei gleichzeitige L\u00e4ufe mit demselben Backup-Verzeichnis. Der Vergleich pr\u00fcft Dateieigenschaften beziehungsweise verf\u00fcgbare Pr\u00fcfsummen, nicht die Funktionsf\u00e4higkeit einer wiederhergestellten Website.<\/p>\n
      Eine laufende Website kann w\u00e4hrend des Archivierens Dateien ver\u00e4ndern. F\u00fcr einen konsistenten Stand ist deshalb ein geeigneter Snapshot oder ein abgestimmtes Sicherungsfenster n\u00f6tig. Eine Datenbank ben\u00f6tigt einen eigenen konsistenten Export; tar \/var\/www\/html<\/code> sichert deren laufenden Inhalt nicht automatisch.<\/p>\n
      Nach einem manuellen Probelauf kann ein Cronjob das ausf\u00fchrbare Skript unter einem festen absoluten Pfad starten. R\u00fcckgabewerte und Protokolle geh\u00f6ren in eine Fehlerbenachrichtigung. Automatisches L\u00f6schen ist bewusst nicht enthalten: Lokale und entfernte Archive wachsen an, bis eine Aufbewahrungsregel eingerichtet wird. Diese Regel sollte Mindestbestand, fehlgeschlagene L\u00e4ufe, Speicherplatz und nachgewiesene Wiederherstellbarkeit ber\u00fccksichtigen.<\/p>\n
      \n
      Fragen und Antworten<\/h2>\n
      Warum folgt auf den Upload kein delete –min-age 7d?<\/h3>\n
      Eine reine Altersregel kann nach einer l\u00e4ngeren St\u00f6rung alle verbliebenen Sicherungen erfassen. Ein fehlgeschlagener Upload darf keine L\u00f6schung alter St\u00e4nde ausl\u00f6sen. Das Beispiel beendet Fehlerl\u00e4ufe und l\u00e4sst die Aufbewahrung als getrennte, ausdr\u00fccklich festzulegende Aufgabe offen.<\/p>\n
      Kann eine vorhandene Rclone-Konfiguration \u00fcbernommen werden?<\/h3>\n
      F\u00fcr Google Drive ist die sichere \u00dcbertragung einer bestehenden Konfigurationsdatei eine dokumentierte Alternative. rclone config file<\/code> zeigt den Pfad auf beiden Rechnern. Vor dem Kopieren sind vorhandene Remotes, Dateirechte und weiterhin g\u00fcltige Tokens zu pr\u00fcfen; eine bestehende Serverkonfiguration darf nicht ungepr\u00fcft \u00fcberschrieben werden. F\u00fcr die Wiederherstellung muss die Zugangskonfiguration unabh\u00e4ngig vom gesicherten Archiv verf\u00fcgbar bleiben.<\/p>\n
      Wann ist die Sicherung tats\u00e4chlich brauchbar?<\/h3>\n
      Erst eine Wiederherstellungsprobe zeigt, ob Dateien, Datenbankexport, Zugriffsrechte und notwendige Konfigurationen zusammenpassen. Ein Upload-Vergleich allein belegt das nicht. Ebenso ben\u00f6tigt der Schutz vertraulicher Inhalte eine eigene Entscheidung zur Verschl\u00fcsselung vor dem Upload, beispielsweise mit Rclone Crypt.<\/p>\n<\/div>\n
      Quellen und Stand<\/h2>\n
      2026-10-24<\/p>\n