Backups

Stoa is on-premises, which means backups are your responsibility, not a managed cloud feature. The good news: there's a small, well-defined set of things to back up, and once you have a strategy in place it largely runs itself.

What Stoa stores

A working deployment holds the following data:

• Knowledge base documents: the original files you uploaded (PDFs, Word docs, spreadsheets, slide decks). These live in a dedicated documents directory on the host.
• Knowledge base indexes: the searchable representation of your documents. Derived, but expensive to recompute.
• Conversation history: every chat, every message, every citation. In the database.
• Configuration settings: AD settings, SMTP, webhooks, model config, role definitions, sharing rules. In the database.
• Audit log: the durable record of every mutating action. In the database.
• Branding logo file: the uploaded logo image. On disk alongside the documents.
• User accounts: username, email, password hashes (or AD identifiers), role assignments. In the database.

What needs to be backed up vs what can be recreated

Not everything needs the same level of protection.

Data	Backup priority	Notes
KB source documents	Critical	Cannot be recreated unless originals exist elsewhere.
KB indexes	Recommended	Rebuildable from sources, but slow on large libraries.
Conversation history	Critical	The institutional memory of your platform.
Configuration settings	Critical	Tedious and error-prone to recreate.
Audit log	Critical for compliance	Required by most retention policies.
Branding logo	Low	Easy to re-upload if lost.
User accounts	Critical	Especially if you're not using AD/LDAP.

For deployments using Active Directory for sign-in, the directory is the source of truth for user identity. Stoa caches a thin profile per user, so losing that profile is recoverable.

Recommended backup strategies

Pick the strategy that matches your infrastructure. Most customers do a combination.

Filesystem snapshots

If your storage layer supports snapshots (LVM, ZFS, Btrfs, a SAN), schedule regular snapshots of the documents directory and the database volume. Pair with off-host replication so a single disk failure doesn't take both the live data and the snapshots.

Database dumps

Schedule daily database dumps to a directory outside the live database volume. Combine the dump with a tar of the documents directory, encrypt the bundle, and copy it off-host.

Off-site copies for air-gapped sites

For air-gapped deployments, "off-site" is whatever destination your security policy allows: a separate vault, an encrypted drive, a write-only bucket on a different network. Take a snapshot, copy it out of band, verify it's readable, and retain enough generations to survive corruption that took days to notice.

TIP

A backup you can't restore is not a backup. Once a quarter, restore one of your backups into a non-production environment and walk through the steps. The first time you discover that a backup is incomplete should not be the day you actually need it.

How often to back up

A reasonable starting point:

• Database dump: every 24 hours.
• Documents directory: every 24 hours, or after every large ingestion.
• Snapshots (if supported): every 6 hours.
• Off-site copy: at least weekly, ideally daily, retained for at least 30 days.

Adjust based on your recovery point objective (how much data you can afford to lose) and recovery time objective (how long you can be down).

Restoring from a backup

Restore is a workflow your delivery engineer walks you through, because it varies by what failed and how your storage is laid out. The high-level shape is always:

1. Stop the platform so nothing is writing while you restore.
2. Restore the database from the most recent good dump or snapshot.
3. Restore the documents directory from the matching backup point.
4. Start the platform and watch System status come up.
5. Run a sanity check: sign in, open a chat, query a KB, review the audit log for the restored range.
6. Reindex if needed, in case the documents and database snapshots aren't perfectly aligned.

If you're restoring from a backup older than your live audit log retention window, coordinate with your compliance team first so you don't overwrite recent records.

Backups and updates

When your delivery engineer applies an update, they always take a fresh backup as the first step of the maintenance window. You should still maintain your own independent backup discipline; the update-time snapshot is for rollback, not long-term archival.

Next

• System status to monitor health between backups.
• Updates & on-site delivery for the related rollback workflow.
• Audit logging for which records your retention policy needs to preserve.