Backups#
Plan required
Backups are available only on the Premium and Enterprise plans. Freemium accounts cannot back up, restore or schedule backups.
Ametnes treats a service as a single logical unit rather than a collection of separately managed components. A backup is per service, not per volume: it represents one service resource and captures every persistent volume that makes it up, together, as one recovery point for that service. Underneath, each volume is written as a restic snapshot in the backup repository of the resource's service location. Snapshot data is deduplicated across runs, so repeated backups add only the bytes that changed. You can back up a resource on demand, schedule recurring backups, and restore a backup into the same resource.
A service can be a single component or an assembly of several. One backup captures all of a service's volumes:
| Service | Volumes captured by one backup |
|---|---|
| GitLab | MinIO (uploads, artifacts, and packages), Gitaly (repositories), PostgreSQL, Redis, Prometheus |
| Sentry | ClickHouse, ClickHouse Keeper, Kafka, PostgreSQL, Redis, and Filestore |
The console lists one backup for the service, not one backup per volume. The individual volume snapshots are an implementation detail of that backup: you do not choose volumes, and a backup succeeds only when every volume is captured.
Service-level view, volume-level snapshots
The console presents a backup as a single unit for the service. The per-volume restic snapshots that make it up are an implementation detail: you cannot choose volumes, and a backup succeeds only when every volume is captured. A resource without persistent volumes has nothing to back up.
Manual runs#
A manual run is a one-off backup that you start when you need it. It is useful before a planned change, or when you want a recovery point outside the schedule.
A run moves through these states:
| Status | Meaning |
|---|---|
INIT |
Queued, or claimed by the agent and in progress. |
READY |
Backup completed and can be restored. |
ERROR |
The run failed. The error describes the cause. |
DELETING |
The resource was deleted and the run's snapshots are being removed. |
DELETED |
The run's snapshots were removed. |
A manual backup can start only when the resource is READY, INITIALIZED, or
STOPPED. In any other state the console disables Back up now.
Only one backup or restore run can be in progress for a resource at a time. A
run that no agent completes is marked ERROR after the location's stale
timeout.
Schedules#
A schedule is a recurring backup plan for a resource. It defines:
- Interval - how often to back up, in seconds. The default is 86400 (daily); the minimum is 60.
- Retention - the window, in days, for which snapshots are kept. Snapshots older than this are pruned after a successful backup. The default is 30.
- Enabled - whether the schedule creates new runs.
A schedule cannot be created while the resource is initializing, provisioning,
or being deleted. It creates a run only when the resource is READY or
INITIALIZED and no run is already in progress. The control plane checks due
schedules every 60 seconds, so a run can start up to a minute after its due
time. A resource can have several schedules; each must have a unique name.
Disabling or deleting a schedule stops new backups. It does not delete existing snapshots.
Backup storage#
The repository is provided by the operator of the service location. A location uses one repository for all of its resources, and snapshots are tagged by account, project, resource, and volume. Two storage targets are supported:
| Target | Description |
|---|---|
| Mount | A shared filesystem, such as NFS, or a PVC that is mounted into the backup job. Every node must see the same repository at the same path. |
| S3 | An S3-compatible bucket reached over the network. Credentials are read from a Secret in the resource namespace, or from workload identity. |
The control plane stores only the backup ledger and schedules. It never stores repository credentials and never reads or writes the repository. The location agent executes the backup jobs. For target configuration, see Backup Storage.
Quiesced backups#
Backups are quiesced only. Before capturing the volumes, the agent stops the resource's workload, takes the snapshot, and starts the workload again. This guarantees a consistent point-in-time copy across all of the resource's volumes and allows volumes that cannot be attached twice to be backed up.
Backups are quiesced
Online or hot backups are not supported yet. Expect a short outage for the duration of each backup.
Restore#
A backup can be restored into the same resource when the resource is READY,
INITIALIZED, or STOPPED. Restore works at the service level, not per
component: it returns the whole service to the state captured by one backup, in
one operation, rather than recovering each component separately and reassembling
the service by hand. Recovery is whole, not piecemeal - the service comes back
as the unit it was. You cannot restore a subset of a backup's volumes.
A restore is itself a run, listed in the console with a restore operation
alongside backup runs. It follows the same INIT to READY or ERROR
lifecycle and counts against the one-run-at-a-time limit.
The agent stops the workload if needed, restores the snapshots into the resource's existing volumes, and starts the workload again. The resource's storage must be large enough to hold the restored data.
Restoring into a different resource, a new resource, or another location is not supported.
Retention#
Retention runs after a successful backup. The agent keeps snapshots created
within the last retention days and prunes the rest. The value comes from the
schedule that created the run, or from the agent's configured default
(backup.retention, 30 days).
Retention runs only after a successful backup. A resource whose schedule is disabled, or that keeps failing, stops pruning until a backup succeeds again. Deleting a resource removes its snapshots through the deletion flow; it does not depend on retention.
Deleting backups#
When a resource is deleted, its backup runs move to DELETING and the location
agent removes the corresponding snapshots. The resource is retained as a
deleted tombstone until cleanup finishes, then removed. Schedules belonging to
the resource are deleted with it.
Deleting a single backup record does not remove its snapshots yet. The record is removed, but the snapshot remains in the repository until the resource is deleted or an operator removes it manually.
Limitations#
- Backups are quiesced only; online (hot) backups are not supported.
- Restore is same-resource only. Cross-resource clone, cross-location restore, and disaster recovery are not implemented.
- Deleting a backup record removes the record only; its snapshots remain in the repository until the resource is deleted.
- Backup records are not aged out automatically; they remain until the resource or the record is deleted.
- Backups run only when the location's agent has backups enabled. While
disabled, runs stay in
INITuntil they become stale and fail.
Operator-facing limits — repository garbage collection and legacy snapshots without tenant-qualified tags — are documented in Backup Storage.