Backup & Disaster Recovery

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €29/mo; daily backups, 30-day retention, recovery SLA (4 hours)

Generated from docs/plan/paid/backup-disaster-recovery/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need daily backups and recovery guarantees. This feature provides automated daily backups with encryption, 30-day retention, and a recovery SLA (restore within 4 hours).

The problem

If I lose my data, my business is done. I need daily backups and a way to restore to a specific date if something goes wrong.

What it does

• Automated daily backups: full database snapshot once per day (UTC time configurable), encrypted at rest
• Backup retention: keep 30 daily backups (rolling window), delete older backups automatically
• Backup storage: encrypted backup stored in an S3-compatible bucket (AWS S3, DigitalOcean Spaces, MinIO)
• Backup metadata: timestamp, size, MD5 checksum, full/incremental flag, schema version
• Recovery endpoint: admin can list available backups, download backup file, restore from backup (blocking operation: site read-only during restore)
• Point-in-time restore: restore to any backup in retention window (not arbitrary timestamp, but to one of the daily snapshots)
• Backup verification: test backup integrity by checking MD5 checksum; surface checksum errors to admin
• Disaster recovery runbook: admin can export instructions (where backups are stored, how to restore), printable
• API endpoints: list backups, restore backup, verify backup, download backup (encryption key required)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Continuous replication (real-time backup to secondary region) — that is separate infrastructure and beyond CMS scope
• Incremental backups (only changed data) — daily full snapshots only; incremental is an optimization for future
• Backup compression (gzip) — backups are encrypted; compression adds little benefit
• Backup encryption key management — merchant provides their own encryption key (stored securely in env); we do not rotate or manage keys
• Automated recovery (auto-restore if primary fails) — merchant must initiate restore manually to avoid data loss from accidental deletion

Data model

New entity: Backup {id, created_at, size_bytes, checksum_md5, status (success/failed/verifying), storage_path (S3 key), schema_version, retained_until, backup_type (full)}. Schema changes: none to user-facing entities; only audit/metadata.

API

• GET /api/backups — list all available backups (admin only)
• GET /api/backups/:id — fetch backup metadata (admin only)
• POST /api/backups/:id/verify — run integrity check (admin only, async)
• GET /api/backups/:id/verify-status — check verification result
• POST /api/backups/:id/restore — initiate restore (admin only, blocking, requires confirmation)
• GET /api/admin/recovery-info — download recovery runbook (admin only)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Backup & Recovery panel: list of available backups (date, size, status). Click backup to view metadata and verify button. Restore button opens confirmation dialog (‘site will be read-only during restore, ~5 min, continue?’). Verification status shows for each backup (green = verified, yellow = verifying, red = failed checksum). Recovery runbook: generated document with backup location, encryption key fingerprint, and restore instructions.

The seam — why this is paid

Core owns the backup scheduling, verification, and restore logic. Paid layer owns encryption key management (HSM integration, key rotation, access audit), backup SLA compliance (guaranteed availability of backups from the past 30 days, restore within 4 hours), and replication/multi-region disaster recovery (if merchant pays for DR tier).

Support commitment: backup frequency SLA, recovery time objective (RTO), point-in-time restore

Dependencies

• S3-compatible storage API (AWS, DigitalOcean Spaces, MinIO, or equivalent; merchant configures via env vars)
• Encryption library (assume available; e.g., tweetnacl.js for AES-256-GCM)
• Scheduler (core must run backup job once per day)
• Database schema export capability (ability to dump all data in portable format)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A backup is created daily at the configured UTC time; it is encrypted and uploaded to S3
• Backup metadata (timestamp, size, checksum) is stored in the database
• An admin can list backups; the list shows dates back 30 days
• An admin can verify a backup; MD5 checksum is recomputed and compared; status updates
• A failed backup (storage error, encryption failure) is logged with error; status is ‘failed’, no retry is attempted immediately
• An admin can restore from a backup; the site is marked read-only, the backup is downloaded and decrypted, data is restored, site is reopened
• During restore, if decryption fails (wrong key), restore is aborted and error is shown
• A backup older than 30 days is deleted from S3 automatically on the day after the 30-day mark

Risks

Restore is a destructive, blocking operation; if something goes wrong mid-restore, the site is left in an inconsistent state. Test restore on a staging environment before doing it on production (recommend in runbook). Encryption key loss means backups are unrecoverable; keys must be stored separately and securely (not in the database, not in git). Backup size can grow large; storage costs must be documented. S3 credentials must not be logged; sanitize logs that may contain secrets.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.