Knowledge guide
Self-Hosted AI Backup and Recovery Checklist: Restore the Whole Agent Stack
Use this self-hosted AI backup and recovery checklist to protect models, agent state, vector data, MCP services, secrets, and restore evidence.
Data accurate as of August 2026 based on market research
Contents
Introduction
What a recoverable AI system contains
Build the recovery inventory
Use the right backup method
Back up Hermes Agent and connected services
Restore in dependency order
Run a recovery acceptance test
What to copy and what to rebuild
Common misconceptions
FAQ
Conclusion
Truth Box
| Key Point | Insight |
|---|---|
| Back up state, not only models | Chats, agent memory, source documents, vector data, workflows, and credentials may be harder to replace than a downloadable base model |
| One archive rarely covers the whole stack | Agent files, databases, object storage, browser sessions, and remote MCP services can have different authoritative stores |
| Use application-aware backups | A generic volume copy is useful for files, but live databases need their documented dump or snapshot process |
| Integrity checks are not restore tests | A valid archive can still restore into an unusable or incomplete application |
| Recovery needs evidence | Record the backup ID, component versions, restore result, test date, owner, and failed checks |
Introduction
A self-hosted AI backup must recover a working system, not only models. Cover agent state, databases, documents, vector indexes, MCP services, secrets, schedules, and reconnection instructions.
Proof comes from a clean restore that answers a known retrieval question, runs a harmless tool call, and completes a canary schedule.
This checklist complements Nguyen LNP's self-hosted AI system deployment service and guide to private knowledge systems with Hermes Agent and MCP.
What a recoverable AI system contains
Treat the stack as separate recovery scopes:
| Scope | Examples | Record |
|---|---|---|
| Deployment | Compose, proxy, service settings | Repository, version, effective config |
| Agent state | Hermes profiles, sessions, memory, skills, cron | Full backup and profile inventory |
| AI assets | Models, Modelfiles, adapters, prompts | Name, revision, source, rebuild path |
| Knowledge | Source files, vector collections, aliases | Native snapshot, corpus, embedding version |
| Application data | PostgreSQL, SQLite, workflow databases | Native backup and restore command |
| Access | Secrets, OAuth, browser sessions | Encrypted copy, owner, login path |
Prioritize source data, agent memory, custom adapters, approvals, and audit records by replacement difficulty, not file size.
Build the recovery inventory
Start from the running system because source files can drift. For Docker Compose, docker compose config renders the effective deployment after merging files and resolving variables. Review that output for secrets before storing it.
Record each service, data path, volume, database, model, vector collection, MCP server, browser profile, schedule, certificate, and upstream account. Add its version, owner, backup method, and restore order. Version non-secret configuration and recovery scripts. Store secrets with a separate access-recovery plan.
Use the right backup method
| State | Method | Check |
|---|---|---|
| Docker volume | Documented export or quiesced snapshot | Restore into a new volume |
| PostgreSQL | Logical dump or planned base backup | Query expected records |
| Qdrant | Snapshot matched to topology | Check collections, aliases, and known search |
| Ollama | Preserve or redownload models and custom inputs | Run ollama ls and required models |
| Source documents | Versioned object storage or encrypted backup | Open files and rebuild a small index |
| Secrets | Encrypted backup with key escrow | Test decryption and login recovery |
Docker's volume procedure suits ordinary files, but a raw copy of a busy database may be inconsistent.
PostgreSQL documents pg_dump as an internally consistent snapshot that can run alongside normal activity. Cluster-wide roles and tablespaces need separate attention, and pg_verifybackup still does not replace a test restore.
Qdrant collection snapshots include configuration, points, and payloads, but not aliases. Distributed restores need node-aware planning and compatible versions.
Back up Hermes Agent and connected services
Hermes Agent provides hermes backup for a full ZIP of configuration, skills, sessions, and data. The codebase is excluded, so record the intended Hermes version separately. Use the full backup for disaster recovery and keep the secret-bearing archive in encrypted storage.
After import, compare environments with hermes dump. Check profiles, sessions, memory, skills, plugins, cron jobs, and every MCP connection. Tokens can expire or be revoked, so keep a reauthentication path. Back up each MCP server's database separately because MCP is an interface, not a storage system.
Restore in dependency order
Restore on an isolated host or namespace so tests cannot trigger real side effects:
- Install the recorded operating system, container runtime, and Hermes version.
- Restore deployment configuration, networks, volumes, certificates, databases, source documents, object storage, and vector collections.
- Restore or redownload models, then import Hermes state.
- Restore secrets and reconnect services, expecting some OAuth connections to need a new login.
- Run read-only checks before enabling publishing, payments, account changes, or customer messages.
Run a recovery acceptance test
| Test | Passing evidence |
|---|---|
| Repository | Opens with the escrowed key and selected snapshot verifies |
| Services | Health and expected versions match |
| Agent state | Profiles, sessions, memory, skills, plugins, and cron are present |
| Retrieval | Known question returns the expected source |
| MCP | Inventory loads and a read-only call reaches restored data |
| Browser | Low-risk page opens or login recovery works |
| Schedule | Canary run records the expected safe output |
| Objective | Actual restore time and data-loss window are recorded |
NIST Cybersecurity Framework 2.0 states that backups should be created, protected, maintained, and tested. Testing the whole application is what turns that outcome into useful operational proof.
What to copy and what to rebuild
Copy unique or costly state: source documents, custom adapters, agent memory, workflows, databases, approval logs, and recovery keys.
Rebuild public models, images, packages, indexes, and caches only when the exact version and source are recorded and tested. Keep the source corpus even when vector snapshots exist. It provides an independent rebuild path if a snapshot is incompatible.
Common Misconceptions
| Myth | Correction |
|---|---|
| Backing up the Ollama models protects the AI system | Models are one layer. Agent state, databases, source files, vector data, credentials, and schedules need their own recovery plan |
| A Docker volume copy works for every service | File copies can be useful, but active databases and distributed vector stores need application-aware procedures |
| A successful backup command proves recovery | It proves that a job finished. Only an isolated restore and functional acceptance test prove that the stack works |
FAQ
What should I back up in a self-hosted AI system?
Back up unique data, agent state, databases, source documents, vector snapshots, custom model inputs, configuration, secrets, schedules, and a versioned recovery runbook. Record rebuild instructions for replaceable models and packages.
Do I need to back up Ollama models?
Back them up when download time, bandwidth, availability, or custom changes matter. Otherwise, preserve the model inventory, exact source or revision, Modelfiles, adapters, and a tested download path.
Is a Docker volume backup enough for PostgreSQL?
Not by itself. Use PostgreSQL's documented logical or physical backup method based on the required recovery objective, then restore and query the database in a test environment.
Does a Hermes Agent backup include MCP server data?
No. It can preserve Hermes configuration and local agent state, but each MCP server and its upstream application can have a separate database, object store, or cloud account that needs its own backup.
How often should I test a self-hosted AI restore?
There is no reliable universal interval for every stack. Set the schedule from the rate of change, business impact, recovery objective, and recent infrastructure changes. Always test after major storage, database, authentication, or architecture changes.
Sources and Further Reading
Hermes Agent, CLI commands reference
Hermes Agent, configuration
Docker, volumes
Docker, docker compose config
PostgreSQL 18, SQL dump
PostgreSQL 18, pg_verifybackup
Qdrant, snapshots
Ollama, FAQ
Model Context Protocol, authorization
NIST, Cybersecurity Framework 2.0
Local AI Master, Local AI Backup and Disaster Recovery
RDF Industries, Backups, Recovery and Change Management for a Self-Hosted AI Stack
Conclusion
Map every stateful component, choose its backup method, and finish with an isolated functional test. Prove one retrieval query, a harmless MCP call, and a canary schedule before enabling production side effects.
Browse more AI guides or email [email protected] with the stack, data, and recovery target.
Need help applying this?
See the related service page: Self-hosted AI system deployment or email [email protected].