Azure SQL Hyperscale: Understanding PITR Retention vs Azure Portal Restore UI

Overview

Customers using Azure SQL Database – Hyperscale may sometimes notice a discrepancy between the configured Point-in-Time Restore (PITR) retention period and what the Azure Portal displays as available restore points.

In some cases:

• PITR retention is configured (for example, 7 days),
• Yet the Azure Portal only shows restore points going back a shorter period (for example, 1–2 days),
• And the restore UI may allow selecting dates earlier than the configured retention window without immediately showing an error.

This post explains why this happens, how to validate backup health, and what actions to take.

Key Observation

From investigation and internal validation, this behavior is not indicative of backup data loss. Instead, it is related to Azure Portal UI behavior, particularly for Hyperscale databases.

The backups themselves continue to exist and are managed correctly by the service.

Important Distinction: Portal UI vs Actual Backup State

What the Azure Portal Shows

• The restore blade may show fewer restore points than expected.
• The date picker may allow selecting dates outside the PITR retention window.
• No immediate validation error may appear in the UI.

What Actually Happens

• Backup retention is enforced at the service layer, not the portal.
• If a restore is attempted outside the valid PITR window, the operation will fail during execution, even if the UI allows selection.
• Hyperscale backup metadata is handled differently than General Purpose or Business Critical tiers.

Why This Happens with Hyperscale

There are a few important technical reasons:

1. Hyperscale backup architecture differs
   Hyperscale uses a distributed storage and backup model optimized for scale and fast restore, which affects how metadata is surfaced.
2. Some DMVs are not supported
   Views like sys.dm_database_backups, commonly used for backup visibility, do not support Hyperscale databases.
3. Azure Portal relies on metadata projections
   The portal restore experience depends on backend projections that may lag or behave differently for Hyperscale, leading to UI inconsistencies.

How to Validate Backup Health (Recommended)

Instead of relying solely on the Azure Portal UI, use service-backed validation methods.

Option 1: PowerShell – Earliest Restore Point

You can confirm the earliest available restore point directly from the service:

# Set your variables
$resourceGroupName = "RG-xxx-xxx-1"
$serverName = "sql-xxx-xxx-01"
$databaseName = "database_Prod"

# Get earliest restore point
$db = Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName
$earliestRestore = $db.EarliestRestoreDate

Write-Host "Earliest Restore Point: $earliestRestore"
Write-Host "Days Available: $([math]::Round(((Get-Date) - $earliestRestore).TotalDays, 1)) days"

This reflects the true PITR boundary enforced by Azure SQL.

Option 2: Internal Telemetry / Backup Events (Engineering Validation)

Internal monitoring confirms:

• Continuous backup events are present.
• Coverage aligns with configured PITR retention.
• Backup health remains ✅ Healthy even when the portal UI appears inconsistent.

Key takeaway: Backup data is intact and retention is honored.

Is There Any Risk of Data Loss?

No.

There is no evidence of backup loss or retention policy violation.
This is a visual/UX issue, not a data protection issue.

Recommended Actions

For Customers

• ✅ Trust the configured PITR retention, not just the portal display.
• ✅ Use PowerShell or Azure CLI to validate restore boundaries.
• ❌ Do not assume backup loss based on portal UI alone.

For Support / Engineering

• Capture a browser network trace when encountering UI inconsistencies. 
• Raise an incident with the Azure Portal team for investigation and fix.
• Reference Hyperscale-specific behavior during troubleshooting.

Summary

Final Thoughts

Azure SQL Hyperscale continues to provide robust, reliable backup and restore capabilities, even when the Azure Portal UI does not fully reflect the underlying state.

When in doubt:

• Validate via service APIs
• Rely on enforcement logic, not UI hints
• Escalate portal inconsistencies appropriately