# Restore a point before the bad change

Recovery from corruption requires more than choosing the newest backup. Rehearse how to identify a clean point and account for legitimate work after it.

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

## Create a visible timeline

In a safe test environment, create a known valid record, make a controlled damaging change and then create another legitimate record. Record the identities and order of these events.

Choose a failure that matches the service's recovery concern, such as an incorrect bulk update. Do not rely on random corruption that makes the expected result impossible to define.

The desired recovery state should exclude the damaging change while making clear what happens to the later legitimate work.

## Select the recovery target deliberately

Use the backup and database platform's supported recovery mechanism. For point-in-time recovery, understand the required base backup and change-log history rather than assuming a timestamp alone is sufficient.

Restore into an isolated destination and inspect the known records. Confirm where the recovered state sits relative to the damaging transaction.

If the target selection is ambiguous, resolve it using transaction or application evidence. A timezone conversion mistake can place the restore on the wrong side of the event.

## Account for later valid work

The legitimate record created after the damaging change may not exist in the recovered state. Identify how the application would recover or reconcile such work in the real scenario.

Possible sources include an independent operation ledger or an external system's confirmed records, depending on the design. Do not assume replay is safe without duplicate and dependency handling.

Distinguish what the drill restores automatically from what requires a business decision or manual repair. That distinction determines the actual interruption and data-loss exposure.

## Verify the repaired workflow

Run the application against the recovered data and complete a relevant task. Check related records, attachments and external references.

Measure the time spent locating the clean point separately from data restoration. During an incident, investigation may take longer than the restore command itself.

Keep the selected point, evidence and unresolved limitations in the result. A successful drill demonstrates a specific recovery capability. It should not imply that every future corruption event can be reversed without losing or reconciling subsequent work.

## Sources

- [PostgreSQL: continuous archiving and recovery](https://www.postgresql.org/docs/17/continuous-archiving.html)