Backups
Frona AI stores all its data on disk. Backing up is a matter of copying the right directories.
What to back up
Section titled “What to back up”| Directory | Contents | Priority |
|---|---|---|
data/db/ | SurrealDB database (users, agents, chats, messages, tasks, memory) | Critical |
data/workspaces/ | Workspace files | Important |
data/files/ | Uploaded file attachments | Important |
.env | Configuration and secrets | Critical |
The database contains everything. User accounts, agent definitions, conversation history, memory, tasks, and credentials. Losing it means losing all platform state.
Backup procedure
Section titled “Backup procedure”1. Stop the engine
Section titled “1. Stop the engine”For a consistent backup, stop the engine first:
docker compose stop fronaThis ensures the database files are in a clean state (no active write-ahead logs).
2. Copy the data directory
Section titled “2. Copy the data directory”tar czf frona-backup-$(date +%Y%m%d).tar.gz data/ .env3. Restart the engine
Section titled “3. Restart the engine”docker compose start fronaAutomated backups
Section titled “Automated backups”Set up a cron job for regular backups:
0 2 * * * cd /path/to/frona && docker compose stop frona && tar czf /backups/frona-$(date +\%Y\%m\%d).tar.gz data/ .env && docker compose start fronaThis runs at 2 AM daily. Adjust the schedule and backup location to your needs.
Restoring from backup
Section titled “Restoring from backup”- Stop the engine:
docker compose stop frona - Remove or rename the current data directory:
mv data/ data.old/ - Extract the backup:
tar xzf frona-backup-20260227.tar.gz - Start the engine:
docker compose start frona
Considerations
Section titled “Considerations”- Downtime: stopping the engine for backup causes a brief outage. For most deployments, a few seconds of downtime during off-hours is acceptable.
- Backup size: the database grows over time, especially with many conversations. Monitor backup sizes and implement retention policies.
- Off-site storage: keep copies of backups in a different location (cloud storage, different server) for disaster recovery.
- Test restores: periodically test that you can actually restore from a backup. An untested backup is not a backup.