About Backups

App-level (this page): Daily JSON snapshot of the MRP tables listed below, with a manifest (schema version, row counts, per-table checksums). Stored in Supabase Storage; download links last 24 hours.

Restoring is a deliberate operator action, not a button here. Use mrp/ops/restore-backup.mjs, which is dry-run by default and refuses to write to the production project. Until a restore drill has been run against a fresh database and recorded, treat these archives as unproven — see mrp/ops/RESTORE.md.

Supabase native (behind the scenes): Supabase Pro also runs nightly physical Postgres backups at the database level. Those are managed from the Supabase dashboard, under Database → Backups on the Scenta Master project, and are the right tool for full-database disaster recovery.

Tables in app-level snapshots (schema version 2), in restore order: app_settings, inventory_locations, vendors, raw_goods, components, finished_goods, shopify_products, variants, cogs, bom_revisions, bom_lines, purchase_orders, po_lines, po_receipts, manufacturing_orders, mo_assignees, mo_time_logs, production_runs, finished_goods_stock, raw_goods_movements, components_movements, inventory_movements, raw_goods_import_log, sync_log.

Excluded on purpose: backup_log (the index of backups — restoring it would overwrite the record of the restore) and the views suppliers, activity_log, finished_goods_summary (derived, rebuilt by the schema). Before schema version 2 the snapshot named the suppliers view and never captured the vendors table, and omitted all movement history, purchasing and manufacturing — archives taken before this change cannot be fully restored.