Sendense Documentation

EBA Repositories

How EBA repositories work across local appliance storage, remote self-hosted EBA storage, and external S3-compatible providers.

Documents Home

Concept

EBA Repositories

How EBA repositories work across local appliance storage, remote self-hosted EBA storage, and external S3-compatible providers.

ReadyCurrentebarepositoriesstorage

Repository Model

An EBA repository is the Sendense-managed storage target for backup recovery points. It holds deduplicated and compressed protected data, recovery-point metadata, and the governance state used by restore, validation, browse, retention, and cleanup workflows.

Administrators manage repository behavior through EBA, independent of the underlying storage provider.

Deployment Models

Local appliance storage
SHA provisions attached disks on the appliance for EBA storage.
Remote self-hosted EBA storage
SHA commissions a remote host and registers the Sendense EBA Provider as Sendense-managed EBA storage. Available where the feature is enabled.
External S3-compatible provider
SHA connects to an existing qualified S3-compatible bucket using customer-supplied credentials.

Provisioning

EBA repositories can be provisioned automatically from SHA. This applies to self-hosted repositories and repositories backed by external S3-compatible providers. External providers are qualified by repository capability checks, including Object Lock support where immutability will be used.

Repository deployment models

Recovery points live in governed EBA repositories: on local appliance storage provisioned by SHA, on an external S3-compatible provider, or both, with policy-driven secondary copies between repositories.

Repository deployment modelsSENDENSE HUBEXTERNAL PROVIDERCONTROL PLANESHAProvisioning + governanceSELF-HOSTEDEBA RepositoryLocal appliance storageEXTERNALEBA RepositoryS3-compatible providerProvisions + writesS3-compatible writesSecondary copy
Backup and recovery trafficSecondary copy (policy-driven)

Repository Setup Flow

Repository creation in the SHA GUI is organized around five steps.

Location
Repository name, description, and storage location.
Performance
Compression and optional SSD cache behavior where available.
Preflight
Compatibility and capability review for external S3-compatible providers.
Safety
Destructive-disk confirmations and generated-credential confirmation where required.
Review
Final configuration review before creation.

Repository Settings

  • Repository name and description.
  • Storage location and backing deployment model.
  • Credentials stored in the Sendense vault.
  • Compression level.
  • Deletion grace period.
  • Repository status: active, disabled, or error.
  • Last verification and health check state.
  • Capability state for external S3-compatible providers.
  • SSD performance cache settings for managed local or remote repositories where present.

SSD performance cache

Some managed EBA repositories can use an SSD tier that accelerates backup writes and repeat reads before data settles to capacity storage. Availability depends on the deployment model, detected devices, and host prerequisites.

External Provider Capability

SHA probes external S3-compatible repositories to understand provider capability. Standard repository mode and version-aware repository mode have different governance and cleanup capabilities, and bucket versioning plus Object Lock support affect whether pattern immutability can be used.

Capability results are reported as outcomes such as eligible, blocked, unsupported, or needs configuration, and can be refreshed by reprobing the repository. A repository can still be usable for storage even when a specific governance feature is blocked.

Relationship To Patterns And Recovery

Protection patterns choose which EBA repository stores primary recovery points, decide retention behavior, and decide whether backups use repository immutability where the repository supports it. The repository enforces storage and governance capability; the pattern decides how protected workloads use it.

Repositories are the recovery-point source for restore, browse, and validation. Repository status, credentials, external provider access, and governance constraints all affect whether a recovery point is immediately usable.

When You Work With Repositories

  • When creating or assigning protection patterns.
  • When planning retention, immutability, and legal hold.
  • When browsing recovery points or starting recovery operations.
  • When reviewing repository health, capacity, and cleanup status.

Related Docs