"rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files
azure-blobazure-blob-storageazure-filesbackblaze-b2cloud-storagedropboxencryptionftpfuse-filesystemgogolanggoogle-cloud-storagegoogle-driveonedriveopenstack-swiftrclones3sftpsyncwebdav
4025f42bd9
Before this change, bisync had no mechanism to gracefully cancel a sync early and exit in a clean state. Additionally, there was no way to recover on the next run -- any interruption at all would cause bisync to require a --resync, which made bisync more difficult to use as a scheduled background process. This change introduces a "Graceful Shutdown" mode and --recover flag to robustly recover from even un-graceful shutdowns. If --recover is set, in the event of a sudden interruption or other un-graceful shutdown, bisync will attempt to automatically recover on the next run, instead of requiring --resync. Bisync is able to recover robustly by keeping one "backup" listing at all times, representing the state of both paths after the last known successful sync. Bisync can then compare the current state with this snapshot to determine which changes it needs to retry. Changes that were synced after this snapshot (during the run that was later interrupted) will appear to bisync as if they are "new or changed on both sides", but in most cases this is not a problem, as bisync will simply do its usual "equality check" and learn that no action needs to be taken on these files, since they are already identical on both sides. In the rare event that a file is synced successfully during a run that later aborts, and then that same file changes AGAIN before the next run, bisync will think it is a sync conflict, and handle it accordingly. (From bisync's perspective, the file has changed on both sides since the last trusted sync, and the files on either side are not currently identical.) Therefore, --recover carries with it a slightly increased chance of having conflicts -- though in practice this is pretty rare, as the conditions required to cause it are quite specific. This risk can be reduced by using bisync's "Graceful Shutdown" mode (triggered by sending SIGINT or Ctrl+C), when you have the choice, instead of forcing a sudden termination. --recover and --resilient are similar, but distinct -- the main difference is that --resilient is about _retrying_, while --recover is about _recovering_. Most users will probably want both. --resilient allows retrying when bisync has chosen to abort itself due to safety features such as failing --check-access or detecting a filter change. --resilient does not cover external interruptions such as a user shutting down their computer in the middle of a sync -- that is what --recover is for. "Graceful Shutdown" mode is activated by sending SIGINT or pressing Ctrl+C during a run. Once triggered, bisync will use best efforts to exit cleanly before the timer runs out. If bisync is in the middle of transferring files, it will attempt to cleanly empty its queue by finishing what it has started but not taking more. If it cannot do so within 30 seconds, it will cancel the in-progress transfers at that point and then give itself a maximum of 60 seconds to wrap up, save its state for next time, and exit. With the -vP flags you will see constant status updates and a final confirmation of whether or not the graceful shutdown was successful. At any point during the "Graceful Shutdown" sequence, a second SIGINT or Ctrl+C will trigger an immediate, un-graceful exit, which will leave things in a messier state. Usually a robust recovery will still be possible if using --recover mode, otherwise you will need to do a --resync. If you plan to use Graceful Shutdown mode, it is recommended to use --resilient and --recover, and it is important to NOT use --inplace, otherwise you risk leaving partially-written files on one side, which may be confused for real files on the next run. Note also that in the event of an abrupt interruption, a lock file will be left behind to block concurrent runs. You will need to delete it before you can proceed with the next run (or wait for it to expire on its own, if using --max-lock.) |
||
|---|---|---|
| .github | ||
| backend | ||
| bin | ||
| cmd | ||
| cmdtest | ||
| contrib | ||
| docs | ||
| fs | ||
| fstest | ||
| graphics | ||
| lib | ||
| librclone | ||
| vfs | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yml | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| MAINTAINERS.md | ||
| Makefile | ||
| MANUAL.html | ||
| MANUAL.md | ||
| MANUAL.txt | ||
| notes.txt | ||
| rclone.1 | ||
| rclone.go | ||
| README.md | ||
| RELEASE.md | ||
| VERSION | ||
Website | Documentation | Download | Contributing | Changelog | Installation | Forum
Rclone
Rclone ("rsync for cloud storage") is a command-line program to sync files and directories to and from different cloud storage providers.
Storage providers
- 1Fichier 📄
- Akamai Netstorage 📄
- Alibaba Cloud (Aliyun) Object Storage System (OSS) 📄
- Amazon S3 📄
- ArvanCloud Object Storage (AOS) 📄
- Backblaze B2 📄
- Box 📄
- Ceph 📄
- China Mobile Ecloud Elastic Object Storage (EOS) 📄
- Cloudflare R2 📄
- Citrix ShareFile 📄
- DigitalOcean Spaces 📄
- Digi Storage 📄
- Dreamhost 📄
- Dropbox 📄
- Enterprise File Fabric 📄
- Fastmail Files 📄
- FTP 📄
- Google Cloud Storage 📄
- Google Drive 📄
- Google Photos 📄
- HDFS (Hadoop Distributed Filesystem) 📄
- HiDrive 📄
- HTTP 📄
- Huawei Cloud Object Storage Service(OBS) 📄
- ImageKit 📄
- Internet Archive 📄
- Jottacloud 📄
- IBM COS S3 📄
- IONOS Cloud 📄
- Koofr 📄
- Leviia Object Storage 📄
- Liara Object Storage 📄
- Linkbox 📄
- Linode Object Storage 📄
- Mail.ru Cloud 📄
- Memset Memstore 📄
- Mega 📄
- Memory 📄
- Microsoft Azure Blob Storage 📄
- Microsoft Azure Files Storage 📄
- Microsoft OneDrive 📄
- Minio 📄
- Nextcloud 📄
- OVH 📄
- Blomp Cloud Storage 📄
- OpenDrive 📄
- OpenStack Swift 📄
- Oracle Cloud Storage 📄
- Oracle Object Storage 📄
- ownCloud 📄
- pCloud 📄
- Petabox 📄
- PikPak 📄
- premiumize.me 📄
- put.io 📄
- Proton Drive 📄
- QingStor 📄
- Qiniu Cloud Object Storage (Kodo) 📄
- Quatrix 📄
- Rackspace Cloud Files 📄
- RackCorp Object Storage 📄
- Scaleway 📄
- Seafile 📄
- SeaweedFS 📄
- SFTP 📄
- SMB / CIFS 📄
- StackPath 📄
- Storj 📄
- SugarSync 📄
- Synology C2 Object Storage 📄
- Tencent Cloud Object Storage (COS) 📄
- Wasabi 📄
- WebDAV 📄
- Yandex Disk 📄
- Zoho WorkDrive 📄
- The local filesystem 📄
Please see the full list of all storage providers and their features
Virtual storage providers
These backends adapt or modify other storage providers
- Alias: rename existing remotes 📄
- Cache: cache remotes (DEPRECATED) 📄
- Chunker: split large files 📄
- Combine: combine multiple remotes into a directory tree 📄
- Compress: compress files 📄
- Crypt: encrypt files 📄
- Hasher: hash files 📄
- Union: join multiple remotes to work together 📄
Features
- MD5/SHA-1 hashes checked at all times for file integrity
- Timestamps preserved on files
- Partial syncs supported on a whole file basis
- Copy mode to just copy new/changed files
- Sync (one way) mode to make a directory identical
- Bisync (two way) to keep two directories in sync bidirectionally
- Check mode to check for file hash equality
- Can sync to and from network, e.g. two different cloud accounts
- Optional large file chunking (Chunker)
- Optional transparent compression (Compress)
- Optional encryption (Crypt)
- Optional FUSE mount (rclone mount)
- Multi-threaded downloads to local disk
- Can serve local or remote files over HTTP/WebDAV/FTP/SFTP/DLNA
Installation & documentation
Please see the rclone website for:
Downloads
License
This is free software under the terms of the MIT license (check the COPYING file included in this package).