Share via

If Azure SQL PITR is set to 1 day and the database is deleted, can Azure still retrieve that data after the PITR window expires?

Kershawn Edwards 0 Reputation points
2026-06-02T18:50:55.5466667+00:00

We are building a solution on Azure SQL Database and need to clarify data retention behavior for a client compliance requirement.

The client requires that upon deletion, all data be completely and permanently removed from Azure infrastructure.

Question: If PITR is set to 1 day and the database is deleted, is it possible for Azure to retrieve or access that data after the PITR window has expired? For example, would the data still exist on Azure systems 3 days after deletion?

Azure SQL Database
0 comments No comments

2 answers

Sort by: Most helpful
  1. Manoj Kumar Boyini 16,810 Reputation points Microsoft External Staff Moderator
    2026-06-04T02:11:01.65+00:00

    Hi @Kershawn Edwards

    In Azure SQL Database, Point-in-Time Restore (PITR) is available only while valid backups exist within the configured backup retention period. If a database is deleted, it can be restored only while the required PITR backups are still retained by the service.

    If the database is configured with a 1-day PITR retention period and no additional backup retention mechanisms (such as Long-Term Retention (LTR)) are configured, then once the retention period expires, the PITR restore window also expires and the database can no longer be restored using PITR.

    However, before concluding that recovery is no longer possible, it is important to verify whether any Long-Term Retention (LTR) policies or other backup retention configurations were enabled for the database. If LTR backups exist, they may still be available for restore even after the PITR retention period has expired.

    You can review the following Microsoft documentation for details:

    Restore a deleted database using backups: https://learn.microsoft.com/azure/azure-sql/database/recovery-using-backups

    Long-Term Retention (LTR) Overview: https://learn.microsoft.com/azure/azure-sql/database/long-term-backup-retention-overview

    Please let us know if you have any questions.

    Was this answer helpful?


  2. AI answer

    2026-06-02T18:51:15.07+00:00

    Azure SQL Database automated backups are managed in Microsoft-owned subscriptions and stored in secure internal Azure Storage accounts. These backups are not externally accessible, and only internal backend services (such as the Backup-Restore service) can access them under strict Just-In-Time (JIT) and audit controls.

    For point-in-time restore (PITR), Azure SQL Database retains full, differential, and log backups long enough to provide PITR for the configured retention period. To maintain an uninterrupted backup chain, backups may be kept for up to about a week longer than the configured PITR retention. Backups that are no longer needed to provide PITR functionality are automatically deleted, and after all backups are deleted and PITR is no longer possible, billing for backup storage stops.

    For deleted databases, backups are retained only as long as needed to support PITR within the configured retention period. After those backups age out and are purged, they are no longer available to Azure’s backup/restore services. At that point, Azure cannot restore or otherwise retrieve the database from PITR backups.

    Therefore, with PITR set to 1 day, once the backup chain required to support that 1-day window has fully expired and been deleted (which can extend up to roughly a week beyond the configured retention to maintain the chain), Azure’s backup/restore mechanisms can no longer access or restore the data. The data is then removed from Azure’s backup systems as part of the automated deletion process.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.