An AI workspace backup must preserve more than a container image. Conversations, notes, uploads, application configuration, encryption keys, and custom tools may live in different stores with different consistency requirements.
The recovery objective is a usable system, not simply an archive that can be listed. This guide extends Database Backups and Replication and Encrypted Backups with restic to an assistant workspace.
Start with a data inventory
| Data | Typical location | Recovery requirement |
|---|---|---|
| Conversations and accounts | Application database | Consistent dump or supported snapshot |
| Notes and documents | A separate database or document service | Ownership, content, revisions, attachments |
| Uploaded files | Bind mounts, volumes, or object storage | Match database references |
| Configuration and custom code | Files and Git repositories | Exact version and local patches |
| Application encryption secrets | Protected configuration | Recover encrypted credentials |
| Embeddings and indexes | Vector or search stores | Restore or reproduce from sources |
Do not assume that a Notes page and chat history share a database. Follow the actual save path and record every backing service.
Define the recovery target
Recovery point objective (RPO) describes acceptable data loss, such as an hour of new notes. Recovery time objective (RTO) describes how quickly the service must become usable again.
These targets determine scheduling, offsite copies, and whether a slow full reindex is acceptable. Keep an inventory of required versions and tools so rebuilding a container is not confused with restoring its data.
Capture a consistent recovery set
Use database-native backup tools or supported application-consistent snapshots. Copying the live database storage directory with a generic archive tool is not automatically consistent.
For related files and database references, either pause writes during capture or use a documented consistency mechanism. If independent stores cannot be snapshotted atomically, record capture times and the reconciliation procedure.
Name one recovery set with an identifier and include a manifest containing software versions, timestamps, file checksums, source revision, and backup-tool results. Keep secrets encrypted, with access restricted to recovery operators.
Keep copies outside the failure domain
Use multiple copies and at least one copy that a compromised application cannot modify. A backup on the same disk does not protect against that disk failing. A continuously writable remote share does not necessarily protect against ransomware.
Retain encryption recovery material separately and test that authorized operators can access it. Do not publish keys, environment files, database dumps, or full configuration output in a public wiki.
Restore in isolation
- Provision an isolated test environment with outbound email, webhooks, and scheduled agents disabled.
- Restore configuration and the application version associated with the recovery set.
- Restore databases and uploads using supported tools and correct ownership.
- Start dependencies and the application without exposing it publicly.
- Test login, old conversations, note edits, attachment downloads, and user separation.
- Verify search and document retrieval; rebuild only the indexes that are safe to regenerate.
- Record elapsed recovery time and any manual repairs.
Avoid replaying background jobs that could send duplicate messages or execute tools against real services. A restored copy should not share unrestricted production credentials during testing.
Upgrade and deletion considerations
Retain a pre-migration backup before an upgrade. Rolling back an image alone may fail after a schema migration. Document retention and how deleted private records are handled if an older backup is restored.