A deployment tool offers a reassuring button: roll back. Before relying on it, ask which thing moves backward. The application version, database contents, uploaded files, and runtime configuration may have different recovery paths.
Write down the combinations
Take a hypothetical notes app. Version one stores a title and a body. Version two introduces an archived state. After deploying version two, you discover a problem and return to the earlier application.
Can version one read the data that version two already wrote? It might ignore the new field, reject the record, or display an unexpected subset. The answer depends on the implementation. The fact that old code starts successfully does not settle it.
| Application | Data state | Question to test |
|---|---|---|
| Previous version | Before migration | Does normal reading still work? |
| Previous version | After migration | Can it interpret new records? |
| Current version | Restored backup | Are records and files consistent? |
This table is a planning example, not a record of a completed restore.
Choose a recoverable point in time
A database backup and a file backup taken at different times can leave records pointing to attachments that are absent. Define which data, files, and configuration must be restored together.
Recovery features also have product-specific behavior. Amazon RDS point-in-time recovery, for example, creates a new DB instance rather than modifying the source instance. That still leaves application reconnection and end-to-end validation to plan.
Practice on a bounded example
Use non-sensitive test data to rehearse the intended path. After restoration, check reading, writing, attachments, and permissions. Record the backup identity, procedure version, and checks that passed.
If the test uses a tiny data set, preserve that limitation. A quick rehearsal does not establish a production recovery time. Measure the larger case before promising one.
한국어 글: 코드는 롤백했는데, 데이터는 어떻게 되는 걸까