# Keep older recovery points usable after an application release

A schema or encryption change can make retained backups harder to use. Test recovery across the release boundary before retiring compatible code and keys.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Identify what the release changes

List changes to schema, data encoding, file formats, encryption references and configuration. Determine which of them affect reading older data.

A backup taken before the release may remain valid at the storage level while requiring an older application or a specific migration sequence.

Record the supported recovery path for that point. It should identify artefacts that must remain available, including application images and migration tooling.

## Test both sides of the boundary

Restore a representative pre-release point into isolation and bring it forward through the intended procedure. Then test a post-release point with the current application.

Verify meaningful historical records rather than only startup. A changed field interpretation can produce incorrect results without an exception.

Include attachment and encryption access. Rotating active configuration should not accidentally remove the ability to read data still covered by the recovery policy.

## Coordinate retirement decisions

Do not delete old images, keys or migration definitions solely because the live deployment no longer uses them. Check whether retained recovery points still depend on them.

Where the platform supports another tested path, document it before removing the old dependency. Keeping every artefact forever is not the only option, but removal needs evidence.

Separate active rollback support from backup recovery support. The previous application may no longer be a live rollback target while still being part of a restore sequence.

## Update the routine drill

Add the changed dependency to the periodic restoration exercise. Choose recovery points that exercise the supported age range rather than always selecting the newest one.

Record the application and migration versions used in each result. This makes later failures easier to compare with known working combinations.

The release is ready when current operation and the agreed historical recovery path both work. A successful deployment should not quietly reduce recoverability without a deliberate decision about that tradeoff.

## Sources

- [PostgreSQL: continuous archiving and recovery](https://www.postgresql.org/docs/17/continuous-archiving.html)
- [AWS Backup: restore testing](https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html)