{"id":114,"date":"2026-07-16T22:43:39","date_gmt":"2026-07-16T20:43:39","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=114"},"modified":"2026-10-24T00:57:43","modified_gmt":"2026-10-23T22:57:43","slug":"how-to-set-up-rclone-with-google-drive-on-a-headless-server-the-right-way","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/it-networks\/how-to-set-up-rclone-with-google-drive-on-a-headless-server-the-right-way\/","title":{"rendered":"How to Set Up Rclone with Google Drive on a Headless Server (The Right Way)"},"content":{"rendered":"

Rclone can copy files from a server without a graphical interface to Google Drive. Authorization takes place once on a computer with a browser; the server then uses the saved configuration. A successful upload is still not a substitute for a restore test.<\/p>\n

This guide sets up a dedicated OAuth client and a file-backup example that stops on errors. Requirements are a Google account with sufficient storage, SSH access, and Rclone on both computers. The example backs up a web directory, not a complete operating system or a running database.<\/p>\n

\"Rclone:<\/figure>\n

Phase 1: Prepare a dedicated Google client<\/h2>\n

The current Rclone documentation announces retirement of the shared Google Drive client ID during 2026. A dedicated client ID avoids that dependency. Google quotas and throttling still apply; a separate project does not remove API limits.<\/p>\n

    \n
  1. The setup requires a new or existing project in the Google Cloud Console<\/a> with the Google Drive API enabled.<\/li>\n
  2. Branding and Audience settings in Google Auth Platform define the application and its users. A normal personal Google account uses an external audience.<\/li>\n
  3. The Drive scope defines the permitted access. This example uses https:\/\/www.googleapis.com\/auth\/drive<\/code>, which grants broad file access. Narrower scopes are available for different use cases.<\/li>\n
  4. The OAuth client type is Desktop app. Rclone configuration requires its client ID and client secret.<\/li>\n
  5. For an external app in Testing, refresh tokens with this Drive scope expire after seven days. Continued operation requires the appropriate production status and a check of verification requirements. In production removes that particular testing limit, not every reason a token can expire.<\/li>\n<\/ol>\n

    Publishing and Google verification are separate steps. Personal-use exceptions can apply to verification. Warnings, user limits, and organizational policies still require separate consideration.<\/p>\n

    Phase 2: Start authorization on the server<\/h2>\n

    Rclone must be installed on both computers. rclone version<\/code> reports each version; the remote-setup documentation recommends the same version. Debian and Ubuntu provide a package through sudo apt install rclone<\/code>. Prompt wording can differ between versions.<\/p>\n

      \n
    1. On the server, rclone config<\/code> creates a new remote named gdrive<\/code> with storage type drive<\/code>.<\/li>\n
    2. The configuration requires the dedicated client ID, client secret, and intended scope. This flow does not use a service account.<\/li>\n
    3. The answer to browser-based automatic authentication is n<\/code>. Rclone displays the appropriate rclone authorize<\/code> command for the local computer and waits at config_token<\/code>.<\/li>\n<\/ol>\n

      Phase 3: Sign in through the local browser<\/h2>\n

      The authorization command displayed by the server runs on the computer with a browser. After Google sign-in and consent, rclone authorize<\/code> provides a result to copy. That result belongs in the waiting server prompt; confirmation then completes the remote configuration. A normal local rclone config<\/code> session is not the same as this token-output step.<\/p>\n

      rclone lsd gdrive:<\/code> checks folder access. An empty Drive can produce an empty listing; the exit status and error messages also matter. rclone config file<\/code> shows the configuration location. The file contains credentials and must remain readable and writable by the backup account while being protected from other accounts.<\/p>\n

      Phase 4: Copy files and check the run<\/h2>\n

      The following script requires Bash, GNU tar, flock<\/code>, and Rclone. The source directory, backup directory, and remote require adjustment before use. The archive directory must remain outside the source directory. The same account needs access to both the source files and the Rclone configuration.<\/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
      The script first creates a temporary archive. Only successful completion of tar<\/code> gives it the final name. The upload and rclone check<\/code> must also succeed before the success message appears. The lock prevents simultaneous runs using the same backup directory. The comparison checks file properties or available checksums, not whether a restored website works.<\/p>\n
      A running website can change files during archiving. A suitable snapshot or coordinated backup window is therefore needed for a consistent state. A database needs its own consistent export; archiving \/var\/www\/html<\/code> does not automatically capture the running database.<\/p>\n
      After a manual trial, cron can launch the executable script using a fixed absolute path. Exit statuses and logs need an error-notification mechanism. Automatic deletion is deliberately absent: local and remote archives accumulate until a retention policy is configured. That policy should account for a minimum retained set, failed runs, available space, and demonstrated recoverability.<\/p>\n
      \n
      Questions and answers<\/h2>\n
      Why does the upload not end with delete –min-age 7d?<\/h3>\n
      An age-only rule can select every remaining backup after a long interruption. A failed upload must not trigger deletion of older copies. This example stops failed runs and leaves retention as a separate task requiring an explicit policy.<\/p>\n
      Can an existing Rclone configuration be transferred?<\/h3>\n
      Secure transfer of an existing configuration file is a documented alternative for Google Drive. rclone config file<\/code> shows the path on both computers. Existing remotes, file permissions, and token validity need checking before the transfer; an existing server configuration must not be blindly overwritten. Recovery credentials need to remain accessible independently of the backup they unlock.<\/p>\n
      When is the backup actually usable?<\/h3>\n
      A restore test establishes whether files, database exports, permissions, and required configuration work together. An upload comparison alone does not establish that. Confidential data also requires a separate decision about encryption before upload, for example with Rclone Crypt.<\/p>\n<\/div>\n
      Sources and review date<\/h2>\n
      2026-10-24<\/p>\n