convex-backup
get-convex/agent-skills
Set up Convex backups and prove recovery works with automated restore drills.
What is convex-backup?
This skill sets up regular Convex database snapshots and runs restore drills that actually recover data into a throwaway preview to verify backups are usable. Use it to establish a backup strategy matched to your RPO (recovery point objective) and validate that you can restore before disaster strikes.
- Export Convex database snapshots on a schedule matched to your RPO
- Run automated restore drills into disposable preview deployments to verify recovery works
- Assert that restored data is intact by checking row counts and spot-checking records
- Generate a gated recovery runbook with deploy-guard protection for production restores
- Detect failed restores before a real disaster by validating critical tables came back with expected data
How to install convex-backup
npx skills add https://github.com/get-convex/agent-skills --skill convex-backup- A Convex project with deploy access
- A Preview Deploy Key (paid-tier feature) for running drills; alternatively a fresh personal dev deployment
- CI/cron infrastructure or manual scheduling for regular exports to durable storage you control
How to use convex-backup
- 1.Run `npx convex export --path backup-<date>.zip` (add `--include-file-storage` if your app stores files) to create a snapshot
- 2.Schedule regular exports via CI/cron to durable storage with a retention window matched to your RPO
- 3.Create a throwaway preview: `npx convex deploy --preview-create restore-drill-<date>`
- 4.Restore the snapshot into it: `npx convex import backup-<date>.zip --deployment restore-drill-<date> --replace`
- 5.Assert recovery by querying restored tables (check row counts and spot-check real records against the source)
- 6.Review the drill report: confirm what was backed up, that restore was verified, and document the recovery runbook
- 7.Delete local snapshot copies when done (they contain real data); the drill preview auto-expires
Use cases
- Establish a user-owned portable backup copy alongside Convex's platform backups with a retention window
- Validate that your backup and restore process actually works before you need it in an emergency
- Test recovery procedures regularly without touching production
- Prove to compliance or audit requirements that backups are tested and verified
- Catch backup failures early by asserting row counts and sample records match the source
- Backend engineers managing Convex databases
- DevOps and infrastructure teams responsible for disaster recovery
- Teams with compliance or SLA requirements for data recovery
- Anyone running production Convex deployments who wants confidence in their backup strategy
convex-backup FAQ
Convex provides platform-level backups; this skill creates a user-owned, portable copy you control, with a schedule and retention window matched to your RPO, plus automated drills that prove recovery works.
A backup you've never restored is a hope, not a backup. Drills catch failures before a real disaster—a restore that lands 0 rows is a failed drill, found now instead of when you need it.
No. The drill restores into a throwaway preview deployment (or a fresh dev deployment), never production. The backup source and restore target are always different deployments.
You can run the drill against a fresh personal dev deployment instead and document that in the report. Preview Deploy Keys are a paid-tier feature for production-grade drills.
Match the schedule to your RPO (recovery point objective)—how much data loss is tolerable. For example, daily exports for most applications, or more frequent for high-change systems.
Full instructions (SKILL.md)
Source of truth, from get-convex/agent-skills.
name: convex-backup description: "Set up Convex backups and run a restore DRILL that proves recovery — snapshot, restore into a throwaway preview, assert the data came back — plus a schedule matched to your RPO and a gated recovery runbook."
<!-- GENERATED from convex-agents content/capabilities/convex-backup.json — do not edit by hand. -->Back up — and prove the restore works
Every backup story has two halves and most people only do the first: taking the backup, and proving you can get it back. This capability does both — it sets up regular snapshot exports and then runs a RESTORE DRILL that actually recovers the data into a disposable preview and asserts it's intact. The drill reuses migrate-rehearse's exact primitives (snapshot export → preview deploy → snapshot import) pointed at recovery instead of a forward change, so the safety net is tested, not assumed.
Workflow
- GUARD: deploy-guard — classify + announce the deployment being backed up (reading/exporting is safe; the drill's restore target is a throwaway preview, never prod).
- TAKE the snapshot:
npx convex export --path backup-<date>.zip(add--include-file-storageif the app stores files). This is the backup artifact; treat it as sensitive real data. - SCHEDULE it (the ongoing half): recommend a cadence matched to how fast the data changes and how much loss is tolerable (RPO) — e.g. a daily
npx convex exportvia CI/cron to durable storage the user controls, with a retention window. Convex's own platform backups exist; this adds a user-owned, portable copy. - RESTORE DRILL (the half almost nobody does — this is the point):
(a) PRECONDITION: a Preview Deploy Key as
CONVEX_DEPLOY_KEY(same requirement as migrate-rehearse; a paid-tier feature). If unavailable, drill against a fresh personal dev deployment instead and say so. (b) create a throwaway preview from the CURRENT code:npx convex deploy --preview-create restore-drill-<date>. (c) restore the snapshot into it:npx convex import backup-<date>.zip --deployment restore-drill-<date> --replace(import targets a deployment by NAME with--deployment; there is no--preview-nameon import). (d) ASSERT recovery: read the restored data back (MCPtablesfor row counts,data/runOneoffQueryfor spot-checks) and confirm the critical tables came back with the expected row counts and a sample of real records — a restore that 'succeeds' but lands 0 rows is a FAILED drill. Compare against the source's counts where available. - REPORT the drill result plainly: what was backed up, that the restore was ACTUALLY performed and verified (or that it FAILED and why — a failed drill is the most valuable output, found before a real disaster), the recommended schedule + retention, and the recovery runbook (the exact commands to restore to prod:
npx convex import backup.zip --replace --prod, gated by deploy-guard, with the post-snapshot-write-loss caveat stated). - HYGIENE: delete local snapshot copies when done (real data); the drill preview auto-expires. Never commit a backup file.
Rules
- A backup you have never restored is a hope, not a backup — always run (or offer to run) the restore DRILL, don't just take the export.
- The drill restores into a THROWAWAY preview (or dev), never prod; the restore target and the backup source are different deployments.
- Assert recovery, don't assume it: a restore that lands 0 rows is a FAILED drill — check critical-table row counts + a real-record sample against the source.
- A FAILED drill is the most valuable output — surface it loudly; that's the whole reason to drill before a real disaster.
- Schedule matched to RPO (how much data loss is tolerable); keep a user-owned portable copy alongside Convex's platform backups, with a retention window.
- Snapshots are sensitive real data: delete local copies when done, never commit them; the restore-to-prod runbook is deploy-guard-gated with the post-snapshot-write-loss caveat stated.
- Shares migrate-rehearse's snapshot+preview mechanics but aims them at RECOVERY, not a forward change — a forward schema change is migrate-rehearse.
Related skills
More from get-convex/agent-skills and the wider catalog.

convex-billing
Add Stripe billing and subscription management to Convex apps with checkout, webhooks, and server-side gating.

convex-cost
Preview Convex spend by ranking functions on bytes-read × call-volume, project cost curves, and name the cheapest fix.

convex-create-component
Build reusable Convex components with isolated tables and app-facing APIs.

convex-crons
Add recurring scheduled jobs to Convex apps with idempotent handlers.

convex-deploy-guard
Classify and announce Convex deployment targets before acting; gate production changes with fresh per-action consent.

convex-design
Design and build reactive, type-safe production backends on Convex with schema, auth, real-time, and LLM workflows.