Backups and restore
Back up and restore Studio and Runtime data volumes.
Backups and restore
Open Ticket AI stores its own state in two SQLite databases plus .env.
Ticket content stays in your ticket system — back that up with your existing
OTOBO / Zammad / KIX (or database) strategy.
What a backup contains
Each archive under backups/otai-backup-<timestamp>.tar.gz includes:
| Item | Purpose |
|---|---|
Studio SQLite (otai-studio.db) | AI tasks, options, config audit |
Runtime SQLite (otai-runtime.db) | Workflow run history / KPIs |
.env | License key, connector credentials, version pins |
docker-compose/ | Compose snapshot used with that install |
meta.json | Version, timestamp, volume names |
Default retention: last 14 archives (OTAI_BACKUP_KEEP to change).
Create a backup
otai backup
The command prints the archive path. Databases are dumped with SQLite’s online backup API via the running containers when possible.
Periodic backups
Install asks to enable daily backups by default. You can change that later:
otai backup --schedule daily # cron at 02:30 local
otai backup --schedule weekly
otai backup --schedule off
As root, this writes /etc/cron.d/otai-backup. Otherwise it uses the current
user’s crontab. If cron is unavailable, the CLI prints a line you can paste
into your existing scheduler.
Combine with your general backup strategy
- Run
otai backupon the same cadence as other app config (nightly is fine). - Copy or sync the install’s
backups/directory to encrypted off-host storage (same tool you use for VM / filesystem / object backups). - Continue backing up the ticket system database separately — OTAI backups do not replace that.
- Store
.envsecrets with the same controls as other credentials (the backup archive contains them; protect the share accordingly).
Suggested mental model: OTAI backup = small config + history files; ticket DB = large operational data.
Restore
otai restore latest
# or:
otai restore /path/to/otai-backup-20260726T120000Z.tar.gz
Restore stops Studio and Runtime, writes .env and compose from the archive,
loads both databases into the named volumes, starts the stack, and runs
otai verify.
Disaster recovery order
- Restore / start the ticket system (if needed).
- Restore the OTAI install tree (compose + CLI) if the host was rebuilt.
otai restore <archive>(or restorebackups/thenotai restore latest).- Confirm
otai verifyand that Studio opens from the ticket system.
Related
- Installation
- Updates (always backups before upgrading)
