Skip to main content

​
Buckets are bound to a location

Each bucket has a datacenterId that binds it to a storage location. The location determines where the bucket’s objects are written. Region and datacenter selection happens when a bucket is created in the dashboard. The public API can read the binding through bucket records, but cannot move a bucket between locations.

​
One region per object

An object lives in one region of Everabyte’s storage infrastructure. Everabyte does not automatically replicate objects to a second region. This is a deliberate, documented limit. Versioning, object lock, retention, and trash protect against logical deletion and corruption. They do not protect against the loss of an entire region.
Everabyte does not provide automatic multi-region redundancy, cross-region disaster recovery, or a guaranteed recovery point objective. These are not part of the standard service.

​
What you can rely on

​
Availability of locations

Available datacenters and regions depend on the deployment and the customer’s plan. Do not hardcode region identifiers in your application. Read datacenterId from bucket records and treat it as opaque. If your integration needs a specific jurisdiction or location, confirm availability with Everabyte before committing to a design. See Data residency.

​
Designing for regional failure

Because there is no automatic second copy, durability against regional loss is an application decision:
  • Keep an independent copy in storage you control, if the data is business-critical.
  • Use version history and retention for logical protection, not as a substitute for geographic redundancy.
  • Test restores from your own copy, not only from Everabyte.
  • Define your own RTO and RPO; Everabyte does not publish guaranteed values for standard plans.
For enterprise arrangements, discuss durability requirements during onboarding.