Scheduled Backups

Free — GPL coresize Lplanned, not built

Generated from docs/plan/core/scheduled-backups/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

AstroBaaS automatically backs up the database (products, orders, customers, settings) on a configurable schedule (daily, weekly). Backups are encrypted and stored off-site; merchants can view backup history and confirm recent backups exist. Core owns the backup scheduler and encryption; this is infrastructure, not a paid feature.

The problem

Merchants have no backups; a server crash, ransomware attack, or data corruption loses years of customer data. Automated, encrypted backups are essential infrastructure.

What it does

• Automated backup scheduler: daily or weekly backups (merchant chooses)
• Backup storage: backups are encrypted and stored off-site (S3, separate server, or merchant-supplied location)
• Backup naming: backups are named by timestamp (backup-2026-09-03-02-00-00.tar.gz.enc)
• Encryption: backups are encrypted with AES-256; encryption key is separate from database
• Backup history UI: admin sees list of all backups, backup size, encryption status, download link
• Retention policy: backups older than 30 days are auto-deleted (configurable)
• Backup verification: system verifies backup integrity on restore (no corrupted backups)
• Notification: admin gets email confirming backup completion or failure

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.

• Backup staging: we don’t create intermediate copies; backup is created once and stored.
• Point-in-time recovery: we restore entire backup, not individual records (granular PITR is premium feature, separate).
• Compliance certifications: we encrypt at rest and in transit; merchant must verify for compliance (SOC 2, ISO 27001 are merchant’s responsibility).

Data model

New document: backup_record { backupId, timestamp, size, status (success, failed), encryption (aes256), storage_location, retention_delete_at, checksum }.

API

• GET /api/backups -> list of backups with size, timestamp, status
• GET /api/backups/{backupId}/download (admin only, returns encrypted backup file)
• POST /api/backups/config { schedule: ‘daily’ or ‘weekly’, retention_days } (admin only)
• GET /api/backups/config (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

Admin sees: backup schedule (daily/weekly), retention policy (days), list of backups, backup status (success/failed), manual backup button, next scheduled backup time.

The seam — why this is core

Core owns backup scheduler, encryption, storage, and restore process. No paid seam; this is infrastructure.

Core owns the interface + honest backup scheduler; data protection is infrastructure, not a per-country obligation or support commitment.

Dependencies

• database subsystem (existing)
• encryption subsystem (existing)

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.

• Backup is created daily at 2 AM UTC; filename includes timestamp
• Backup file is encrypted with AES-256; decryption key is separate from database
• Admin sees backup history showing size (e.g., 500 MB), timestamp, status (success)
• Backup older than 30 days is auto-deleted (default retention is 30 days)
• Admin can manually trigger backup from admin UI
• If backup fails (disk full, API error), admin receives email notification
• Backup checksum is verified before delete; corrupted backups are preserved for inspection

Risks

If encryption key is stored next to database, backup is not secure (separate key storage essential). If backups are stored only locally, ransomware deletes both database and backups. If retention deletes too aggressively (e.g., 7 days), merchants cannot recover from old data loss. If backup verification is skipped, corrupted backup is stored and restore fails at worst time. If email notification is not sent, merchant doesn’t know backup failed.

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.