Centralized Storage Offerings

Concept

Centralized Storage Offerings

CSPs can create or adopt storage buckets and assign them as tenant offerings, while backup data flows directly between each appliance and its bucket.

ReadyCurrentscacspstorageofferingsresale

Overview

Centralized storage offerings let the CSP manage a storage back-end from the SCA — creating buckets, assigning them to tenant appliances, and reselling external-provider storage as a product — where the deployment model allows. It is a CSP-edition capability.

Centralized management is additive. The decentralized model, in which a partner registers a storage endpoint and each appliance connects to it directly while the SCA meters consumption, remains the default and stays valid.

The decentralized model stays the default

A partner can still register a storage endpoint and let each appliance connect to it directly while the SCA meters usage. Centralized offerings add a provider-managed option on top of that model; they do not replace it.

Storage Offerings

A storage offering is a named product that combines a provisioning mode, a storage back-end, a set of defaults, and a rate card.

An offering is assigned to a tenant in one action: the SCA provisions or resolves the bucket per the offering's mode and wires it to the tenant appliance as a named repository.

Tenants can choose among the repositories assigned to them, but they cannot create repositories themselves; repository creation and assignment stay with the CSP.

Three Provisioning Modes

An offering uses one of three provisioning modes, each with a distinct credential posture:

Provider-created bucket

The SCA creates the bucket, mints its credentials, and applies a quota. This is the fully automated path where the CSP owns and manages the storage back-end.

Adopt existing bucket

The SCA adopts a bucket the CSP already created on a managed back-end — verifying it rather than creating it, and leaving any existing data untouched. The SCA still mints the tenant credentials and applies a quota.

External bucket-scoped keys

The CSP supplies keys scoped to a single bucket from a third-party storage provider, and the SCA never holds an admin key for that back-end. This is how external-provider storage is resold.

Data Never Transits The SCA

The SCA's role is limited to bucket lifecycle, assignment, credential issuance and rotation, and metering.

Storage data never transits the SCA

Backups flow from the tenant appliance to the bucket directly. The SCA orchestrates and meters storage but is never in the data path.

Per-Tenant Storage Isolation

Storage isolation is structural: one bucket is one EBA (Enterprise Block Archive) repository is one deduplication domain, per tenant.

Tenant storage is never pooled across tenants; deduplication domains and offboarding purges stay confined to a single tenant.

Clean Offboarding

Offboarding a tenant's storage follows a defined lifecycle:

Reclaim — the repository is unassigned from the tenant's SHA once in-flight copies complete, and the per-tenant credential is revoked.
Data-return window — a CSP-configurable period during which the tenant can restore or export their data, or the bucket can be handed over where the storage back-end supports ownership transfer.
Purge — objects and the bucket are deleted, and a deletion-evidence record (object count, bytes, timestamps, operator) is written and retained on the SCA.
Detach — a data-preserving alternative to purge that releases the bucket while leaving the data intact.

Consumption-Based Billing

Storage is billed on measured consumption, computed from average daily TB reported by the tenant appliance rather than from provisioned capacity.

The assigned quota is an enforcement and alert threshold, never a billed quantity — a tenant is not charged for space that was allocated but unused.

Consumption is metered from SHA-reported usage and reconciled by the SCA; today it is billed at the tenant level, and per-repository breakdown is partial.