Skip to content

Operations

Kody Dennon edited this page Jul 3, 2026 · 2 revisions

Operations

Operations are the habits that make backups useful when something goes wrong. A backup system is not complete until backup, verification, restore, and evidence review have all been exercised.

Health checks

Web UI:

http://localhost:8976

API health:

curl http://localhost:8976/api/v1/health

CLI health:

convex-autobackup health --json
convex-autobackup doctor --json

First production checklist

The web console guides the main setup path. Complete these items before trusting the system:

  1. Create an owner account.
  2. Create a project.
  3. Store or reference a Convex deploy key.
  4. Create a Convex Cloud target.
  5. Create a local or S3-compatible destination.
  6. Create a backup job.
  7. Create a schedule.
  8. Run a manual backup.
  9. Verify the backup.
  10. Run a restore drill against a non-production deployment.

Manual backup flow

CONVEX_AUTOBACKUP_MASTER_KEY=<master> convex-autobackup backup run \
  --job-id <job-id> \
  --json

List runs:

convex-autobackup runs --json

Verify:

convex-autobackup verify --run-id <run-id> --json

Restore flow

Restore requires explicit target confirmation:

CONVEX_AUTOBACKUP_MASTER_KEY=<master> convex-autobackup restore \
  --run-id <run-id> \
  --target-id <target-id> \
  --confirm-deployment <deployment-name> \
  --json

Do not test restore against production unless you are intentionally performing a real incident recovery.

DR evidence

Generate a DR report:

convex-autobackup dr-report --json

Review audit events:

convex-autobackup audit --json

Evidence to keep:

  • Backup schedule and retention settings.
  • Recent successful backup runs.
  • Recent verification results.
  • Restore drill date and result.
  • Storage destination and manifest references.
  • Operator notes for any failed run.

Logs

Docker:

docker logs convex-autobackup

systemd:

journalctl -u convex-autobackup -f

Native foreground:

convex-autobackup supervise

Retention

Local retention currently supports keep_last behavior after a successful backup. Keep enough backups to cover operator mistakes, application bugs, and delayed discovery of data corruption.

Recommended starting point:

  • Critical production: keep at least 14 to 30 successful backups.
  • Client/project work: keep at least 7 successful backups.
  • Development-only: keep enough for your own rollback window.

Upgrade cadence

Watch releases:

https://github.com/KodyDennon/ConvexAutoBackup/releases

Before upgrading:

  1. Back up the ConvexAutoBackup data directory.
  2. Export current configuration notes.
  3. Confirm the master key is recoverable.
  4. Read release notes.
  5. Upgrade.
  6. Run doctor.
  7. Run and verify a backup.

Clone this wiki locally