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

Contents
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.
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:
- Create a Project: Go to the Google Cloud Console, click the project dropdown, and select New Project. Name it something like “Rclone Backup”.
- Enable the API: Search for Google Drive API in the top search bar and click Enable.
- 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/driveto 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.
- 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).
- Install Rclone on the local computer.
- Open a terminal and type
rclone config. - Press
nfor a new remote and name it (e.g.,gdrive). - Choose
driveas the storage type. - Paste the Client ID and Client Secret when prompted.
- When asked
Use auto config?, typey(Yes). - The browser opens. Log in and grant permission.
- 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).
- Install Rclone on the server (
sudo apt install rclone). - Run
rclone config. - Create a new remote (
n), give it exactly the name used locally (gdrive), choosedrive, and paste the Client ID and Secret. - When asked
Use auto config?, typen(No). - When prompted for the result/token, paste the JSON block copied from the local machine.
- 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.
2 comments
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.
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.