Using Rclone to Sync Google Drive with SFTP To Go

Tools like Chronosync, FreeFileSync, Mountain Duck, and WinSCP exist for a specific use case: copying data between a desktop computer and an SFTP server. As great as they are, when you need more storage types in the pipeline, your best option is Rclone.

Rclone works on virtually every popular operating system, can be automated with scripts, and supports over a hundred file storage services.

This guide walks through setting up both remotes, running your first sync, and navigating various SFTP To Go specifics.

Install rclone

Start by installing rclone: go to https://rclone.org/downloads/, download the program for your operating system, and follow the installation instructions.

Rclone in a nutshell

Rclone is a command-line application. It expects you to type commands that will perform a specific task. Most of the time, the commands will follow the “action command followed by a path” syntax. Here is a syncing example:

rclone sync source:path destination:path [options]

Here, you start with a command that instructs rclone what specific operation to perform (syncing) and then submits two locations, source: and destination:. In rclone’s terminology, these locations are called remotes. They are essentially handles for predefined storage configurations that you can create.

Here is a simple example of syncing between two remotes:

rclone sync gdrive:invoices/ sftptogo:invoices/

In this case, rclone finds all new or changed files in the invoices folder on a Google Drive account and copies them to the invoices folder on an SFTP To Go account.

Most of the time, you will be using commands for copying or moving files and performing one-way and two-way syncs between remotes. However, rclone uses the same command-line interface for pretty much everything: changing remotes’ configuration, serving local files over HTTP. 

Rclone can also perform actions that are specific to storage types, e.g., cleaning the Trash folder on Google Drive or removing all pending multipart uploads older than 24 hours on an S3 bucket.

With over a hundred supported data storage types, rclone is an anything-to-anything syncing solution. If there’s a documented way to access a storage, rclone likely can do it already.

Setting up remotes

We are going to need two remotes: one for Google Drive and one to access the data on your SFTP To Go account. 

First, please follow our guide to create an rclone remote for SFTP To Go. After that, let’s create a remote for Google Drive. 

Getting access to your Google Drive account from a 3rd-party application like rclone requires creating and setting up a project on Google Cloud. We’ll start from scratch, where you only have a Google account and no projects on Google Cloud.

1. First, let’s create a project. Go to https://console.cloud.google.com/welcome/new and click Create or select a project, then New project.

2. Next, set a project name and select the parent organization, then click Create.

3. Open the newly created project and go to APIs & Services and select Library, search for Google Drive API, and enable it. 

Without this enabled, the OAuth client won't be able to talk to Drive at all.

4. Go to APIs & Services, select OAuth consent screen, and click Get started to configure. 

It's a quick setup process. You can use rclone for the App Screen and use your regular Google account email when asked for one.

After that, set Audience to External (don’t worry, it will only be accessible to users you explicitly granted access to). 

To finish, submit a contact email, agree to the Google API Services user data policy, and click Create. This will create the initial OAuth configuration.

5. From the OAuth Overview page where you end up in the previous step, go to Clients and click + Create client. 

Select Desktop app as the application type and give it a name (rclone will work just fine). 

The platform will generate a new client ID and a client secret. Copy them somewhere safe and accessible, as you won't be able to see them ever again.

6. Now you need to give at least one user access to the app. Go to the Audience page and click + Add users in the Test users section.

Submit your Google account email and click Save.

Now you are ready to create a remote config for Google Drive:

rclone config create gdrive drive client_id=YOUR_CLIENT_ID client_secret=YOUR_CLIENT_SECRET scope=drive

Replace YOUR_CLIENT_ID and YOUR_CLIENT_SECRET with actual credentials. The scope setting defines what kind of access you get to files; drive simply means full access to all files on the remote. You can set a few other defaults, see here for details.

Running the command will open a web browser when you need to select your Google account. 

Google may display a warning that the app you are about to grant access to your data hasn’t been verified yet. Click Continue.

Once you confirm you agree to grant rclone access to manage your Google Drive files, rclone will create the remote config for Google Drive.

Rclone will display a quick summary about the newly created remote:

[gdrive]
type = drive
client_id = 244165275455-8121cccf6osbfals32lirb9kg3bnh4pi.apps.googleusercontent.com
client_secret = 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
scope = drive
token = {"access_token":"ya29.a0AdMD6EiDSjd1FjvMSkPAPUUEE3qLF6cvnR5WuUqtFm3uIW8WAw_my3SofumEkh4Zes_NqD9G1bu2wXfyrV2Ae6EkLCfEHc0dtpl-WKvd2uZu7-HKhVss_wq4gR9N7em_yLFCoo6038LCcSD6NP9iN_RXGMtXv9xGFI83ltxPGDLFvYN2JnEpSG8tB4hn8YFUh0xqliMaCgYKAVsSARASFQHGX2MisSj3ijIbDyk5YPgJyhfY8A0206","token_type":"Bearer","refresh_token":"1//03q97_eZyeKEqCgYIARAAGAMSNwF-L9Ir57mOJHy-qPdaM9mzphPTxze4huxudC5yyNpRlOYkU6pnnGYjgOQH4KKyIq0D1fW6Kgk","expiry":"2026-09-06T23:26:37.509664722+02:00","expires_in":3599}
team_drive = 

Take a moment to see if all the details you specified are correct. If you made a mistake, use either rclone config to edit settings with a wizard or edit the rclone configuration file (e.g., ~/.config/rclone/rclone.conf) in a text editor.

Test connectivity

When configured correctly, rclone should be able to connect to both remotes. To test that, you can list all directories in the root directory for each remote.

For Google Drive, run:

rclone lsd gdrive:
          0 2026-07-23 12:58:36        -1 inbound

Repeat the same for the SFTP To Go remote:

rclone lsd sftptogo:
       4096 2026-07-29 17:33:03        -1 inbound

Create folder structure

For the purpose of this article, let's assume that you need to collaborate on documents in Google Drive, but the company’s compliance rules demand finalized documents to be mirrored to an immutable, tamper-evident archive on SFTP To Go that can be pointed to during an audit.

Therefore, new documents land in an inbound folder first. Once they are either processed or manually confirmed, they go to the archive folder where they are treated as a permanent record. Let’s reproduce this logic. 

Start by creating a folder named inbound:

rclone mkdir sftptogo:inbound

Tell rclone to list folders on your account to see if the operation was successful:

rclone lsd sftptogo:
         -1 1970-01-01 01:00:00        -1 inbound

Now, repeat to create another folder named archive. This is where approved files will be stored.

Now let’s learn how to perform a simple one-way sync between the two remotes.

One-way sync: Google Drive to SFTP To Go

A one-way sync updates the target folder to mirror the source. It copies missing or modified files from the source and deletes any files on the target that no longer exist on the source.

To see this in action, let's set up a scenario where the source and target drift apart. We copy files to a target folder, delete a file from it, and run rclone sync to bring it back into alignment with the source. Start with copying:

rclone copy gdrive:inbound/ sftptogo:inbound/ --dry-run
2026/07/29 17:34:39 NOTICE: 2024/contract_03.pdf: Skipped copy as --dry-run is set (size 31.326Ki)
2026/07/29 17:34:39 NOTICE: 2024/contract_04.pdf: Skipped copy as --dry-run is set (size 30.244Ki)
2026/07/29 17:34:39 NOTICE: 2024/contract_05.pdf: Skipped copy as --dry-run is set (size 31.545Ki)
2026/07/29 17:34:39 NOTICE: 2024/contract_06.pdf: Skipped copy as --dry-run is set (size 31.443Ki)
2026/07/29 17:34:39 NOTICE: 2024/contract_01.pdf: Skipped copy as --dry-run is set (size 31.042Ki)
2026/07/29 17:34:39 NOTICE: 2024/contract_02.pdf: Skipped copy as --dry-run is set (size 29.877Ki)
2026/07/29 17:34:39 NOTICE: 2024/contract_07.pdf: Skipped copy as --dry-run is set (size 30.019Ki)

Strictly speaking, the --dry-run flag here is not necessary, as the first copy to a remote is typically innocuous enough. However, using it for operations that involve moving pre-existing files around and deleting data is a very good habit to develop. Dry runs with rclone report potential issues before they happen, so you can amend the command or reconsider it entirely.

If you don’t see any issues during the dry run, proceed with actually copying the files:

rclone copy gdrive:inbound/ sftptogo:inbound/ -v

To check that the files have arrived at the destination, run rclone ls to list all files on the remote:

rclone ls sftptogo:inbound/
    31787 2024/contract_01.pdf
    30594 2024/contract_02.pdf
    32078 2024/contract_03.pdf
    30970 2024/contract_04.pdf
    32302 2024/contract_05.pdf
    32198 2024/contract_06.pdf
    30739 2024/contract_07.pdf

To test syncing, let’s make the destination remote different enough from the source remote to give rclone something to fix. To do that, let’s remove one copied file:

rclone delete sftptogo:inbound/2024/contract_07.pdf --dry-run
2026/08/09 17:52:28 NOTICE: contract_07.pdf: Skipped delete as --dry-run is set (size 30.019Ki)

If there are no issues in the output, repeat the command without --dry-run and sync the two remotes:

rclone sync gdrive:inbound/ sftptogo:inbound/ -v --dry-run
2026/08/09 17:58:31 INFO  : 2024/contract_01.pdf: Copied (replaced existing)
2026/08/09 17:58:31 INFO  : 2024/contract_07.pdf: Copied (new)
2026/08/09 17:58:31 INFO  : 2024/contract_02.pdf: Copied (replaced existing)
2026/08/09 17:58:32 INFO  : 2024/contract_03.pdf: Copied (replaced existing)
2026/08/09 17:58:32 INFO  : 2024/contract_04.pdf: Copied (replaced existing)
2026/08/09 17:58:33 INFO  : 2024/contract_05.pdf: Copied (replaced existing)
2026/08/09 17:58:33 INFO  : 2024/contract_06.pdf: Copied (replaced existing)

As is evident from the output, rclone replaced the files that already existed on the destination remote and copied the file you had previously deleted on the destination remote. That makes the SFTP To Go remote a perfect mirror of the Google Drive remote.

To revert the direction of a one-way sync, simply swap source and destination remotes in the command line:

rclone sync sftptogo:archive/ gdrive:archive/ -v
output

Inclusion and exclusion rules

There are many scenarios where you need to explicitly include or exclude specific folders and files from a sync. One common use case is where a folder to sync contains a mix of file types from active collaborations, but you only need the finalized PDFs to make it into an immutable archive. 

Rclone has three ways to handle such use cases: inclusion rules, exclusion rules, and filters. Let’s start with inclusion:

rclone sync gdrive:projects/ sftptogo:archive/ --include "*.pdf" --dry-run

Here, rclone only considers file with the .pdf extension regardless of what their names are. So a .docx file still being edited on Google Docs is left alone in projects. but a finalized PDF gets copied to the archive.

Similarly, the following command will exclude all .psd files from the sync:

rclone sync gdrive:projects/ sftptogo:archive/ --exclude "*.psd" --dry-run

The part where it gets interesting is when you need to combine inclusion and exclusion in the same sync. Rclone follows the “first match wins” design. If the first rule it applies includes a broad range of files, and an exclusion is applied next to remove certain files from that sampling, the exclusion won't work because matching files were already captured by the first rule. Here is a quick example:

rclone sync gdrive:projects/ sftptogo:archive/ --include "*.docx" --exclude "*"

Here, rclone will include all .docx files in the sync and exclude everything else. But if you reverse the rule order:

rclone sync gdrive:projects/ sftptogo:archive/ --exclude "*" --include "*.docx"

Rclone will exclude everything right away. This will prevent the second rule from ever being evaluated because * covers all files, including .docx.

It gets even more complex when applying multiple rules. Let's say you are syncing a directory of office exports and design deliverables to cold storage with these requirements:

• Exclude all draft documents (*_draft.docx)
• Exclude everything inside any /temp_assets/ folder
• Except keep draft documents specifically inside /archive/2024/ (retained for compliance auditing)
• Include everything else (finalized PDFs, presentations, spreadsheet reports)

With the combination flags, the command looks like this:

rclone sync gdrive:projects/ sftptogo:archive/ \
  --include "/archive/2024/**_draft.docx" \
  --exclude "temp_assets/**" \
  --exclude "*_draft.docx" \
  --include "**"

This is noticeably harder to read and doesn’t scale well when later you need multiple other archive-year exceptions. Let’s use --filter instead. 

First, create a text file with these filter rules:

# document-sync-filters.txt
+ /archive/2024/**_draft.docx
- *_draft.docx
- temp_assets/**
+ **

Then run the sync using the filter file:

rclone sync gdrive:projects/ sftptogo:archive/ --filter-from document-sync-filters.txt

This approach has important benefits:

• Clear contextual order: Lines 1 and 2 read sequentially to exclude draft Word documents while retaining the 2024 archive folder.
• Scalable exceptions: Adding new compliance rules (e.g., a 2023 archive) will require appending single lines. You wouldn’t have to reshuffle command flags.
• Maintainable documentation: You can version-control filter files, reuse them in automation, and add inline comments that explain the rationale behind rules.

Two-way syncing

While one-way sync assumes that the destination remote should be a perfect mirror of the source remote, bidirectional (two-way) sync’s job is to bring both remotes into the same state. The bisync command in rclone attempts to detect changes on both sides and reconcile them.

Before any syncing can start, rclone needs to establish the baseline, which is the original state of files and folders on both remotes. Every time you run bisync after that, rclone will incrementally update the original baseline using a three-way comparison (baseline, source state, destination state).

To create the original baseline, run rclone with the following flags:

rclone bisync gdrive:data/ sftptogo:data/ \
  --checksum \
  --resync \
  --dry-run \
  --verbose

If the command completes without errors, repeat it without --dry-run. On every recurring run afterwards, run it without --resync: that’s the exact flag in charge of establishing a fresh baseline instead of doing a normal three-way comparison (baseline vs source vs destination).

How do I sync Google documents, spreadsheets, and slides?

These documents are special-case files that need to be treated differently, so rclone does not sync them directly. Instead, it triggers the conversion of these documents to other file formats and then copies or syncs the exported files. By default, rclone uses .docx, .xslx, and .pptx for exports. You can change that with the --drive-export-formats flag like this:

rclone sync gdrive:reports/ sftptogo:reports/ --drive-export-formats ods,odt,odp

If you prefer PDF files of everything in exports, adjust the flags accordingly:

rclone sync gdrive:reports/ sftptogo:reports/ --drive-export-formats pdf

Protecting existing files

By default, rclone overwrites existing files when syncing remotes. This may be in conflict with compliance rules where files already logged to an SFTP server should stay intact at all times. Rclone has two flags that help you deal with this scenario: --immutable and --ignore-existing.

Both flags protect pre-existing files from being updated on the destination remote when you use sync, copy, or move commands. The difference is that --immutable throws an error while not overwriting files, and --ignore-existing does the same silently.

Please note that neither of the two flags should be used with bisync. --immutable throws a hard error and aborts the sync whenever an existing file needs updating. --ignore-existing silently blocks modifications while incorrectly marking those files as updated in the .lst baselines, which causes synchronization drift. If you are lucky enough to catch that early, you can fix it with --resync on the next run to reconstruct the baselines.

Working around missing S3 timestamps

SFTP To Go is built on top of the AWS infrastructure, including S3 storage that has a caveat: folders don’t have real timestamps. Since S3 doesn’t have true directories, any folder shown on SFTP To Go has zero UNIX time (January 1, 1970) instead of a meaningful creation or modification date. 

Files themselves do get a real timestamp, but it reflects when the file was uploaded, not when it was originally created. So a file created on January 1, 2000 but uploaded on September 14, 2026 will show the latter. This can mess up bi-directional syncs in cases when remote files have been overwritten. To work around that, you can employ one of rclone’s mechanisms to compare files where timestamps are not reliable:

• When you use the --checksum flag, rclone will calculate and compare hashes for files with matching names and locations.
• When you use the --size-only flag, rclone will compare file sizes to determine whether a file on one of the remotes has changed.

Both methods have their pros and cons. 

Using checksums is precise: even if you change one digit in a CSV file, the file size will be the same, but the checksum will change because the content has changed. However, the checksum calculation takes time.

Using filesize is fast: but it’s less precise and will fail in the same situation where content has changed, but the file size hasn’t.

Wrapping up

Rclone shines when you need a fast, scriptable command-line tool that runs on any operating system and bridges almost any cloud storage platform. It’s efficient, reliable, and has great documentation.

With the workflow in this guide, you now have a solid framework for keeping Google Drive and SFTP To Go in sync. Ready to simplify your file transfer setup even further? Read our migration guide to learn how a managed SFTP server can streamline your team's workflow. 

Frequently asked questions

rclone config update gdrive root_folder_id "YOUR_FOLDER_ID_HERE"

rclone config update gdrive scope "drive.appfolder"

Total:   15 GiB
Used:    6.636 GiB
Free:    3.676 GiB
Trashed: 1 KiB
Other:   4.688 GiB