Skip to main content

​
The situation

Critical data needs a second copy outside the primary cloud: for resilience, for negotiating leverage with a provider, or because a regulator asks for it. Today that is a sync job per bucket, a second set of keys in every application, and a failover plan nobody has tested.

​
What OneBucket changes

One policy maps the bucket to several peer buckets, each synchronous or asynchronous, with a write quorum you set. Applications write once and the copies land. A new provider joins by adding a peer bucket, and opportunistic replication fills it from existing data as it is read. One write through OneBucket lands on AWS S3, Wasabi and on-prem peers according to the replication policy

​
How it works

  • Peer buckets. A policy maps one OneBucket to one or more peer buckets at your endpoints. Each peer is in sync, async or cache mode.
  • Write quorum. The quorum says how many write-enabled peers must succeed before the write is acknowledged. That is the dial between durability and latency, set per bucket.
  • Opportunistic replication. When a peer is added, existing objects are copied into it as they are read, so a second provider is usable with its existing data right away rather than after a bulk copy. The asynchronous flux path fills the rest in the background.
  • Exit option. Leaving a provider is a policy change, not a migration program: remove the peer, and the remaining copies carry on.