rClone bisync (workaround)


Because the RCLONE bisync feature is in beta and not reliable, I have made a script that uses the stable command "sync" in combination with a few flags, to mimic a seamless bidirectional syncing experience with no manual maintenance such as the "resync" command.

Here it is: GitHub - sebaptcd/rClone-bysinc-workaround: rClone bisync feature is currently in beta and not reliable. This script uses the stable commands of the software to mimic a reliable and stable bidirectional syncing experience.

I built this for myself, but I thought to also share it here in case anyone finds it useful.

Also, if you have any better options or are doing it differently, let me know!

Are you sure that you are using the latest v1.66 version of rclone? Bisync has had major overhaul recently and should be out of beta in the next version when all tests are automated:

As of today it is already something very different in terms of reliability and functionality what it was before.

1 Like

Hello, I just had a look!

I indeed tried bisync with an older version as I read at some point that the lead developer for this feature quit maintaining it. But I will now keep an eye on the developments!

Thank you for your reply!

Have a look at updated docs - it should give you good overview how many things changed.

1 Like

This was true at one point -- but last summer I picked up where he left off and have been actively maintaining it since then. :slight_smile:

It looks like your script basically does rclone sync --update in both directions. A fundamental problem with this approach (and really any "stateless" approach to bidirectional synchronization) is that it won't be able to properly handle deletes (including renames). Deletes do not have timestamps, so without knowing the prior state, it is impossible to say whether an absent file was deleted from one side or added to the other. As a result, your script will be asymmetrical -- whether an absent file is interpreted as "new" or "deleted" will depend on whichever side happens to be the source first in the sync order.

An additional problem is that --update makes the assumption that "newer" always equals "better". For example, it would never be possible to restore from a backup with an older timestamp, as it would just get overwritten on the next sync. It also makes the assumption that the backend has modtime support, which is not true for all rclone backends.

Bisync overcomes these kinds of problems by keeping a prior "state" snapshot and reconciling changes with the "Dual Shadow" method. (bisync also uses sync under the hood, by the way.)

As @kapitainsky mentioned, bisync received a huge update in v1.66 and is much more stable compared to older versions. The integration tests will provide a way of officially verifying that going forward. I'd encourage you to give it a try, and as always, if you find any suspected bugs, please report them so we can get them fixed! :slight_smile: