Configure rclone for Google Drive Without Slowing Transfers

Updated 9 November 2026 · Standard formula, shown below

Configure rclone for Google Drive by choosing sensible transfer and concurrency settings, then test them on a small folder before syncing a large library. This guide is for people setting up a new remote or tuning an existing one; the aim is to avoid unnecessary slowdowns without sacrificing reliability.

What You’ll Need

rclone installed on the computer or server that will transfer files.
A Google account with access to the Drive files you need.
A terminal or command prompt, plus a stable internet connection.
Enough local disk space if you plan to use a disk-based cache or stage files locally.

Step-by-Step

Check rclone and your connection. Run rclone version to confirm it is available. Update to a current rclone release if yours is old, using the installation method for your operating system. Before tuning rclone, check that your connection is not already saturated by another upload, VPN, backup, or Wi-Fi issue. A speed test can help, but it does not guarantee the same speed to Drive.
Create or verify a Google Drive remote. Run rclone config, choose to create a new remote, give it a clear name such as gdrive, and select Google Drive as the storage type. Follow the browser sign-in and authorization prompts. For a shared drive, answer the shared-drive question and select the correct drive. Avoid sharing your token or configuration file; it contains credentials. If a remote already works, do not recreate it just to change transfer settings.
Confirm the remote can read Drive. Run rclone lsd gdrive: and check that expected folders appear. Replace gdrive with your remote name. For a shared drive, verify you are listing the intended drive rather than your personal Drive. Resolve authorization or path issues before measuring transfer performance.
Start with conservative, direct settings. For a typical upload, try rclone copy /path/to/folder gdrive:Backup --progress --transfers 4 --checkers 8. For a download, put the remote path first, for example rclone copy gdrive:Backup /path/to/folder --progress --transfers 4 --checkers 8. --transfers controls simultaneous file transfers; --checkers controls parallel checks. These are starting points, not universal speed settings. Keep the source and destination paths precise, and use copy for an initial test because it does not delete extra destination files.
Test a representative batch. Copy a small selection that includes the file sizes and types you normally handle. Watch the progress display and the machine’s CPU, disk activity, and network use. Increase --transfers in small steps, such as from 4 to 6, only if the connection and system have spare capacity and overall throughput improves. If speed falls, errors rise, or the machine becomes unresponsive, return to the previous value.
Use the right tool for the bottleneck. Many small files can be limited by listing, metadata checks, or API request overhead rather than bandwidth. A moderate increase in --checkers may help, but very high concurrency can add load and provoke throttling. Large files may use chunked transfers; test rclone’s default behavior before changing chunk settings. Avoid adding a bandwidth cap unless you deliberately need to leave capacity for other tasks.
Choose copy or sync deliberately. Use rclone copy to add or update files without removing destination-only files. Use rclone sync only when you want the destination to match the source; it can delete files from the destination. For a planned sync, first run the same command with --dry-run and review what rclone would change. Once the test is sound, save the working settings in your script or scheduled task.

Common Mistakes

Setting concurrency as high as possible: More simultaneous work does not always mean more speed. It can overload a small device, compete with other traffic, or trigger Google API limits.
Assuming every slow transfer is an rclone problem: Wi-Fi, disk speed, CPU limits, other network users, and Google-side processing can all affect throughput.
Using sync for a first test: Sync can delete destination files that are not present at the source. Start with copy or use --dry-run.
Changing several flags at once: If performance changes, you will not know which setting caused it. Adjust one variable per test and compare similar file sets.
Confusing checks with transfers: A job with many small files may spend time checking names and metadata even when its displayed transfer count is low.

Tips

Keep a record of the exact command and the approximate number and size of files in each test. Compare total completion time, not a brief speed fluctuation.
Use a wired connection where practical, and pause unrelated uploads or backups during a controlled test.
For recurring jobs, keep flags in a script or configuration you can review. Avoid copying example paths without replacing them with the paths you intend to use.
Do not set a fixed bandwidth limit unless you need one. If using --bwlimit, remember that it intentionally caps transfer rate.
Use --log-level INFO --log-file /path/to/rclone.log when you need a record of a run. Protect logs and configuration files, and remove sensitive material before sharing diagnostic output.

Troubleshooting

If transfers are slow, first determine whether the bottleneck is the network, disk, CPU, or file pattern. Test one large file and a batch of small files separately. If one large file is slow too, check network conditions, other traffic, and local disk activity. If large files move well but small files do not, metadata and request overhead may be the limiting factor; try a modest checker adjustment rather than sharply raising transfers.

If increasing --transfers makes the job slower or causes errors, lower it and retry. Repeated API or rate-limit messages usually call for reducing concurrency and allowing retries to complete, not adding more parallel requests. If rclone reports authorization errors, rerun rclone config to reauthorize the remote, then confirm the account still has access to the folder or shared drive. If the command cannot find a path, list the remote with rclone lsd gdrive: and correct the remote name or folder spelling. For a sync that proposes unexpected deletions, stop it, run --dry-run, and verify both source and destination before proceeding.

Frequently Asked Questions

What is a good starting value for --transfers?
Try 4 for an ordinary connection, then compare small increases on a representative batch. The best value depends on the connection, files, and device.

Should I increase --checkers too?
Only if metadata or file-list checking appears to be the bottleneck. Start around 8, then test a modest change; more checkers can add API load.

Does --drive-chunk-size make uploads faster?
Not automatically. Larger chunks can change memory use and retry costs, and benefits depend on the workload. Leave the default unless you have a specific reason and can test safely.

Will a cache improve transfer speed?
A cache is mainly useful for certain access patterns, such as repeated reads or mount behavior. It is not a general speed boost for a straightforward copy or sync, and it uses local storage.

Can I run multiple rclone jobs at once?
You can, but they compete for bandwidth, disk, and API capacity. One job with measured concurrency is often easier to tune; run separate jobs only when the workload benefits and the system has capacity.

How do I safely test a sync?
Run the intended command with --dry-run first and inspect the proposed changes. Confirm the source and destination are correct before running it without the flag.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.