What happens in (the remote? impossible?) case of an Azure datacenter DR is a recurring question when I advocate Azure. Sometimes the ability to have storage account replica (with GRS and GRS-RA) is misleading, it leads to the wrong conclusion that everything is going to work auto-magically. This is not the case, even if your data is there it’s your duty to recover the services (excluding the services with their own geo DR, for example Aure SQL databases).
If we consider Virtual Machines we can leverage Azure Site recovery (recently GA) to build a DR workflow, or if we have a (much) larger Recovery Time Objective (RTO) we can use Azure Backup (that is obviously cheaper) to perform a recovery in the survived datacenter. This is a choice that must be made at recovery vault creation (and by the way it is the default choice) when you chose the storage type: LRS or GRS. This choice cannot be changed once the vault contains data. Obviously choosing GRS means you’re going to pay twice for the storage space used by Azure Backup, just because… you’re really using twice the space.
When GRS is selected not only the data is replicated but also the service metadata. So in case of an entire Azure datacenter DR, in the paired datacenter you’ll find your data and the recovery vault from where you can start you recovery process.
From the official documentation:
Azure Backup allows restoring backed-up VMs to the paired datacenter in case the primary datacenter where VMs are running experiences a disaster and you configured the backup vault to be geo-redundant. During such scenarios, select a storage account, which is present in a paired datacenter. The rest of the restore process remains the same. Backup uses the compute service from the paired geo to create the restored VM. For more information, see Azure datacenter resiliency.