Context
Azure SQL point-in-time restore reconstructs a new database from retained backups. It does not rewind the existing production database in place. That distinction creates a useful inspection boundary: operators can validate recovered records before deciding what should return to production.
Prerequisites are the source database, its available retention interval, the incident timeline in UTC and an approved recovery objective. Identify an isolated target name and the people authorized to validate business data. Confirm the service tier and special features that the restored database must support.
1. Establish the recovery timestamp
Correlate deployment logs, application events and database audit evidence to find when the incorrect change began. Distinguish the first bad write from the moment someone noticed its effect. Choose a point before the unwanted transaction while documenting legitimate transactions that happened afterward.
Inspect available restore boundaries for the source database. Do not promise a timestamp outside retention or assume that the latest possible recovery point is identical to the current time. Record the source database identity to avoid selecting a similarly named development database.
2. Restore to an inspection database
Use the supported portal workflow to create a separately named recovery database at the selected time. Keep application writers pointed at production during inspection unless the incident plan explicitly pauses them. Give reviewers only the access needed for recovery validation.
Track the restore operation to completion. A visible database resource can still be restoring. Avoid deleting it because a first query does not immediately work. Confirm its online state, expected compatibility and access configuration before starting record checks. Preserve the operation identifier and chosen timestamp in the incident record.
3. Choose repair or cutover explicitly
Compare affected business keys and dependent records between restored and current databases. Selective repair can preserve legitimate later work, but its script must account for relationships, generated identifiers and side effects already sent to other systems. Prepare a reviewed reconciliation plan rather than copying entire tables by intuition.
A full application cutover needs a different plan: control writes, decide how to handle later valid transactions, update connection targets and validate dependencies. PITR alone does not reverse payments, emails or third-party API calls. Reconcile those external effects using their own business identifiers and authoritative records.
Diagnostic checkpoints
| Observation | Implication | Next evidence |
|---|---|---|
| Desired timestamp unavailable | Retention boundary | Earliest and latest restore range |
| Resource exists, queries fail | Restore still progressing | Operation state |
| Recovered rows are correct, links differ | Dependent data mismatch | Relationship comparison |
| Production contains later valid work | Cutover may discard it | Reconciliation inventory |
Illustrative scenario
A hypothetical release marks the wrong customers inactive. The team restores a new database from before the release and compares the affected customer identifiers. It then reviews a selective status repair while preserving orders created afterward. This example demonstrates decision boundaries, not a promised recovery duration or a real customer outcome.
Verify and maintain the recovery SOP
Test the repair against an isolated copy using representative affected and unaffected records. After approved execution, verify application behavior and downstream reconciliation, not only row counts. Keep a rollback or compensating plan for the repair itself.
The SOP should record recovery point selection, validation queries, data-owner sign-off and cleanup timing for the temporary database. Monitor retention configuration and protection changes. Rehearse selective repair as well as complete restoration, because a successful database restore does not establish that operators can safely reconstruct the intended business state.
Explore Clouvenix backup disaster recovery for implementation and operational handover.