feat(deploy): Phase 3-4 of DB migration -- retire manual backup as primary, restore RDS alarms
Phase 3: - Found and fixed a live bug: production's deploy/backup.sh cron still docker exec'd into musehub_postgres, which Phase 2 stopped. It had already silently produced an empty backup file that same morning. Rewrote to connect via DATABASE_URL (works against RDS or self-hosted Postgres identically) instead of exec'ing into a specific container. - Changed backup.sh's cron from daily to weekly on production -- RDS's own native daily backups + PITR now cover day-to-day recovery, so this is a secondary belt-and-suspenders backup, not the primary mechanism. Not added to staging (non-critical, RDS-native backups judged sufficient). - Removed the broken daily cron, installed the new weekly one, test-ran it live against RDS to confirm it works end-to-end.
Phase 4: - Restored a real AWS/RDS DatabaseConnections CloudWatch alarm for both environments (musehub-{env}-db-connections-high) -- #160 removed this believing it was inapplicable with no RDS anywhere; both environments genuinely run on RDS now. Ran cloudwatch-alerts.sh for real against both, verified both alarms live via describe-alarms. - Corrected Section 5's SPOF finding to be precise: RDS closes the no-managed-backups/patching gap but does not eliminate single-AZ SPOF -- both instances remain single-AZ, Multi-AZ is a real pending decision. - Updated pre-launch-checklist.md and Section 8's backup docs to match.
Semantic Changes
16 symbols
Files Changed
~6
1061 in snapshot
0 comments
muse hub commit comment sha256:3404c581bd9905d4997ed46a04402586460f9a892da0b29fd9b23de6577e39c9 --body "your comment"
No comments yet. Be the first to start the discussion.