Rclone 将你的文件同步到云存储
Rclone 被强调为一个多功能命令行工具，能够在几十种云存储服务商之间同步、复制和挂载数据，常常成为 rsync、sshfs 或厂商专用客户端之外更灵活的替代方案。评论者称赞它的可靠性、校验和验证、客户端加密，以及支持异地备份、云到云传输、临时 FTP 服务器和通过 FUSE 挂载远程存储等工作流，有时还会与 Restic 或 Borg 等工具配合使用。其局限包括对稳定网络的依赖、若不额外配置则缺乏真正实时的双向同步（例如 bisync）、以及一些边缘粗糙或缺乏维护的功能，但许多人仍将其视为个人和专业数据管理中的“顶级工具”。
核心能力和使用场景
- Rclone 被广泛赞誉为文件领域的“瑞士军刀”：
- 在本地文件系统与许多云服务商之间同步/复制/移动。
- 通过 FUSE 将云端或远程存储挂载为本地文件系统。
- 通过 FTP（以及其他协议）向传统设备和内网提供远程存储服务。
- 使用
rclone ncdu和“通用”文件浏览器来查看云端占用情况。
- 常见的实际用途：
- 家庭和小型办公室将数据备份到 S3/Glacier、Backblaze B2、rsync.net 等。
- 在服务器上进行跨云迁移（例如 GDrive ↔ S3 ↔ OneDrive）。
- 在某些工作流中替代用于远程挂载的 sshfs。
- 在局域网中或向只支持 FTP 的设备公开 Dropbox/其他云存储。
备份 vs 同步与双向同步
- 许多人强调，rclone 本身并不是完整的备份系统；它更像是“适用于许多后端的 rsync”。
- 提到的合适备份工具包括：Restic、Borg、Kopia、Duplicacy、Syncthing、Unison、borgmatic。
- 常见模式：用 Restic 或 Borg 做带版本和加密的备份；再用 rclone 将仓库推送到便宜的云存储。
- Rclone 的
sync是单向的，并且按设计会删除多余文件。 - Rclone 提供了用于双向同步的
rclone bisync，但它是批处理式的，不是实时的；它是否适合复杂的多设备/多云环境仍不明确。
加密与安全
- Rclone 的
crypt后端可在任意存储后端之上提供客户端加密（从用户视角看是 e2e）。 - 在服务商缺乏原生端到端加密时，这一点很有吸引力。
- 有些人将其与服务商侧方案进行对比，例如 S3 基于 SDK 的客户端加密。
- 讨论中提到，将 rclone 与不可变/仅追加的桶结合使用，可以强化备份方案。
可靠性、性能与限制
- 总体上被认为非常稳定，即使在大规模场景下也是如此（多 PB 迁移、多 TB 备份）。
- 优势：
- 能恢复中断的传输；同一命令很容易重新运行。
- 默认进行校验和验证，被视为重要的安全特性。
- 缺点 / 痛点：
- 当网络消失时，挂载可能卡住；超时不一定能干净地恢复。
- 一些后端/功能被标为实验性或维护不充分。
- 作为 FUSE 挂载驱动时，面对大量小文件会比较慢。
生态、API 与支持
- Rclone 主要使用各服务商的官方 API（通常兼容 S3）；部分后端是通过逆向工程实现的。
- 有一家存储服务商将 rclone 直接集成到其环境中。
- 关于服务商是否提供“官方支持”存在争论；许多用户把 rclone 视为对各种不断演变的 API 进行抽象的务实层。
工具与部署
- 常见模式：
- 一些人建议通过 systemd 守护进程化，而不是使用 cron/nohup，以提升稳健性和安全性。
- 在无头服务器上配合 tmux/screen 使用，便于监控。
- 存在实验性的 Web UI 和第三方 GUI（例如 RcloneBrowser），但它们的维护可能没有那么活跃。
- 一些人希望有更好的移动端/iOS 工作流以及更精致的 GUI 选项。