What is point-in-time recovery?
Point-in-time recovery is a restore that returns a database, virtual machine or file system to its state at a chosen past moment, such as just before corruption or an accidental deletion. The result is usable only if it is consistent, meaning data files and transaction logs agree on that same instant.
What does transactional consistency mean?
A database records changes as transactions, groups of writes that either all take effect or none do. A transactionally consistent restore contains every transaction committed before the target moment and none of the ones still in progress. Mixing files from different moments breaks that rule: a restored order table might list an order whose payment record is missing. The database may refuse to start, or it may start and serve quietly wrong data.
How does a database reach an exact moment?
Most databases combine two things. A full or incremental backup supplies a starting state, and the transaction log, which records every change in order, is replayed forward from that state. Replay stops at the requested timestamp, so the restore can land on a moment between two backups, down to a single transaction. The reach is limited by the logs: a gap in the retained log ends the replay at the gap.
How do crash-consistent and application-consistent copies differ?
| Crash-consistent | Application-consistent | |
|---|---|---|
| How it is taken | Disk captured as it stands, as after a sudden power loss | Application flushes pending writes and pauses first, a step called quiescing |
| State on restore | Incomplete transactions present, resolved by log replay at startup | Clean, no replay needed |
| Cost on the source | None | A short pause |
Many environments take application-consistent points less often and crash-consistent points in between, accepting longer startup for the extra coverage.
Which settings decide whether a moment is reachable?
- Spacing. The gap between recovery points, or the continuity of the log, sets how close a restore lands to the target. The recovery point objective states how much loss is acceptable, and continuous data protection narrows the gap to seconds.
- Depth. Retention decides whether any point exists from before the problem began. Intrusions often start well before they are noticed, so retention policy design sets depth against detection time.
- Integrity. A point is useful only if nobody altered or deleted it afterward. Storing points under S3 Object Lock keeps the history intact against a stolen administrator login.
Frequently asked questions
Is point-in-time recovery the same as restoring the latest backup?
No. The latest backup is one possible point. Point-in-time recovery lets a team pick an earlier one, which matters when the latest backup was taken after the damage.
Can a crash-consistent copy be trusted for a database?
Usually, because the database replays its log at startup to resolve unfinished transactions. Applications without that recovery step are safer with application-consistent copies.
What decides how close to the target moment a restore lands?
The spacing of recovery points, or an unbroken transaction log. With hourly points and no log, the nearest point can be up to an hour away.
Related terms
- Recovery point objective: the loss target that sets point spacing.
- Continuous data protection: second-level recovery points over a short window.
- Retention policy design: how depth is chosen.
- Immutable backup: keeping recovery points unaltered.
- Ransomware recovery: choosing a point before the intrusion.