Server backups and recovery
Back up, restore, and recover an Autodisc Server without losing track of retained resources.
Backups are separate durable resources. Stopping a Server does not delete its volumes or backups, and deleting a Server does not imply that every separately retained backup has been deleted.
Recovery behavior was checked against the managed Server and backup contracts on 2026-07-13. A backup or restore control is shown only when the destination and Server runtime are configured and authorized; unavailable integrations fail closed.
Destinations and retention
Autodisc can expose an automatic managed backup destination without revealing its object-store provider, endpoint, bucket, or credentials. Authorized users may also add an S3-compatible destination they control. Custom credentials are stored server-side and must not be pasted into support messages.
Before relying on a backup:
- Confirm its completion time, scope, size, and retention state.
- Run the available restore test into an isolated target.
- Verify application startup and expected data before changing the original.
- Record any application-consistency steps required by the database or service.
Backups and snapshots can continue to consume storage after a Server stops or is deleted. Delete them explicitly only after the retention requirement has ended.
Recover by state
| State | Safe response |
|---|---|
quota_hold | Review Billing → Usage, retained storage/IPv4 cost, reset time, and the configured cap. Data is not deleted. |
degraded | Check health, metrics, networking, disk capacity, and the latest lifecycle operation before restarting. |
failed | Open the failed operation, copy its correlation ID, and retry only after correcting the reported cause. |
stopped | Confirm enough Server credit or approved overage remains, then start. Persistent storage stays attached. |
deleted | Restore only from an independently retained backup or snapshot. A deleted runtime is not resurrected automatically. |
Do not repeatedly retry an unknown provisioning failure: lifecycle operations are idempotent, but a persistent configuration or capacity error needs to be fixed. If support is required, include the account, Server name, canonical state, operation time, and correlation ID. Redact addresses when they are not necessary, and never include credentials or private keys.
For billing rules during stop or deletion, see Servers, pricing, and lifecycle.