What should you preserve?
MySQL holds primary data, but durable storage is not a backup. Treat Redis as rebuildable data unless you have confirmed suitable persistence and recovery. Uploaded files also need durable storage and a backup plan; do not assume runtime files survive redeployment.
Keep source, migration versions and configuration needed to rebuild the app. Store secrets and protected backups separately from the original resource with appropriate access controls.
Make a backup plan
- Decide how much recent data you can afford to lose and how long the app can be offline.
- Check your plan or support for backup schedules, retention and restore procedures. Do not assume a backup exists until confirmed.
- If exporting MySQL yourself, use tools compatible with the server version and account permissions. Check export consistency while the app writes data and keep passwords out of shell history.
- Keep protected backups in an independent location and monitor whether each backup succeeds. Back up before migrations that can lose data.
Practice recovery
Flash Deploy rollback changes the app version only. An older release may fail after a migration removes columns or changes data. Check schema compatibility and use a separate data recovery plan.
- Choose a dated backup and a separate test destination; do not overwrite production.
- Restore through the supported procedure and compare tables, record counts and representative business data.
- Point a test app at the restored data and verify login, reads and writes. Record the actual recovery time.
- During an incident, agree on the recovery point and how to handle newer writes before switching endpoints or overwriting data.