Point-in-time recovery
Point-in-time recovery is a restoration technique that uses a backup and recorded changes to restore a system to a selected moment.
MongoDB 8.0 in Action, Third Edition
Point-in-time recovery is restoration of database state to a specified moment by applying recorded changes to a backup baseline.
- How it is used
- Restores an Atlas cluster to a selected moment within a continuous-backup retention window.
- How deep it goes
- Explains oplog capture and shows a CLI restore command, but does not detail the restore engine's internals.
- Examples
- Shows an Atlas CLI point-in-time restore targeting another cluster and discusses recovery from accidental deletion or corruption.
- What you can do after
- Operate/configure it by enabling continuous backup and starting an Atlas CLI restore for a chosen UTC time.
Read how MongoDB 8.0 in Action, Third Edition explains point-in-time recovery →
PostgreSQL Mistakes and How to Avoid Them
Point-in-time recovery is a database restoration technique that replays archived transaction logs to recover a system to a selected moment or transaction.
- How it is used
- Restores a damaged PostgreSQL cluster to the point before a known bad transaction.
- How deep it goes
- Explains base backups, WAL replay, archiving requirements, backup incompatibilities, and operational automation without detailing recovery commands.
- Examples
- Uses an afternoon DROP TABLE after a morning backup and a Barman-based redundant backup architecture.
- What you can do after
- Operate/configure it by creating physical base backups, archiving WAL continuously, selecting a recovery target, and testing full restores.
Read how PostgreSQL Mistakes and How to Avoid Them explains point-in-time recovery →
100 SQL Server Mistakes and How to Avoid Them
Point-in-time recovery is restoration of a database to a selected moment within a sequence of backed-up transaction-log records.
- How it is used
- Guides backup planning and restoration when recovery must reach a selected moment rather than only a backup boundary.
- How deep it goes
- Explains restore chains, recovery-model limits, and operational safeguards, but does not detail the complete restore command sequence.
- Examples
- Uses MarketingArchive, a bulk-logged ETL window, transaction-log backups, and RESTORE WITH VERIFY ONLY.
- What you can do after
- Operate/configure recovery models and backup checks while preserving the intended recovery point objective.
Read how 100 SQL Server Mistakes and How to Avoid Them explains point-in-time recovery →
Related concepts
- transaction log backupused by · A transaction log backup is a saved sequence of database transaction-log records used to support recovery and manage log space.
- bulk-logged recovery modelcontrasts with · The bulk-logged recovery model is a SQL Server recovery configuration that minimally logs certain bulk operations while limiting point-in-time recovery.
- continuous backupuses · Continuous backup is the ongoing capture or archival of data changes so a system can be restored to a recent point after disruption.
- transaction loguses · A transaction log is an ordered record of transactions, transaction-related events, or resulting data changes, maintained as a history and often used for tracking or recovery.
- oploguses · The oplog is MongoDB's ordered operation log of successful data modifications, used for replication and recovery.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.