How to Back Up Self-Hosted AI Agent Data
Backup strategy for AI agent systems differs from traditional application backups because of the unique data types involved. Model weights are large but re-downloadable. Vector indices are expensive to rebuild but not irreplaceable. Conversation logs and fine-tuned models may be truly unique and irreplaceable. Understanding these distinctions helps you allocate backup resources efficiently.
Step 1: Inventory Your Data Assets
Configuration files include Docker Compose files, environment variables, system prompts, agent workflow definitions, and platform settings. These are small (kilobytes) but critical. Losing your configuration means reconstructing your entire agent setup from memory.
Application databases store conversation history, user accounts, agent metadata, and platform state. Dify uses PostgreSQL and Redis. n8n uses SQLite or PostgreSQL. These databases range from megabytes to gigabytes depending on usage volume.
Vector database indices contain your embedded documents and knowledge base. Rebuilding these from source documents is possible but time-consuming (hours for large corpora). Sizes range from megabytes to tens of gigabytes.
Model weights are the largest files (4 GB to 130+ GB each). Base models can be re-downloaded from Hugging Face or Ollama's registry. Fine-tuned models, however, represent significant training investment and should be treated as irreplaceable.
Conversation logs and monitoring data accumulate over time and may be required for compliance, auditing, or agent improvement. These can grow to tens of gigabytes for active deployments.
Step 2: Prioritize by Recovery Importance
Tier 1 (critical, back up daily): Configuration files, application databases, fine-tuned model weights, and agent workflow definitions. Losing these stops your agent system and requires significant effort to recreate.
Tier 2 (important, back up weekly): Vector database indices and conversation logs. These can be rebuilt from source data but the rebuild process takes time and temporarily degrades agent capabilities.
Tier 3 (nice to have, back up monthly or not at all): Base model weights (re-downloadable), monitoring data older than 90 days, and temporary processing files. These are convenient to have backed up but not essential for recovery.
Step 3: Choose Backup Methods
For PostgreSQL databases: Use pg_dump to create logical backups. This produces a SQL file that can be restored to any PostgreSQL instance. Schedule pg_dump via cron to run during low-usage periods. Compress the output with gzip to reduce storage requirements. For larger databases, use pg_dump's custom format (-Fc) which supports parallel restore.
For Docker volumes: Stop the container (or at minimum quiesce the application), then copy the volume data. For databases, always prefer database-native backup tools (pg_dump, redis-cli BGSAVE) over raw volume copies, since volume copies may capture inconsistent state if the database is writing during the copy.
For configuration files: Store all configuration in a Git repository. Commit changes with meaningful messages. This provides versioned backup with history, making it easy to see what changed and when. Keep the Git repository backed up to a remote location (a private GitHub/GitLab repository, or a separate backup server).
For model files: Copy fine-tuned model weights to a separate storage location. For base models, keep a list of model names and versions so you can re-download them quickly if needed. Avoid backing up base models unless bandwidth is severely limited.
For vector databases: Qdrant supports snapshot exports via its API. pgvector data is included in PostgreSQL backups. For standalone vector databases, check their documentation for native backup procedures.
Step 4: Automate and Schedule
Manual backups do not happen reliably. Automate everything. Create a backup script that handles all Tier 1 data and schedule it with cron to run daily during your lowest-usage period (typically 2 to 4 AM).
Your backup script should: dump the PostgreSQL database, export Redis data if used, copy configuration files, and transfer all backup files to a remote location. The remote location should be physically separate from your AI server: an external drive, a different server, or cloud storage like S3, Backblaze B2, or Wasabi.
Implement retention policies to prevent backup storage from growing indefinitely. A reasonable starting policy: keep daily backups for 14 days, weekly backups for 8 weeks, and monthly backups for 12 months. Automate the cleanup of old backups as part of the backup script.
Monitor backup success. Your backup script should report its completion status. If a backup fails, you should receive a notification (email, Slack message, or monitoring alert) so you can investigate and fix the issue before the next scheduled backup.
Step 5: Test Restores Regularly
A backup that cannot be restored is not a backup. Schedule quarterly restore tests to verify your backup process works end to end. The test should restore a full backup to a test environment and verify that: the application starts correctly, conversation history is intact, vector search returns expected results, agent workflows function properly, and all configuration settings are correct.
Document the restore procedure step by step. When you actually need to restore from backup (likely under pressure during a system failure), clear documentation prevents mistakes. Include specific commands, expected outputs, and verification checks at each step.
Measure restore time during tests. Knowing that a full restore takes 30 minutes versus 4 hours informs your disaster recovery planning and helps you set realistic expectations for downtime in the event of a failure.
Security and Encryption
Backup files often contain the same sensitive data as your live system, including conversation logs, user credentials, and proprietary knowledge base content. Treat backups with the same security standards as production data. Encrypt backup files before transferring them to remote storage using tools like gpg or openssl. Store encryption keys separately from the backups themselves, ideally in a password manager or secrets management system that multiple trusted team members can access.
If you use cloud storage for remote backups (S3, Backblaze B2, Wasabi), enable server-side encryption in addition to encrypting files before upload. This provides two layers of protection: even if someone gains access to your storage bucket, they encounter encrypted files that require your local key to decrypt. Configure access controls on the storage bucket to limit who can read, write, and delete backup files. Enable versioning on the bucket to protect against accidental deletion or overwriting of backups.
For databases that contain user passwords or API keys, verify that your backup process captures these in their encrypted or hashed form rather than as plaintext. PostgreSQL stores password hashes by default, so pg_dump backups are safe in this regard. Environment variables and configuration files with API keys should be backed up to a separate, more restricted location than general application backups.
Back up configuration files and databases daily, vector indices weekly, and fine-tuned models whenever they change. Automate everything, store backups on a separate system, and test restores quarterly. A backup strategy you never test is a strategy that might not work when you need it most.