> ## Content Index > Fetch the complete content index at: https://snubmonkey.com/llms.txt > Use this file to discover other available public pages before exploring further. # rclone: One Tool to Sync Them All β€” Google Drive, Nextcloud & More. - URL: https://snubmonkey.com/rclone-one-tool-to-sync-them-all-google-drive-nextcloud-more/ - Published: 2026-09-17T00:56:48.000Z - Updated: 2026-09-17T00:56:48.000Z - Description: rclone brings cloud storage into the Linux command line, making it easy to copy, sync, automate, and manage files across services such as Google Drive and self-hosted Nextcloud. - Author: SNUBmonkeyteam - Tags: how to πŸͺ„, security 🦾🦿, linux 🐧, rclone **Cloud storage** is convenient, no doubt. But managing files across multiple providers can quickly become complicatedβ€”and annoying. You might have a **Google Drive** account for personal storage, a **self-hosted Nextcloud** instance for private data, and a Linux server containing production files that need to be backed up. Do you really need a different application for each one? **Not necessarily.** Meet **`rclone`**. Often described as **β€œrsync for cloud storage,”** `rclone` is a command-line utility that supports a wide range of cloud and remote-storage providers. It brings familiar Linux file-management conceptsβ€”**copying, syncing, checking, filtering, and automation**β€”to a broad range of storage backends. And for Linux administrators, that makes `rclone` particularly interesting. # **What Is rclone?** **Rclone** is an open-source command-line program designed to manage files on local and remote storage. The concept is simple: ``` Local filesystem β”‚ β–Ό rclone β”‚ β”œβ”€β”€ Google Drive β”œβ”€β”€ Nextcloud β”œβ”€β”€ S3 β”œβ”€β”€ Dropbox β”œβ”€β”€ OneDrive └── many other backends ``` Instead of learning a completely different tool for every storage provider, you can use the same rclone commands and concepts. For example: ``` $ rclone ls remote: ``` or ``` rclone copy /var/www/DIR remote:DIR ``` The `remote:` part is simply a name you assign to a configured storage destination. # **Why Is rclone Useful?** One of the biggest advantages of `rclone` is **automation**. A graphical cloud-storage application is convenient when you want to manually move a few files. A Linux server, however, may need to perform storage operations automatically and without a graphical interface. For example, a server might need to: - Back up a website every night - Copy production data to another server - Synchronize directories - Upload large media collections - Maintain an off-site backup - Move data between cloud providers - Run scheduled backups with `cron` or `systemd` - Operate entirely from the command line That's where `rclone` becomes particularly useful. You can build workflows such as: ``` Production Server β”‚ β–Ό rclone β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Ί Google Drive β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Ί Self-hosted Nextcloud β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Ί iCloud Drive β”‚ └──────────────► S3 ``` You can also use filters to exclude files and directories that don't need to be transferred: ``` --exclude '/node_modules/**' --exclude '/content/logs/**' ``` This can be particularly useful for applications such as **Ghost**, where dependencies, caches, logs, and other generated or rebuildable data may not need to be included in a disaster-recovery backup. The important part is to **define what your recovery process actually requires**. If something can be reliably regenerated or restored from another source, excluding it can reduce backup size, transfer time, and complexity. If it cannot, it belongs in your backup strategy. # **rclone vs. rsync** The names can be confusing, but their primary use cases help distinguish them. [**rsync**](https://snubmonkey.com/rsync-command-in-linux/) is primarily designed to synchronize files and directories between **local filesystems and remote Linux/Unix systems**, commonly over SSH. For example: ``` $ rsync -av /var/www/DIR/ /backup/www/DIR/ ``` Or to another Linux server over SSH: ``` $ rsync -av /var/www/DIR/ user@server:/backup/www/DIR/ ``` `rclone` provides a similar file-management and synchronization model for a much broader range of **cloud storage and remote storage services**. For example: ``` $ rclone copy /var/www/ remote:backup/ ``` The key difference is often the **type of storage backend you're connecting to**. With **`rsync`**, you might copy files to another Linux filesystem, either locally or on another server over **SSH**. With **`rclone`**, the destination could be **Google Drive, Nextcloud, Amazon S3**, or one of many other supported storage backends. In simple terms: ``` rsync β†’ Filesystems / Linux servers rclone β†’ Cloud / object / remote storage backends ``` There is some overlap between the two, but they are built around different ecosystems and use cases. # **Setting Up rclone** On Debian and Ubuntu, you can install `rclone` using the system package manager: ``` $ sudo apt update $ sudo apt install rclone ``` Verify the installation: ``` $ rclone version ``` Once installed, configure your first remote: ``` $ rclone config ``` `rclone` will present an interactive configuration interface where you can create and configure remote storage connections. One of the most important concepts to understand is the **remote name**. For example: ``` gdrive: nextcloud: ``` These names are **arbitrary**. They are simply labels you assign to your configured remotes and can be named whatever makes sense for your infrastructure. For example: ``` google: cloud: backup: ``` You would then reference the remote by that name when using `rclone`: ``` $ rclone ls gdrive: $ rclone ls nextcloud: ``` The name itself does not determine which storage provider is usedβ€”the remote's configuration does. # **Google Drive** Google Drive is one of the most common use cases for `rclone`, making it a practical option for managing data between a Linux system and cloud storage. Start by opening the configuration interface: ``` $ rclone config ``` Create a new remote: ``` n) New remote ``` Give the remote a name, such as: ``` gdrive ``` or choose any name that makes sense for your infrastructure. Then select **Google Drive** from the available storage providers. `rclone` will guide you through the **authentication process** and the remaining configuration options. Once configured, test the connection: ``` $ rclone lsd gdrive: ``` This lists the **directories available at the root** of the configured Google Drive remote. You can also list files: ``` $ rclone ls gdrive: ``` This recursively lists files on the configured Google Drive remote along with their sizes. Or copy a directory: ``` $ rclone copy /var/www/DIR gdrive:DIR ``` This copies the contents of `/var/www/DIR` to the `DIR` directory on the configured Google Drive remote while leaving the source files untouched. As always, the remote name and destination path are determined by how you configured the remote. In this example, `gdrive:` refers to the Google Drive remote created earlier. # `copy` **vs.** `sync` This distinction is **extremely important** when using `rclone`. ### **`rclone copy`** ``` $ rclone copy SOURCE DESTINATION ``` Copies files from the **source** to the **destination** while leaving the source untouched. Existing files at the destination are updated when necessary, but files that exist only at the destination are **not deleted** simply because they are absent from the source. This makes `copy` useful for many backup scenarios where you want to add or update files without removing existing data from the destination. ### **`rclone sync`** ``` $ rclone sync SOURCE DESTINATION ``` Makes the **destination match the source** by copying new and changed files and deleting files from the destination when they no longer exist in the source. For example, if `important.txt` exists on the destination but has been removed from the source, a `sync` operation can also remove `important.txt` from the destination. Use `sync` carefully, particularly when the destination contains data that you cannot easily restore. In other words: ``` copy Source ─────────► Destination add/update sync Source ═════════► Destination mirror ``` Neither operation is inherently the right choice for every backup strategy. The important question is **what behavior you want from the destination**. For disaster-recovery backups, understand this distinction before using `sync` and consider testing the command with `--dry-run` first. # **Self-Hosted Nextcloud** `rclone` can work with a **self-hosted Nextcloud installation** through **WebDAV (Web Distributed Authoring and Versioning)**. WebDAV is an extension of HTTP/HTTPS that allows users and applications to **access, upload, modify, move, and manage files on a remote server** through a filesystem-like interface. This is particularly useful when you want your Linux server to push backups to **storage that you control** rather than relying exclusively on a third-party cloud provider. Again, start with: ``` $ rclone config ``` Create a **new remote** and select the **WebDAV** backend. You will typically provide your **Nextcloud WebDAV endpoint** along with the required authentication credentials. A typical WebDAV endpoint has a structure similar to: **Via IP address:** ``` http://192.168.1.100/remote.php/dav/files/USERNAME/ ``` **Via a custom domain:** ``` https://cloud.example.com/remote.php/dav/files/USERNAME/ ``` The exact URL depends on your Nextcloud installation, configuration, and account. Once configured, test the connection: ``` $ rclone lsd nextcloud: ``` If everything is working, you can copy data to your Nextcloud remote: ``` $ rclone copy /var/www/DIR nextcloud:DIR ``` Or synchronize the destination with the source: ``` $ rclone sync /var/www/DIR nextcloud:DIR ``` **Remember:** `copy` adds or updates files without deleting existing destination files, while `sync` can delete files from the destination that no longer exist in the source. Use `--dry-run` (see below) when testing a `sync` operation. # **Encryption: Transport vs. Data-at-Rest** When using `rclone`, it is important to distinguish between **transport encryption** and **data encryption**. The encryption used during transfer depends on the storage backend. For example, an **SFTP** remote uses **SSH**, while HTTPS-based services such as Google Drive and WebDAV/Nextcloud use **TLS**: ``` SFTP β†’ SSH HTTPS/WebDAV β†’ TLS Google Drive β†’ HTTPS/TLS ``` This protects data while it is traveling between your Linux system and the remote storage service. But what about the data **after it reaches the destination**? That's where `rclone crypt` comes in. ## **Client-Side Encryption with rclone crypt** `rclone crypt` provides an additional encryption layer by encrypting files **before they are uploaded to the remote**. ``` Linux Server β”‚ β–Ό rclone β”‚ β”‚ encrypt β–Ό Remote Storage β”‚ β–Ό Encrypted Data ``` This means the remote storage provider receives the encrypted data rather than the original files. For example, you could use `rclone crypt` with a Google Drive, S3, or other supported remote to provide client-side encryption for the data stored there. The important distinction is: > **TLS or SSH protects data in transit. `rclone crypt` protects the data itself on the remote storage.** These mechanisms solve different problems and can be used together. # **Filtering** This is where `rclone` becomes particularly powerful. You don't necessarily need to back up **everything** on a server. Production applications often contain data that can be regenerated or reinstalled, such as: ``` node_modules/ logs/ cache/ temporary files/ package caches/ old application versions/ ``` Depending on your recovery strategy, some of these files may be **rebuildable and unnecessary to include in a backup**. For example: ``` rclone copy /var/www/DIR nextcloud:DIR \ --exclude '/versions/**' \ --exclude '/node_modules/**' \ --exclude '/.pnpm-store/**' \ --exclude '/tools/**' \ --exclude '/content/logs/**' ``` With these filters, `rclone` skips the specified paths during the copy operation. Using exclusions can significantly reduce: - **Storage consumption** - **Transfer time** - **Number of files** - **Network traffic** - **Backup complexity** The important part is deciding **what your recovery actually requires**. Don't exclude something simply because it *looks* temporary or rebuildableβ€”verify that you can reconstruct it from another source before leaving it out of the backup. The principle is simple: > **Back up what you need to restoreβ€”not necessarily everything that happens to exist on the server.** # **Performance: More Is Not Always Faster** `rclone` provides several options for controlling concurrency and optimizing performance, including: ``` --transfers 8 --checkers 16 ``` You can increase these values: ``` --transfers 100 --checkers 50 ``` But **higher values do not automatically mean better performance**. Each option controls a different part of the operation. ### **`--transfers`** Controls the number of file transfers that can run concurrently. ``` --transfers 8 ``` allows up to **eight file transfers** to run simultaneously. ### **`--checkers`** Controls the number of concurrent checking operations. ``` --checkers 16 ``` allows `rclone` to perform more file and directory checks concurrently while determining what needs to be transferred. ### **`--fast-list`** ``` --fast-list ``` changes how `rclone` performs directory listings and can improve performance when working with large numbers of files. The trade-off is **higher memory usage**, because `rclone` may need to hold more directory information in memory. Depending on the workload, CPU usage can also increase. Your environment matters. **RAM, CPU, network bandwidth and latency, storage performance, and the remote provider** can all affect the optimal settings. Don't assume: ``` 32 transfers > 8 transfers ``` More concurrency can actually make a cloud or WebDAV transfer **slower** if the remote server, storage subsystem, network connection, or provider API becomes the bottleneck. The practical approach is to **start conservatively, measure performance, and increase concurrency gradually**. The optimal settings depend on the workload and the systems involved. # **rclone Is More Than a Backup Tool** Although backups are one of the most common uses for `rclone`, the tool goes far beyond simply copying data. You can use `rclone` to: ``` rclone copy >> Copy files from the source to the destination. Files remain at the source. rclone sync >> Synchronize the destination with the source. Files removed from the source may also be removed from the destination. rclone move >> Move files from the source to the destination. Successfully transferred files are removed from the source. rclone delete >> Delete files from the specified remote or path. rclone check >> Compare the source and destination to verify that files match. rclone ls >> List files on a remote, including their sizes. rclone lsd >> List directories on a remote. ``` ## **⚠️ Important** `sync`, `move`, and especially `delete` can **remove data**. Before running any destructive operation, make sure you understand exactly what `rclone` will change. When in doubt, use `--dry-run` first: ``` $ rclone sync SOURCE: DESTINATION: --dry-run ``` Think of `--dry-run` as your safety check: it shows what `rclone` *would* do without actually making the changes. ### **Mount Remote Storage** You can also mount supported remote storage as a filesystem, making it accessible through a local mount point: ``` $ rclone mount REMOTE: /local/mountpoint ``` This opens up useful possibilities for **Linux servers, development environments, media systems, and automation**, allowing applications and users to access remote storage through a familiar filesystem interface. ### **Remote β†’ Local** And remember: **rclone works both ways**β€”you can copy or sync **local β†’ remote** or **remote β†’ local**: ``` $ rclone copy REMOTE:DIR /local/DIR ``` This is useful when **restoring data from remote storage to your local system**, whether for a routine restore, migration, or disaster recovery. # **Automating Backups** Once configured, you can automate `rclone` operations using simple scripts or scheduled tasks. - **Cron Jobs (Basic):** For quick, lightweight setups, schedule background syncs directly using `crontab -e`. - **Systemd Timers (Recommended):** For production or more robust systems, use `systemd` timers for better logging, dependency management, and process control. For example, you could schedule a nightly backup: ``` 02:00 β”‚ β–Ό Backup script β”‚ β–Ό rclone β”‚ β”œβ”€β”€β–Ί Nextcloud └──► Google Drive ``` This elevates **rclone** from a simple file-copy utility into a fully automated component of your infrastructure backup strategy. # **Security Considerations** `rclone` can handle credentials and authenticated remote storage, so treat its configuration as sensitive. Protect your rclone configuration: ``` $ rclone config file ``` Restrict access to the configuration file and avoid exposing credentials in shell history, scripts, command-line arguments, or logs whenever possible. ### **TLS Certificate Verification** Be particularly careful with options that weaken TLS security, such as: ``` --no-check-certificate ``` This disables TLS certificate verification. Although it can be useful when connecting to a **self-hosted service using a self-signed certificate**, it removes an important part of TLS: verifying that you are actually communicating with the intended server. It should therefore **not be used casually**, especially when connecting to services over an untrusted network or the public Internet. If a self-signed certificate is required, the preferred approach is to **properly trust the certificate or configure a certificate signed by a trusted CA** rather than disabling verification. A trusted network or VPN can provide an additional layer of protection, but it **does not replace TLS certificate verification** and should not be treated as a justification for routinely using `--no-check-certificate`. Security should be treated as an integral part of your backup designβ€”not something added after the storage and transfer mechanisms have been configured. ## **Supported Storage Types β€” As of This Writing** `rclone` supports a vast and continually expanding range of storage backends, from traditional cloud storage and object storage to SFTP servers, WebDAV, and other remote storage services, including: ``` 1 / 1Fichier >> Cloud file storage 2 / Akamai NetStorage >> Enterprise cloud storage 3 / Alias >> Alias for an existing remote 4 / Amazon S3 / S3-compatible >> Object storage 5 / Backblaze B2 >> Cloud object storage 6 / Better checksums >> Improved checksum support 7 / Box >> Cloud file storage 8 / Cache >> Cache a remote 9 / Citrix ShareFile >> Business file sharing 10 / Cloudinary >> Media storage and delivery 11 / Combine >> Combine multiple remotes 12 / Compress >> Compress a remote 13 / DOI datasets >> Research datasets 14 / Dropbox >> Cloud file storage 15 / Encrypt/Decrypt >> Encrypt or decrypt a remote 16 / Enterprise File Fabric >> Enterprise file storage 17 / FTP >> File Transfer Protocol 18 / FileLu >> Cloud file storage 19 / Files.com >> Managed file storage 20 / Gofile >> File-sharing cloud storage 21 / Google Cloud Storage >> Google object storage 22 / Google Drive >> Cloud file storage 23 / Google Photos >> Photo and video storage 24 / HTTP >> HTTP-based remote files 25 / Hadoop HDFS >> Distributed filesystem 26 / HiDrive >> Cloud file storage 27 / ImageKit.io >> Image and media storage 28 / In-memory >> Temporary memory-based storage 29 / Internet Archive >> Digital archive storage 30 / Jottacloud >> Cloud file storage 31 / Koofr >> Cloud file storage 32 / Linkbox >> Cloud file storage 33 / Local Disk >> Local filesystem 34 / Mail.ru Cloud >> Cloud file storage 35 / Mega >> Encrypted cloud storage 36 / Microsoft Azure Blob >> Object storage 37 / Microsoft Azure Files >> Cloud file shares 38 / Microsoft OneDrive >> Cloud file storage 39 / OpenDrive >> Cloud file storage 40 / OpenStack Swift >> Object storage 41 / Oracle Cloud Object Storage >> Cloud object storage 42 / pCloud >> Cloud file storage 43 / PikPak >> Cloud file storage 44 / Pixeldrain >> File storage and sharing 45 / Proton Drive >> Privacy-focused cloud storage 46 / Put.io >> Cloud file storage 47 / QingCloud Object Storage >> Cloud object storage 48 / Quatrix >> Managed file transfer 49 / SMB / CIFS >> Windows/network file sharing 50 / SSH / SFTP >> Secure remote file transfer 51 / Sia >> Decentralized cloud storage 52 / Storj >> Decentralized object storage 53 / SugarSync >> Cloud file synchronization 54 / Chunker >> Split large files into chunks 55 / Uloz.to >> Cloud file storage 56 / Union >> Merge multiple remotes 57 / Uptobox >> Cloud file storage 58 / WebDAV >> WebDAV-compatible storage 59 / Yandex Disk >> Cloud file storage 60 / Zoho >> Cloud file storage 61 / iCloud Drive >> Apple's cloud file storage 62 / premiumize.me >> Cloud-based file storage 63 / Seafile >> Self-hosted/cloud file synchronization ``` `rclone` is one of those Linux tools that becomes increasingly valuable as your infrastructure growsβ€”a powerful CLI for moving, syncing, automating, and managing data across local, remote, and cloud storage. Thanks for stopping by. If this guide helped, share it with a fellow Linux enthusiast, sysadmin, or developer. 😎 **Keep learning.** **Keep experimenting.** **Keep building.**