We are preparing our DR plan for an Azure-hosted application and I have come across some confusing wording in the database restore documentation.
As I understand it, log backups are taken roughly every 5 minutes and these are geo-redundant, but when I do a restore with the -FromGeoBackup flag, the most recent backup is older than that.
I can do a point in time restore using a more recent backup but as I understand it, that can only be done on the same server.
What if our primary data center goes down and we need to restore to a new server in a new data center?
Is the only way to do this via -FromGeoBackup with a roughly 1-hour gap in data or can I use the geo-redundant log backups to get a more recent version?
This is using a Standard tier database if that's relevant.
Yes, if you are not using Failover Groups\Geo-replication then you have the default recovery option of Geo-restore (Restore-AzureRmSqlDatabase -FromGeoBackup). There is a delay between when a backup is taken and when it is geo-replicated to an Azure blob in a different region. As a result, the restored database can be up to one hour behind the original database. With Geo-restore the RTO is 12 h and the RPO is 1 h.
If restoring a database to an hour earlier can result in business liability or your organization cannot afford that, you should be using failover groups. This enables your database (and applications) to quickly restore availability in a different region in case of an outage.
With Auto-failover groups the RTO is 1 h ( to ensure that the failover is justified by the scale of the outage) and RPO 5s. With manual database failover, however, the RTO is 30 s and the RPO is 5 s.