We’re attempting to perform a geo-restore of our Azure SQL Database as part of disaster recovery testing, but the operation fails with “Geo-secondary database not available” error. This is blocking our DR validation process.
Our setup includes a Business Critical tier database with geo-replication enabled. We had a failover group configured previously but deleted it last month to restructure our DR topology. Now when trying to restore from geo-backup:
-- Attempting restore via Azure Portal and also tried T-SQL
CREATE DATABASE restored_proddb
AS COPY OF server1.proddb
ERROR: The geo-secondary database is not available for restore
Geo-restore operation failed: backup retention validation error
The primary database shows as healthy, and according to Azure documentation, geo-backups should be available for 7-35 days depending on tier. We’re within that window. Could the previous failover group deletion have impacted geo-backup availability? What are the actual prerequisites for geo-restore to work?
I’ve seen this issue before. Geo-restore relies on geo-redundant backups that are replicated to the paired Azure region. When you had the failover group, it was using active geo-replication which is different from geo-backup. After deleting the failover group, Azure needs to re-establish the automated geo-backup process. The retention period (7-35 days) only applies once the geo-backup chain is healthy. For Business Critical tier, you should have point-in-time restore available, but geo-restore to a different region requires the geo-backup infrastructure to be fully initialized.
One critical point about failover group deletion impact: when you delete a failover group, the secondary database is also removed, which breaks the continuous replication stream. Azure then falls back to geo-redundant automated backups, but these use a different mechanism. The automated backup service needs to complete at least one full backup cycle and replicate it to the paired region before geo-restore becomes available. For Business Critical tier, this is typically 24-72 hours. You can check backup completion using Azure Resource Graph queries or the database’s backup blade.
Just adding context on retention policies - the 7-35 day retention applies to successfully completed geo-backups, not from the moment you enable the feature. After failover group deletion, the retention clock effectively resets because the previous backup chain was tied to the geo-replication topology. For production scenarios, I’d recommend maintaining both failover groups AND ensuring geo-backup is properly configured as defense in depth. The failover group handles planned/unplanned failovers with minimal data loss, while geo-backup provides protection against region-wide disasters or accidental deletions.
Let me provide a comprehensive solution covering all three key aspects of your geo-restore issue:
1. Geo-Restore Prerequisites and Failover Group Impact:
The core problem is that deleting your failover group removed the active geo-replication relationship, which forced Azure to rebuild the geo-backup infrastructure from scratch. Geo-restore requires:
- Completed geo-redundant backup in the paired Azure region
- Valid backup retention policy (7-35 days for your tier)
- At least one full backup cycle completed after any topology changes
When you deleted the failover group, the geo-secondary database was removed, severing the continuous replication. Azure’s automated backup service then needed to:
- Create a new full database backup
- Replicate that backup to the geo-redundant storage in the paired region
- Establish the backup chain for incremental backups
This process takes 48-72 hours for Business Critical tier databases.
2. Verification and Monitoring:
To check geo-backup status:
# Check geo-backup availability
Get-AzSqlDatabaseGeoBackup -ResourceGroupName "rg-prod" -ServerName "server1" -DatabaseName "proddb"
# Verify earliest restore point
(Get-AzSqlDatabase -ResourceGroupName "rg-prod" -ServerName "server1" -DatabaseName "proddb").EarliestRestoreDate
The “Earliest restore point” timestamp indicates when the current backup chain started. If this is within 48 hours of your failover group deletion, the geo-backup infrastructure is still initializing.
3. Azure SQL Geo-Backup Retention and RPO/RTO:
Key differences between failover groups and geo-restore:
- Failover Groups: RPO < 5 seconds, RTO < 1 hour, uses active geo-replication
- Geo-Restore: RPO up to 1 hour (backup frequency), RTO 2-12 hours (depends on database size)
Your Business Critical tier has:
- Automated backups every 5-10 minutes
- Geo-redundant storage replication
- 7-day retention (default), extendable to 35 days
Resolution Steps:
- Wait 72 hours from failover group deletion for geo-backup chain to fully establish
- Verify using Get-AzSqlDatabaseGeoBackup that backups appear in paired region
- Once earliest restore point is > 24 hours old, geo-restore should succeed
- For production, consider re-implementing failover groups for better RTO/RPO
Important: The retention period countdown only starts after the first successful geo-backup completes. Your current situation has reset this timeline due to the topology change.
The error message is misleading - it’s not about geo-secondary availability but about geo-backup readiness. When you delete a failover group, there’s a transition period where the geo-replication relationship is severed but the geo-backup chain needs to rebuild. This typically takes 24-48 hours. Check the database properties in Azure Portal - look for “Earliest restore point” under the backup settings. If this timestamp is recent (within last 2 days), your geo-backup chain is still rebuilding after the failover group deletion.
To verify geo-backup status, use Azure CLI or PowerShell to check the GeoBackupPolicy. The command Get-AzSqlDatabaseGeoBackup will show available geo-backups and their locations. Regarding RPO/RTO differences: failover groups provide near-zero RPO (continuous replication) and RTO of minutes, while geo-restore from backup has RPO up to 1 hour (backup frequency) and RTO of several hours depending on database size. Geo-restore is meant for disaster recovery, not high availability. If you need better RTO/RPO, you should reconfigure failover groups rather than relying solely on geo-restore.