rclone mount vs rclone bisync after Dropbox: the real latency, RAM and conflict numbers
Description and use
Replace Dropbox client by running rclone bisync for daily working files and rclone mount (full cache) for archives, balancing latency, offline access and conflict handling.
Problem
Users need to replace Dropbox desktop client with rclone while balancing latency, offline access, disk usage and conflict handling.
Outcome
Running both rclone mount and bisync allows users to maintain offline access for working files while keeping archive files on remote storage, balancing latency, RAM, disk usage and conflict resolution.
Workflow
- 1. Identify working set and archive set.
- 2. Configure rclone bisync for the working set with a scheduled timer (e.g., every 5 minutes).
- 3. Run rclone mount with --vfs-cache-mode full for the archive set, optionally capping cache size.
- 4. Use bisync for two‑way sync between local and remote for daily edited files.
- 5. Use mount for read‑only or infrequent access to large archives.
- 6. Resolve conflicts manually when bisync creates conflict files.
- 7. Monitor cache usage and adjust --vfs-cache-max-size or --vfs-cache-max-age as needed.
- 8. Optionally expose server folder via rclone serve webdav for phone or second laptop access.
Evidence
An rclone mount with --vfs-cache-mode full gives you a folder that looks complete in your file manager, but every first read of an uncached file costs a network round trip, and nothing is available offline until you have opened it.
rclone bisync gives you genuine local copies with local disk latency and true offline access, at the cost of a scheduled run, a mandatory first --resync, and conflict files you have to resolve yourself.
Split your data: bisync the working set you edit daily, mount the archive you only read.
- Record date: 2026-10-03T05:41:08.151Z