AutoGineer
Generated banner for Convex Backup
Generated logo for Convex Backup

Convex Backup

ConvexOfficialPublished by Convex

  • Skill
  • Workflow
  • Cloud and DevOps
  • Apache-2.0
  • No issues found
Download ZIP

From the author

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 description by Convex

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for managing Convex data backups. It goes beyond simple snapshot creation by implementing a mandatory restore drill, which validates the integrity of the backup by importing it into a temporary preview environment and asserting that the data is correctly restored. The process includes scheduling recommendations based on Recovery Point Objectives (RPO) and provides a gated recovery runbook for production restoration.

What it does

  • Generates snapshot exports of Convex data.
  • Automates a restore drill into a temporary preview deployment.
  • Validates restored data by comparing row counts and record samples against the source.
  • Provides a recovery runbook for production restoration.
  • Recommends backup schedules based on data change frequency and RPO.
  • Ensures sensitive backup artifacts are handled securely and deleted after use.

When to use it

  • When you need to establish a reliable, user-owned backup strategy for Convex.
  • When you want to verify that your backup process actually works before a disaster occurs.
  • When you need to define a recovery procedure for production data.
  • When you need to align your backup frequency with specific data loss tolerance requirements.

Advantages

  • Validates backups through actual restore testing rather than relying on assumptions.
  • Identifies potential recovery failures before they impact production.
  • Provides a clear, gated process for production restoration.
  • Maintains portable, user-controlled copies of data.

Usage examples

“Set up a daily backup schedule and run a restore drill for my Convex project.”
The agent will configure a daily export task, execute a restore into a temporary preview, and report the verification results of the restored data.
“Create a recovery runbook for my production database.”
The agent will provide the specific commands and safety procedures required to restore a backup to the production environment.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/convex/convex-backup/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip convex-backup.zip -d .agents/skills

Documentation by Convex

<!-- 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

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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).

  6. 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.

Files

SKILL.md

<!-- 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

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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).

  6. 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.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Convex
Publisher
Convex (Official)
Source
convex/agent-skills · skills/convex-backup · commit f60629d
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Convex or Convex.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download convex-backup.zip