Platform backup & restore

Definición

Super Admin → Backups → [Run full | Run hourly | Verify | Sync media] → Restore tab prepares plan → CLI restore-mongodb.sh

Platform Backup & DR dumps MongoDB (hourly + daily full), optional config/ops snapshots, and optional R2→secondary media sync. Super Admin can trigger and verify runs. Full database restore is intentionally CLI/runbook-only — the UI prepares and verifies a plan but does not execute in-app mongorestore against production.

Compatibility

• Super Admin role required for UI triggers.
• BACKUP_ENABLED=true (default) and MongoDB Database Tools (mongodump / mongorestore) on the API host.
• BACKUP_DIR must be writable by the API process user (see setup-backup-dir.sh).
• Off-site dump mirror: BACKUP_REMOTE_*. Media secondary: BACKUP_MEDIA_SYNC_ENABLED + secondary bucket credentials.
• Encryption is not implemented — do not set BACKUP_ENCRYPT expecting it to work.

Path & jobs

Super Admin → /super-admin/backups
  Overview / History / Restore / DR tabs
  POST /platform/admin/backups/run
  POST /platform/admin/backups/run-hourly
  POST /platform/admin/backups/verify
  POST /platform/admin/backups/sync-media

Cron (Asia/Dhaka):
  :00  hourly mongodump
  02:00 full daily + store snapshots + trash purge + verify
  03:00 media sync (if enabled)
  04:00 config/ops snapshot

Behavior

• Successful runs appear in History with path, size, and status.
• Verify checks dump integrity (size + optional staging dry-run when configured).
• Restore tab: select a successful run → optional verify → optional safety full backup → checklist → plan ready.
• Applying the restore uses ./scripts/restore-mongodb.sh on the server (type RESTORE to confirm).
• JSON-only fallback dumps (when mongodump is missing) are not mongorestore-compatible — fix Tools install first.

How to run a platform backup

1. Confirm BACKUP_DIR exists and is owned by the API user (setup-backup-dir.sh if EACCES).
2. Open Super Admin → Backup & DR.
3. Use Hourly now for a quick continuity dump, or Run full for daily-style backup.
4. Open History and confirm status = success and path is set.
5. Click Verify (latest or selected run) and confirm ok.
6. If media DR is configured, run Sync media (R2 → secondary).
7. Optionally confirm off-site remote sync is configured for 3-2-1.

Prepare a restore (UI)

1. Open Backup & DR → Restore.
2. Choose source: History (recommended), and select a successful run.
3. Keep Verify on; enable Safety backup unless you already have a fresh dump.
4. Review mode (full / database / media / config) — UI documents intent; CLI applies DB restore.
5. Click prepare — wait until plan is ready.
6. Enable Maintenance mode in Platform Settings before applying a production restore.
7. Follow the Disaster Recovery tab / runbook on the server — do not skip staging tests.

Apply restore (CLI runbook)

./scripts/restore-mongodb.sh /var/backups/bonikbiz/daily/YYYYMMDD_HHMMSS
npm run backup:verify

1. SSH to the API host (or staging host for a test restore).
2. For staging: set STAGING_MONGODB_URI / restore target and practice first.
3. Run: ./scripts/restore-mongodb.sh /var/backups/bonikbiz/daily/<stamp>
4. Type RESTORE when prompted.
5. For single collection: pass --ns=db.collection or use mongorestore --nsInclude.
6. If images were lost from primary R2, sync secondary → primary per runbook.
7. Restart API/PM2, reload Nginx, smoke-test products, orders, uploads, checkout.
8. Record actual RTO and issues in the ops wiki.

Examples

Common errors

• EACCES mkdir BACKUP_DIR — fix ownership with setup-backup-dir.sh; never leave a root-only path.
• mongodump unavailable — install MongoDB Database Tools; avoid relying on JSON fallback.
• Verify failed — do not restore that run; re-run backup and inspect disk space.
• Restore plan ready but DB unchanged — you still need the CLI script on the server.
• Media still missing after DB restore — configure/run secondary media sync.

Véase también

• Backup & Recovery overview
• Store Backup & Recovery
• Announcements, monitoring, backups, users