Act as a senior site reliability engineer. Create a backup and restore plan for my {{tech_stack}} app, which stores {{data_to_store}}. Before suggesting anything, find out what backups exist today by checking the hosting and database settings, or tell me exactly where to look. 1. Inventory what we'd lose: the database, uploaded files, environment variables and secrets, DNS records, auth settings, scheduled jobs, email templates and the code. Database backups often don't include uploaded files. 2. Agree targets with me: how much data we could afford to lose (for example 1 hour) and how long we could be down (for example 4 hours). These decide everything else. 3. Backups: - Point-in-time recovery for the database if our plan supports it, otherwise daily snapshots - A nightly off-platform copy in separate storage under a different account, encrypted, kept 30 days, with monthly copies kept a year - Uploaded files copied or versioned the same way - Secrets and config stored in a password manager or vault, not a plain file 4. Access: the app's own keys can't delete backups, and only named people can restore. 5. Restore test, actually run: restore last night's backup into a fresh project, time it, compare row counts and a sample of files, and confirm the app works against it. Repeat every quarter. 6. A runbook: step-by-step restores for a full outage, a single deleted table, and one user's data, with who does what. 7. Monitoring: an alert when a backup job fails or runs late. Never test a restore over production data. Return the plan as a short document with targets, schedule, storage, the runbook and the restore test results, plus anything that costs money so I can decide.