# 15B Planning a Backup and a Restore

A backup is useful only if we understand what it contains and how the information can be restored when it is needed.
Before a database migration, I ask for a current export and record which environment, date, and application version it belongs to.
The file should be stored in an appropriate location with access that matches the sensitivity of the information inside it.
I also want to know whether the backup includes only database records or the uploaded files that those records refer to.
A record with an image path is not the same thing as the image itself, so these two resources may need separate handling.
The restore procedure should explain the required starting state and the effect it will have on information that already exists.
If the procedure replaces current data, that consequence needs to be understood before anyone uses it in a live environment.
We can then plan a suitable check that shows whether the restored application can actually read its records and associated files.
I keep the explanation connected to the actual project, because a generic instruction may omit a service or resource that this application requires.
A documented backup and restore process gives the team a clearer understanding of what has been protected and what still depends on another system.