Concept and mechanism
Automatic backups form part of Azure SQL Database protection, but retention and redundancy need configuration matching objectives. PITR recovers a point within available history and creates a new database without directly overwriting the existing one. Planning includes validation and controlled connection changes. LTR retains selected backups for longer periods; it does not provide an unlimited continuous chain for choosing any second in previous years. Retention duration and copy location are different dimensions. A local copy does not establish geo-restore capability after regional loss. Check redundancy options and actual copy availability before an incident. Recovery planning should identify who can initiate restoration when the normal administrative environment is unavailable.
Guided application
In a fictional position-update error, restoring before the error can exclude valid later movements. Preserve the source, reconcile events, and consider selective repair where appropriate. Technical restore success does not reverse external integrations. With customer-managed TDE keys, older backups can still depend on previous protector versions. Rotating the key does not automatically re-encrypt those copies; deleting old versions can prevent recovery. Retain required material and target access to Key Vault or HSM with defined protection and owners. Rehearsal must measure both time to availability and actual data loss, including authentication and key access. Report any dependency that prevented completing the full recovery path.
PITR to 09:59 after a 10:00 error requires assessing valid movements committed after 10:00.
Common pitfalls
LTR as unlimited PITR; local backup as geographic; new key as replacement for every old key.
Related topics: Platform, capacity, and migration · Identity, networking, and encryption · Sensitive data and evidence
Recoverability depends on accessible data, history, and keys.
Reference: PITR and geo restore · DP-300 English objectives effective 2026-04-24