platepilot

Backup and restore runbook

• Status: Targets accepted; production implementation pending
• Recovery point objective: 15 minutes
• Recovery time objective: 4 hours
• Target database backup retention: 35 days

M0 reality

Docker volumes persist local PostgreSQL and LocalStack state across ordinary restarts. They are not encrypted production storage, replicated backups, or evidence that recovery objectives can be met. Only synthetic data belongs in them.

No M0 customer-data backup or restore operation exists.

Future backup scope

The following is PENDING:

Data	Intended protection
Relational account, household, diary, entitlement, job, and audit references	Managed database continuous recovery/snapshots sufficient for the 15-minute RPO; 35-day retention
Meal-photo objects	Versioned lifecycle fallback expires current/noncurrent quarantine/ and sanitized processing/ objects after 1 day; opted-in sanitized diary/ copies expire after 365 days
Queue messages	Durable queue and dead-letter handling, not treated as the system backup
Infrastructure definitions	Reviewed source and immutable release artifacts
Provider state	Reconciliation records and provider procedures; never assumed restorable by PlatePilot
Secrets	Managed rotation/recreation process; secrets are not copied into backup archives or runbooks

Application logs target 30-day retention and security audit events target 90 days, subject to privacy/security review. Logs must not contain photo data or sensitive payloads.

Future restore procedure

Every operational detail is PENDING until resources exist:

1. Incident commander approves a restore and identifies affected data/time.
2. Freeze or isolate writes and queues; record current state.
3. Select a restore point within the retention window and validate its integrity in an isolated environment.
4. Restore relational data without overwriting the only healthy copy.
5. Reconcile object references, expiry metadata, queue jobs, entitlements, and provider callbacks.
6. Verify per-adult and household authorization before traffic.
7. Check deletion requests after the restore point so erased data is not unintentionally made active again.
8. Validate critical read/write/manual paths and monitor after controlled traffic restoration.
9. Record achieved RPO/RTO and securely remove temporary restore data.

Do not invent commands or resource names before the managed service and access model are approved.

Restore drill acceptance

• Restore uses least-privilege, audited access
• 15-minute RPO and four-hour RTO are measured
• Authorization and household isolation tests pass
• Photo expiry and prior deletion requests remain effective
• Queue replay is idempotent and bounded
• Export/deletion evidence is reconciled
• Temporary copies are removed
• Findings have owners and dates

Run a restore drill before beta and on a cadence approved by operations/security.