OperationsBackup & restore

Backup & restore

Mnemosyne stores everything in PostgreSQL. There is no separate state to preserve. Use the backup tooling you already trust — Mnemosyne plays nicely with all of it.

Continuous backup (recommended)

# Enable continuous archival of WAL segments to S3-compatible storage
archive_command = 'aws s3 cp %p s3://mnemo-wal/%f'

With WAL archival you can point-in-time recover to any second in the configured retention window.

Periodic snapshots

# Daily snapshot, 06:00 UTC, retain 30 days
pg_basebackup -D /backup/mnemo-$(date -u +%F) -X stream -P

Logical export (portable)

For migrations across PostgreSQL versions or hosts:

mnemo export > workspace.jsonl.gz

mnemo export takes no flags — it dumps the current workspace (derived from your API key) as gzip JSONL to stdout. Re-import on any other Mnemosyne instance:

mnemo import workspace.jsonl.gz --from mnemo --conflict-resolution skip

Restore

# From pg_basebackup
pg_restore --create --dbname=mnemo /backup/mnemo-2026-06-07

After restoring the database, run the migrate service (npx mnemo-migrate) to apply any migrations added since the snapshot before starting the server. Migrations are forward-only.

What ends up in backup

  • All mnemo_* tables (facts, decisions, entities, relations, etc.)
  • API keys (mnemo_api_keys) — review whether you want these in backup
  • Audit log (mnemo_audit_log once shipped) — required for compliance
  • Embeddings (the embedding column is a regular pgvector type — backed up alongside the row)

What doesn’t (and doesn’t need to)

  • The Redis hot tier. It rebuilds from PostgreSQL on next boot.
  • Materialised views. Rebuilt on next refresh cron.
  • The OpenAPI document. Generated at build time.
Running pluginsMonitoring