Backup and Restore
AI Admin Panel includes backup controls for deployed services, but the restore implementation in v2.12.8 is incomplete. Do not use the panel's Restore action for recovery in v2.12.8. Arrange and test an application-specific recovery procedure before relying on a backup.
Retention can delete backups earlier than their own schedule specifies. In v2.12.8, a due schedule's retention period applies across backup types for the same service. Keep recovery copies outside the panel-managed backup set; see Retention Policy before enabling schedules.
Backup Types
On-Demand Backup
Open the service's Backups tab, select a database or volume backup and create it. The request queues background work; inspect its status and error. A completed job does not establish that the archive is complete or restorable.
Scheduled Backups
Review Retention Policy before configuring automatic backups:
- Open the service's Backups tab.
- Find the database or volume schedule under Backup Schedules.
- Enter a cron expression and retention in days (the form defaults to 30 days).
- Create the schedule, or save changes to an existing one. An existing schedule also has an Enabled checkbox.
Example cron expressions:
| Schedule | Cron Expression |
|---|---|
| Daily at 2 AM | 0 2 * * * |
| Weekly on Sunday at 3 AM | 0 3 * * 0 |
| Every 6 hours | 0 */6 * * * |
What Gets Backed Up
The v2.12.8 worker uses the service's first container for both backup types:
| Type | Implementation | Limit |
|---|---|---|
| Database | Runs pg_dump -U postgres --clean --if-exists | Not database discovery or a MySQL/MongoDB/Redis backup implementation |
| Volume | Runs tar czf - /data inside that container | Only /data, not every named volume or every container |
The selected container must have the required tool, path and access. A multi-container service may keep its database or files elsewhere. The worker does not export the Compose configuration, environment, customer, plan or deploy history as part of a complete service recovery bundle. Inspect archive contents and test an application-specific recovery process in isolation.
Storage Targets
Service backups use the configured S3-compatible backend. The panel initializes it from S3_ENDPOINT, S3_ACCESS_KEY, S3_SECRET_KEY, S3_BUCKET and S3_USE_SSL at startup. There is no implemented default local-backup directory or Settings → Backup → Storage editor. Ask your hosting administrator to configure and verify the target; never put live storage credentials in tickets.
Restoring from Backup
The service's Backups tab includes a Restore confirmation dialog. Its request queues work; accepting that request does not demonstrate that data was restored. The v2.12.8 restore worker does not apply the downloaded backup data. It attempts to stop containers and creates an execution request, but does not stream the backup into that request or run a database import or archive extraction. Its success-recording path is not evidence of recovery.
There is no automatic pre-restore safety backup or final application-health check in this worker. Using the action can interrupt a service without recovering its data. Do not test it against a live service to check whether a backup is usable.
Ask your hosting administrator to preserve the current data and the original backup, identify the archive format and the application's database and volume requirements, and test recovery in an isolated environment. Check the recovered application's records and files before planning a production recovery. Keep a separate rollback copy; the panel's Restore action cannot provide that guarantee.
Backup Management
Viewing Backups
Open a service's Backups tab to see its backup type, status, size, date and any available actions. Keep an independent recovery inventory; this list is not an infrastructure backup catalog.
Retention Policy
The service's Backups tab stores a retention period in days for each database or volume schedule. The form defaults to 30 days. It does not offer count-based or combined daily/weekly retention rules.
These are not independent policies in v2.12.8. The retention worker selects completed backups by service and age, without filtering by backup type. For example, when a volume schedule with a 7-day retention period is due, its cleanup can also delete a 10-day-old database backup, even if the database schedule specifies a 30-day retention period. This is a product limitation, not a safe way to manage different recovery windows.
Cleanup runs as a separate hourly job and considers only schedules that are due at that moment. It is not triggered by completion of each new backup, so the configured period is not a guarantee of timely cleanup either.
Keep an independent copy outside the panel-managed backup set for your required recovery window. Ask your hosting administrator to review existing schedules and preserve needed archives before relying on automatic retention. Matching the periods alone does not prove backup completeness, timely cleanup, or recoverability; the restore limitation still applies.
Manual Deletion
Individual backups can be deleted from the backup list. The service attempts to remove the S3 object and deletes the metadata row. Verify storage cleanup separately: an object deletion failure can be logged without preventing metadata deletion.
Infrastructure Backup
Service backups do not cover the panel database, Keycloak, OpenBao, or host configuration. Arrange a separate protected infrastructure backup and recovery plan with your hosting administrator, including the encryption/unseal material needed to recover protected data. Keep that material separate from ordinary support artifacts and restrict access to both archives and recovery keys.
Use the repository's docs/runbooks/openbao.md for OpenBao recovery planning. An OpenBao outage can block vault-backed secret reads and deployments; legacy AI-key fallback is conditional and is not a promise that stopping the vault is harmless. Do not run live stop/copy/restore commands merely to verify this page.