List the application code, database, uploads, secrets, queue state and external services. Identify the required recovery point and acceptable recovery time for the site.

1. Select a backup set and matching application release. Record what each backup includes and what must be obtained separately.

2. Restore into an isolated destination with test credentials and customer-facing actions disabled. Prevent restored jobs from sending real messages or repeating live transactions.

3. Reconnect the restored database, upload store and protected configuration. Run any necessary version-compatible startup or recovery steps.

4. Check representative historical records, recent expected data, private downloads and a controlled write. Verify integrity as well as the homepage.

5. Record the actual recovery time, missing dependencies and corrective actions. Keep the procedure and access references current after architecture changes.

Confirm the restored application is usable and contains data from the intended point. Verify the test did not alter production DNS, customer data or external services.

If the database restores but attachments are missing, the backup scope did not include the file store. Correct the backup design rather than treating the test as successful.

• Rolling back application files without losing new user data
• Keeping Django user uploads separate from static assets
• Preserving Active Storage uploads during deployment
• Documenting the production runtime and recovery procedure

• PostgreSQL backup and restore
• Rails Active Storage