LW IT Solutions
« Blog Overview /IT & Networks / How to Set Up Rclone with Google...
This post in other languages:

How to Set Up Rclone with Google Drive on a Headless Server (The Right Way)

How to Set Up Rclone with Google Drive on a Headless Server (The Right Way)
Contents
  1. Phase 1: Creating the GCP Project (Avoiding Rate Limits)
  2. Phase 2: Local Authorization
  3. Phase 3: Server Configuration
  4. Phase 4: Automating Backups
  5. Sources

Backing up a remote server (like a Raspberry Pi) directly to Google Drive is a brilliant way to ensure data safety. The tool for the job is Rclone – the “Swiss Army knife” of cloud storage. However, setting it up on a “headless” server (a machine without a graphical interface or web browser) can be tricky, especially when dealing with Google’s authentication.

This guide walks through the bulletproof method: creating a dedicated Google Cloud Platform (GCP) project to avoid rate limits, authorizing on a local machine, and moving the configuration over to the server.

Diagram for the article: Phase 1: Creating the GCP Project, Phase 2: Local Authorization, Phase 3: Server Configuration …
The sequence from the article in 4 steps: Phase 1: Creating the GCP Project, Phase 2: Local Authorization, Phase 3: Server Configuration, Phase 4: Automating Backups.

Phase 1: Creating the GCP Project (Avoiding Rate Limits)

Using Rclone’s default Google Drive client ID means sharing bandwidth with thousands of other users, leading to throttling. Here is how to create a dedicated one:

  1. Create a Project: Go to the Google Cloud Console, click the project dropdown, and select New Project. Name it something like “Rclone Backup”.
  2. Enable the API: Search for Google Drive API in the top search bar and click Enable.
  3. Configure OAuth Consent Screen:
    • Go to APIs & Services > OAuth consent screen.
    • Under Audience, choose External user type.
    • Under Branding, fill in the mandatory fields (App name, email addresses).
    • Under Data Access, add the scope .../auth/drive to give Rclone full access to manage files.
    • Under Audience, add the administrator’s Google account email as a test user.
    • Publish the app: still under Audience, click Publish app so that the publishing status changes from Testing to In production. As long as it stays on Testing, Google expires the refresh token after seven days, which would silently break the nightly backup from Phase 4 every week. The exemption from that rule covers only the basic name, email and profile scopes, not .../auth/drive. The app itself stays unverified, so the consent screen shows a warning that has to be confirmed once via Advanced.
  4. Generate Credentials:
    • Go to the Clients tab of the Google Auth Platform.
    • Click Create client.
    • Crucial step: Choose Desktop app as the application type. This prevents issues with redirect URLs later.
    • Click Create. Copy the Client ID and Client Secret.

Phase 2: Local Authorization

Since the server has no web browser, the access token gets generated on a main computer instead (Windows/Mac/Linux).

  1. Install Rclone on the local computer.
  2. Open a terminal and type rclone config.
  3. Press n for a new remote and name it (e.g., gdrive).
  4. Choose drive as the storage type.
  5. Paste the Client ID and Client Secret when prompted.
  6. When asked Use auto config?, type y (Yes).
  7. The browser opens. Log in and grant permission.
  8. Back in the terminal, a block of JSON code containing the token appears. Copy this entire token block.

Phase 3: Server Configuration

Now on to the headless server (via SSH).

  1. Install Rclone on the server (sudo apt install rclone).
  2. Run rclone config.
  3. Create a new remote (n), give it exactly the name used locally (gdrive), choose drive, and paste the Client ID and Secret.
  4. When asked Use auto config?, type n (No).
  5. When prompted for the result/token, paste the JSON block copied from the local machine.
  6. Save and exit. Test it by typing rclone lsd gdrive:. The Google Drive folders should appear.

Phase 4: Automating Backups

Now that Rclone is authorized, let’s set up an automated backup script. Create a file named backup.sh:

#!/bin/bash
BACKUP_DIR="/path/to/local/backup"
DATE=$(date +%Y-%m-%d)
REMOTE="gdrive:ServerBackups"

# Your backup commands here (e.g., mysqldump, tar)
tar -czf "$BACKUP_DIR/data_$DATE.tar.gz" /var/www/html

# Copy to Google Drive (Rclone creates the folder automatically)
rclone copy "$BACKUP_DIR/data_$DATE.tar.gz" "$REMOTE"

# Keep only the last 7 days of backups on Google Drive
rclone delete "$REMOTE" --min-age 7d

Make the script executable (chmod +x backup.sh) and add it to cron (crontab -e) to run nightly. The headless server is now securely backed up to the cloud.

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 comments

  1. Fiona Ashworth

    The seven-day token expiry for apps left in testing is the detail that turns a working backup into a weekly failure, and it is buried deep in Google’s own documentation.

    Before I publish the consent screen: what is the actual downside of an app that stays unverified? The warning during authorisation I can live with, but I would rather know what else changes.

    1. Lukas Wojcik Author

      For this use case, almost nothing beyond that warning. Verification governs what an app may ask of other people; a project that only ever authorises its own owner is outside the situation verification exists for. The one thing that does change is the refresh token lifetime, which is the entire reason to publish.

      The scope matters more than the status. Drive access is a sensitive scope, so an unverified app stays limited to a small number of users — fine for a personal backup, unworkable for something handed to colleagues. At that point verification becomes a real project rather than a checkbox.

      The alternative worth knowing about is a service account, which never needs an interactive login at all. The trade is that it owns its own Drive space rather than reaching into a personal one, so either the backup lives there and quota is bought separately, or a shared drive is used with the service account as a member. For a single Raspberry Pi the published desktop client is the shorter path; for a fleet, the service account is the one that survives staff changes.

Write a comment

The email address is not published. Required fields are marked with an asterisk.

ALL ARTICLES & CATEGORIES

CCTV

Follow this category by RSS

Cloud & AI

Follow this category by RSS

Data Privacy

All 11 articles in this category Follow this category by RSS

Digital Analytics

All 44 articles in this category Follow this category by RSS

Digital Marketing

All 25 articles in this category Follow this category by RSS

IT & Networks

All 15 articles in this category Follow this category by RSS

Raspberry PI

Follow this category by RSS

Smart Home

All 11 articles in this category Follow this category by RSS

Web Development

Follow this category by RSS

WordPress Plugins & Tricks

Follow this category by RSS