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:

ItemPurpose
Studio SQLite (otai-studio.db)AI tasks, options, config audit
Runtime SQLite (otai-runtime.db)Workflow run history / KPIs
.envLicense key, connector credentials, version pins
docker-compose/Compose snapshot used with that install
meta.jsonVersion, 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

  1. Run otai backup on the same cadence as other app config (nightly is fine).
  2. Copy or sync the install’s backups/ directory to encrypted off-host storage (same tool you use for VM / filesystem / object backups).
  3. Continue backing up the ticket system database separately — OTAI backups do not replace that.
  4. Store .env secrets 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

  1. Restore / start the ticket system (if needed).
  2. Restore the OTAI install tree (compose + CLI) if the host was rebuilt.
  3. otai restore <archive> (or restore backups/ then otai restore latest).
  4. Confirm otai verify and that Studio opens from the ticket system.