Control-plane backup and restore
Protect Infra configuration, identities, encryption material, and operational state.
Control-plane backups preserve the state required to recover an Infra installation. They are separate from application backups, which preserve droplet data.
Backup contents
Keep a consistent PostgreSQL backup and the recovery logs required for its selected recovery point. Back up encryption material and installation identity through a separately protected path. A database archive without its required key ring cannot decrypt stored credentials.
Retain the pinned release manifest and deployment configuration, including secret references and public origin. Include managed images and artifacts from object storage. Include observation data when historical metrics and journals are required after recovery; their omission loses that history without restoring it from PostgreSQL.
Node disks and guest volumes are not included by a database backup. Protect those through storage replication and application backup policy.
Create a backup
On the control-plane host, open the pinned release-bundle directory. Use its administrative utility to coordinate a backup manifest and record component revisions. The database backup must use a consistent method appropriate to the configured PostgreSQL deployment.
To create the backup at the configured archive destination, run:
./infra-admin backup create --destination control-plane-archiveTo verify its manifest and stored components, run:
./infra-admin backup verify --manifest BACKUP_MANIFEST_PATHReplace BACKUP_MANIFEST_PATH with the manifest path returned by the completed
creation command. If verification fails, correct the reported missing component
or storage error before using this backup for recovery.
The destination must already be configured and permitted. The manifest identifies required components and completion status. Verification of stored components does not establish that a full restore and agent reconciliation will succeed.
Keep encryption material independently protected from the database archive. Record how a recovery operator can retrieve both without depending on the failed installation's own authentication service.
Restore preparation
Select a complete backup and a compatible release bundle. Isolate the replacement installation from production agents, webhooks, scheduled actions, and the hosted Connector during initial restoration. Do not run two independent control planes with the same identity against the same nodes.
If restoring to a previous point in time, workloads can contain changes newer than the restored management database. The reconciliation plan must account for resources created, moved, or deleted after that backup.
Restore sequence
- Stop the failed or previous control plane and prevent it from issuing work.
- Restore database state through the selected recovery point.
- Restore encryption material, installation identity, and deployment configuration.
- Restore required object and observation data.
- Start the compatible services in recovery mode.
- Inspect resource inventory and queued or reconciling operations.
- Reconnect a controlled set of agents and reconcile authoritative state.
- Verify access, storage ownership, backups, and notification destinations.
- Enable normal scheduling and automation after review.
The recovery utility checks manifest completeness and reports unresolved component references. Do not acknowledge missing encryption material as an ordinary optional warning.
External side effects
A database restore cannot undo mail, webhook processing, hosted resources, or external backup deletion that occurred after the recovery point. Deduplicate replayed events and inspect external resource IDs before enabling integrations.
Recovery exercises
Restore periodically into an isolated environment and record actual duration, missing components, manual steps, and reconciliation outcomes. Test credential decryption and access to a retained application backup. Remove test identities and temporary data through a documented cleanup procedure.