Skills

Skill 6 of 33

Convex Backup

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…

3 minutes · 577 words · 3 sections

Install

$ npx skills add get-convex/agent-skills --skill convex-backup

$ npx skills add get-convex/agent-skills

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

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-storage if 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 export via 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-name on import). (d) ASSERT recovery: read the restored data back (MCP tables for row counts, data/runOneoffQuery for 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.

About this skill

Trigger

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.

The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/get-convex/agent-skills, branch main, last pushed 9 September 2026.

Licence

Apache-2.0 — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

33 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. One layout observed: skills/*/SKILL.md.

Issue colours

Resolved from a deterministic hash of the owner name. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Shifted “3 headings” from h1 to h2 so the skill title is the only h1.

Spec compliance

Every skill satisfies the Agent Skills specification’s frontmatter rules.

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /get-convex/agent-skills.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

Back up — and prove the restore works

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-storage if 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 export via 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-name on import). (d) ASSERT recovery: read the restored data back (MCP tables for row counts, data/runOneoffQuery for 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.

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.