Bisync Basics and Conflicts

rclone bisync is useful when both sides can change, but it requires careful conflict policy and regular runs.

When to Use Bisync

Good fit	Not a good fit
Small team shared folders	Large immutable backup archives
Low-latency change cycles	One-way authoritative source systems
Conflict policy is agreed	No owner for conflict resolution

Mapping

• Bootstrap and Resync
• Conflict Handling
• Cadence and State

First Run Pattern

bisync-bootstrap.sh

rclone bisync local-share: team-share: \
  --resync \
  --check-access \
  --log-file /var/log/rclone-bisync.log

Ongoing Run Pattern

rclone bisync local-share: team-share: \
  --check-access \
  --create-empty-src-dirs

note

Bisync stores state. If state files are lost or stale, run a controlled resync and verify outcomes.

Conflict Considerations

Case	Expected behavior
Same file changed on both sides	Conflict handling required
Deleted on one side, edited on the other	Policy-dependent result
Metadata-only changes	Backend capability dependent

Common Pitfalls

Pitfall	Consequence	Prevention
Running bisync on unstable remotes	Frequent conflict churn	Use one-way sync where possible
Skipping regular cadence	Large divergence	Schedule predictable runs
No conflict review process	Data ambiguity	Define owner and conflict triage

What's Next

• Rollback-Safe Sync Workflow
• Exit Codes, Locking, and Idempotency