Rclone vs backblaze b2 sync

rclone can be configured to sync to BackBlaze B2 cloud storage. But BackBlaze provides their own tools, “b2 sync” will sync a local directory to a BackBlaze bucket. So I’m confused about the difference between rclone and “b2 sync”.

What functionality does rclone provide (with respect to storing data with B2) that is not already provisioned by “b2 sync” ?

The main functionality is that rclone will work with many cloud providers not just b2, so if you learn rclone then you can use it with s3, google drive, dropbox, box, etc, etc.

rclone has a lot more features that b2 sync, eg rclone mount

That said if you start syncing files with b2 sync and decide to use rclone later then it will be compatible.

Thanks ncw. Backblaze support gave me a few comments. They said b2 sync was developed as a barebones sync utility, so it does not get as much development as rclone does.

I noticed using b2 sync, that it periodically hits errors, e.g. that the B2 server is full (busy) and can’t process the transaction. This is not a problem with B2, it’s actually the whole point of Backblaze’s design. Rather than having 100% availability, they designed the server to reject a transaction if it can’t be fulfilled in timely manner. This is precisely how they’re able to keep their cloud storage costs low. The intention is that you just try the file transfer again.

Since b2 sync is a bare-bones program, when it hits the error it moves on to the next file. “Try again” in this case means you need to run b2 sync again to catch the skipped files.

rclone has got more intelligence built into it than b2 sync, so it automatically retries the file transfer in the same run when it’s rejected the first time.

Yes, rclone tries quite hard to deal with this - it is quite complicated! Rclone also has a system of --low-level-retries which will retry the individual operation (like uploading a block of a file) or --retries which will redo the entire sync.

2 Likes