In This Article
Introduction
OpenClaw's memory and config contain your agent's context and history. Losing this data means losing context, preferences, conversation history, and potentially important records. A single disk failure or accidental deletion can wipe months of agent learning. Here's what we're covering: backup and recovery for production deployments — what to backup, how to implement it, recovery procedures, and how to validate your strategy.
What to Backup
Memory directory: Markdown files with agent context, conversation history, and learned preferences. This is the most critical data. Typically located at ~/.openclaw/memory/ or your configured path. Without this, your agent loses all context and must start fresh.
Config: YAML configuration including agent settings, model selection, and Skill configuration. Store secrets separately in environment variables or a secrets manager — never backup plaintext API keys. Backup the config structure with placeholders for sensitive values.
Custom Skills: Any custom Skill code and configuration. Version control (Git) is ideal — push to a private repo. If Skills live outside the main OpenClaw directory, include them in your backup scope.
Optional: Logs. For audit or debugging, you may want to retain logs. Logs can grow large; consider log rotation and separate retention policy (e.g., 7 days).
Backup Strategy & Implementation
Frequency. Memory directory: daily minimum. For high-activity agents (100+ interactions/day), consider every 6-12 hours. Config and Skills: on change, or weekly. Config changes are rare; Skills may update more often.
Step-by-step: Cron-based backup. Create a backup script: tar -czf backup-$(date +%Y%m%d-%H%M).tar.gz ~/.openclaw/memory/ ~/.openclaw/config.yaml. Add to crontab: 0 2 * * * /path/to/backup-script.sh (2 AM daily). Store backups off-host — rsync to another server, upload to S3, or use a backup service (Borg, Restic).
Retention. Retain 7-30 days depending on change frequency. Daily backups × 30 days = 30 restore points. For compliance-sensitive deployments, consider 90 days. Implement rotation: delete backups older than retention period.
Encryption. If backups contain sensitive data (client info, PII), encrypt before storage. Use gpg or backup tools with built-in encryption. Store encryption keys separately from backups.
Recovery Procedures
Step-by-step: Restore from backup. (1) Stop OpenClaw. (2) Restore memory directory to same path. (3) Restore config. (4) Restart OpenClaw. (5) Verify agent responds and has context — send a test message, check memory recall. (6) If Skills were backed up, ensure they're in place and loaded.
Migration to new host. Restore memory and config. Ensure same OpenClaw version (or compatible). Install dependencies and Skills. Update any host-specific paths in config. Test thoroughly before decommissioning old host.
Partial recovery. If only memory is corrupted, restore just memory. If only config was lost, restore config. Document recovery steps for your team — when disaster strikes, you want a runbook, not improvisation.
Implementation Checklist
- □ Identify all paths: memory directory, config, Skills
- □ Create backup script (tar, rsync, or backup tool)
- □ Schedule backups (cron, systemd timer, or orchestration)
- □ Configure off-host storage (S3, another server, NAS)
- □ Set retention policy and rotation
- □ Encrypt backups if containing sensitive data
- □ Document recovery steps; share with team
- □ Run a test recovery within first week
- □ Schedule quarterly recovery drills for production
Cost & Storage Considerations
Backup storage: S3 Standard ~$0.023/GB/month. A typical OpenClaw memory directory is 10-500 MB. 30 daily backups × 100 MB = 3 GB ≈ $0.07/month. Negligible. For larger deployments (1 GB memory), 30 backups = 30 GB ≈ $0.70/month. Backup tools (Restic, Borg) add deduplication — often 50-80% space savings. Total cost: typically under $5/month for most deployments.
Testing & Validation
Test recovery periodically. Restore to a test instance (or temporary directory) and verify: (1) Agent starts, (2) Agent responds to messages, (3) Memory context is intact (ask about a past topic), (4) Skills work. Backup without tested recovery is incomplete — you don't know if your backups are valid until you restore. Quarterly recovery drills recommended for production. Document results.
Common Pitfalls to Avoid
Pitfall 1: Backing up while OpenClaw is writing. Memory files can be mid-write. Stop OpenClaw during backup, or use a snapshot-capable filesystem (LVM, ZFS) for consistent backups.
Pitfall 2: Storing backups on same host. If the host fails, you lose both. Always store off-host.
Pitfall 3: Never testing recovery. Backups can be corrupted or incomplete. Test at least once.
Pitfall 4: Backing up secrets. Never include plaintext API keys in backups. Use env vars or secrets manager.
Frequently Asked Questions
Can we use cloud backup services (Backblaze, Carbonite)? Yes, if they support file-level backup of your OpenClaw directory. Ensure they don't exclude important file types. Test restore.
What about Docker deployments? Backup the volume or bind mount where memory and config live. Same principles apply. Use docker cp or volume backup tools.
How do we backup if OpenClaw runs 24/7? Option 1: Brief stop during backup (e.g., 2 AM for 2 minutes). Option 2: Use filesystem snapshots (LVM, ZFS) for consistent point-in-time copy without stopping.
Can we use Git for memory? Possible for config and Skills. Memory files change frequently and can be large; Git may not be ideal. Use dedicated backup for memory.
Wrapping Up
Backup is essential for production OpenClaw. Implement daily memory backups, off-host storage, and quarterly recovery drills. OpenClaw Consult advises on backup architecture for your getting it running.