Multi-Cloud Storage Disaster Recovery with AIOZ and S3

Multi-cloud storage disaster recovery, in its simplest working form, means the same data lives on two genuinely independent providers, kept in sync, so that one provider's outage or account issue doesn't take your data down with it. rclone's bisync command does exactly that between AWS S3 and AIOZ Storage, keeping changes on either side reflected on the other, both ways. It's also a command rclone's own documentation is unusually blunt about: real, working, and genuinely risky if you skip the safety steps. This article covers the actual setup, why the caution is warranted, and the specific flags that keep bisync's two-way behavior from becoming a two-way data-loss mechanism.

TL;DR:

• rclone bisync keeps two remotes, AWS S3 and AIOZ Storage here, in sync in both directions, changes on either side propagate to the other, unlike a one-directional backup.
• rclone's own documentation calls bisync "an advanced command" and warns that skipping the manual before using it "can result" in data loss, not a casual warning to skim past.
• Every setup needs an initial --resync run, then real ongoing runs with --check-access and --max-delete as safety limits against a bad sync doing more damage than intended.

Why Bisync, Not a One-Directional Sync

A one-directional rclone sync, the tool this series' backup automation guide uses, assumes one side is the source of truth and the other is a copy that should always match it. Multi-cloud resilience for a live, actively-used dataset is a different problem: if you're genuinely using both S3 and AIOZ Storage, changes might happen on either side, a file uploaded directly to S3 by one process, another uploaded directly to AIOZ Storage by a different one, and you want both remotes to end up reflecting the same complete set of files regardless of which side a change originated on. That's specifically what bisync is built for, and specifically why a one-directional sync tool can't do the job.

Why rclone Calls This an "Advanced Command"

rclone's own documentation doesn't hedge on this: "bisync is considered an advanced command, so use with care. Make sure you have read and understood the entire manual (especially the Limitations section) before using, or data loss can result." That's a stronger warning than most CLI tools attach to their own features, and it's warranted by what bisync actually has to do: reconcile changes from two independent sources without a single source of truth to defer to, which means it has to make real decisions about conflicting or ambiguous changes, decisions a one-directional sync never has to make at all.

Setting Up the Two Remotes

Bisync works on top of two already-configured rclone remotes, the same source and destination remote structure covered in this series' migration guide:

[s3]
type = s3
provider = AWS
access_key_id = <your-s3-access-key-id>
secret_access_key = <your-s3-secret-access-key-id>
region = <your-s3-region>

[aioz-storage]
type = s3
provider = Other
access_key_id = <your-aioz-storage-access-key-id>
secret_access_key = <your-aioz-storage-secret-access-key>
endpoint = https://s3.aiozstorage.network

Nothing about the remote configuration itself is bisync-specific, it's the same two remotes a one-directional migration or backup would use. What's different is the command that operates on them.

The Required First Run: --resync

Every bisync relationship has to start with an explicit resync, and rclone's documentation is direct about why: it establishes the initial baseline state bisync compares future runs against. The first command looks like:

rclone bisync s3:my-bucket aioz-storage:my-bucket --resync

Critically, --resync is a one-time step, not something to leave on. rclone's own documentation warns: "for successive sync runs, leave off the --resync flag. (Important!)" Every run after the first should drop the flag entirely, using --resync on an ongoing basis defeats the point of the baseline it establishes and can mask real divergences bisync should otherwise be flagging.

The Safety Flags That Actually Matter

Two settings do real protective work on every subsequent run. --check-access verifies that matching test files exist on both remotes before proceeding, a sanity check that both sides are actually reachable and correctly configured before bisync trusts what it sees as the true state of either one. --max-delete, defaulting to 50%, caps how much of one side bisync is willing to delete in a single run, a real backstop against a misconfiguration or an accidental mass-deletion on one remote silently propagating as a mass-deletion on the other. A realistic ongoing command looks like:

rclone bisync s3:my-bucket aioz-storage:my-bucket --check-access --max-delete 25

Tightening --max-delete below its 50% default, to 25 or lower, is a reasonable default for a resilience setup specifically, since the entire point of running two independent copies is that neither one should be able to silently wipe out a large fraction of the other in one bad run.

What Multi-Cloud Resilience Actually Buys You Here

With bisync running on a schedule between S3 and AIOZ Storage, a genuine AWS-side outage, account lockout, or regional incident leaves your data fully intact and reachable on AIOZ Storage, and vice versa, an AIOZ Storage-side issue leaves S3 as a live, current mirror rather than a stale one. That's meaningfully different from a one-directional backup, where the backup destination is only ever as current as the last successful sync and was never meant to be an actively-used copy in its own right. Bisync's cost is real operational complexity in exchange for that: two live, independently-writable copies to reason about instead of one source and one passive backup.

Frequently Asked Questions

What does rclone bisync do?
Keeps two remotes synchronized in both directions, changes made on either side get reflected on the other. Unlike a one-directional sync, neither remote is treated as the sole source of truth.

Why does rclone call bisync an "advanced command"?
Because reconciling changes from two independent sources without one canonical source of truth requires real decisions about ambiguous or conflicting changes. rclone's own documentation warns that skipping the manual, especially the Limitations section, before using it can result in data loss.

What is the --resync flag for?
Establishing the initial baseline state on the first run of a bisync relationship between two remotes. It should only be used once, rclone's documentation explicitly warns to leave it off on every subsequent run.

What does --max-delete protect against?
It caps how much of one remote bisync will delete in a single run, defaulting to 50%. Lowering it, to 25% or less for a resilience setup, limits the damage a misconfiguration or accidental mass-deletion on one side can do to the other.

Is bisync the same as a backup?
No. A backup is typically one-directional, one side is the source of truth and the other is a copy meant to reflect it. Bisync maintains two actively-writable, independently-updatable copies kept in sync both ways, a different job suited to genuine multi-cloud resilience rather than pure backup.

Do the two remotes need to use the same rclone remote type?
No. This setup pairs an AWS S3 remote (provider = AWS) with an AIOZ Storage remote (provider = Other), both using rclone's s3 backend type, since both are S3-compatible, but configured with their own distinct credentials and endpoint.

Related Reading

• Automating Backups to AIOZ Storage with GitHub Actions - the one-directional alternative for a scheduled backup job, versus this article's two-way sync.
• Migrate from Amazon S3 to AIOZ Storage with rclone - the rclone remote configuration this bisync setup is built directly on top of.
• The 3-2-1 Backup Rule: A Practical Framework Explained - how a two-way multi-cloud mirror fits alongside, but doesn't replace, a real backup strategy.
• AIOZ Storage Explained: S3-Compatible Decentralized Storage - what AIOZ Storage is overall, including the infrastructure independence that makes it a genuine second provider for this setup.

References

• rclone Documentation: bisync
• rclone Documentation: sync command