Sathira Sri Sathara
5158c52db5
- Introduced new endpoints for account overview, analytics, and metrics. - Implemented authorization matrix and backup/restore documentation. - Added smoke test script and updated package dependencies. - Created detailed production checklist and runbook for deployment. - Established cron operations and notification event matrix documentation. - Enhanced security and validation audits for analytics and metrics services. - Added unit tests for analytics and metrics functionalities.
12 lines
1.2 KiB
Markdown
12 lines
1.2 KiB
Markdown
# Backup and Restore
|
|
|
|
Use encrypted, access-controlled backups with retention tiers and regular restore drills. Do not place credentials on command lines; use a protected client option file or secret injection.
|
|
|
|
1. Quiesce high-risk writes or capture a transactionally consistent MySQL backup (`mysqldump --single-transaction --routines --triggers`) and record schema migration state.
|
|
2. Enable S3 versioning, lifecycle rules, encryption and cross-account/region recovery appropriate to policy. Database-only recovery does not restore uploads/documents.
|
|
3. Treat Redis as ephemeral/reconstructable for queues/cache but security-sensitive for OTP/session challenges. Redis loss may invalidate challenges and lose queued work; MySQL remains business truth.
|
|
4. Restore MySQL into a temporary isolated database, run consistency queries, compare row counts/totals, verify migrations, and test application reads before promotion.
|
|
5. Recover in order: MySQL, object storage, Redis, API, workers, single cron scheduler, reverse proxy, then smoke/E2E checks.
|
|
|
|
Rollback after live commerce writes is restore/forward-fix based; do not assume destructive migration `down` functions are safe. Define RPO/RTO, backup owners, retention, restore approval and audit evidence before go-live.
|