Recovering code and recovering data are different decisions.
A release can fail because of application behavior, configuration or changed data. Returning to a previous image addresses only part of that picture. It may leave database migrations and records exactly as they are, which can make the previous version incompatible.
Imagine the shop’s new checkout release displays the wrong shipping message. Reverting the application might be enough. If an operation removed customer records, an older application image would not recreate them. Identify what changed before choosing the recovery action.
A recovery point has a time attached to it.
A backup represents information recoverable from a particular point or period. Restoring an earlier state can leave later legitimate changes absent. Some database systems can combine a base backup with retained change logs to recover to a selected point in time, subject to the available recovery chain.
The timeline below separates a code release from order data. Compare rolling back the application with restoring a saved data point. The numbers are illustrative, but the trade-off is real: “go back” needs a target and a clear account of what happens to changes made after it.
Reference: PostgreSQL: point-in-time recoveryDescribe acceptable loss and acceptable downtime.
A recovery point objective, or RPO, expresses the amount of data loss an organization is prepared to tolerate, usually as a time window. A recovery time objective, or RTO, expresses how quickly service should be restored. These are goals used to shape and test the plan, not properties guaranteed by a backup label.
For the shop, losing a day of orders and losing a day of analytics may have very different consequences. List the important data classes separately. Then time a realistic restore, including provisioning, importing, checking permissions and reopening the service—not just downloading the backup file.
| Concept | Question | Example planning statement |
|---|---|---|
| Recovery point | How much recent change can be lost? | Orders need a short recoverable gap |
| Recovery time | How long can service be unavailable? | Checkout has a defined restoration target |
| Retention | How far back must we recover? | Keep enough history to detect late mistakes |
| Restore test | Does the plan actually work? | Rebuild and verify in isolation |
Choose a method that understands the data.
Database backup methods have consistency and restoration requirements. A logical export captures data in a form the database can restore; physical and log-based approaches have different constraints. Copying live database files arbitrarily is not interchangeable with an engine-supported backup procedure.
Keep the recovery instructions with the backup inventory: engine version, encryption keys, access requirements and restore order. Ensure that a problem affecting production credentials or storage cannot casually destroy every recovery copy. The backup destination belongs in the architecture diagram too.
Reference: PostgreSQL: logical dumps and restorationProve recovery before an incident asks you to.
Restore into an isolated environment and inspect meaningful outcomes. Can the application open an order? Are uploaded documents present? Do permissions and external integrations behave as expected? Disable real notifications and payments in the test environment so the exercise does not affect customers.
Record what the test restored, how long it took and any missing dependencies. Update the procedure after application or storage changes. A successful scheduled backup is useful evidence, but a successful, checked restoration is much closer to the outcome you need during an incident.
Common questions.
Is a replica enough instead of backups?
No. A replica can also receive unwanted changes. Recovery usually needs retained states independent of the current live data.
Can I always roll back to an older container image?
Only if the older application remains compatible with current configuration and data. Review migrations and dependencies first.
Is a server snapshot sufficient?
It depends on consistency, coverage and restoration requirements. Verify the snapshot method against the database and application, then test recovery.
Connect the concept to your work.
DOCKOCK keeps recovery connected to your infrastructure and application changes, so you can review the service, its data and the intended recovery action together.
Explore backup & recovery in DOCKOCKKeep learning from the source.
Further reading from the teams and documentation behind these technologies.
PostgreSQL: point-in-time recoveryPostgreSQL: logical dumps and restoration