https://azure.microsoft.com/en-us/documentation/articles/sql-database-bcdr-faq/
https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity/ Business continuity features
The following table shows the differences of the business continuity features across the service tiers:
Capability Basic tier Standard tier Premium tier
Point In Time Restore
Any restore point within 7 days
Any restore point within 14 days
Any restore point within 35 days Geo-Restore ERT < 12h, RPO < 1h ERT < 12h, RPO < 1h ERT < 12h, RPO < 1h Standard Geo-
Replication
not included ERT < 30s, RPO < 5s ERT < 30s, RPO < 5s
Active Geo- Replication
not included not included ERT < 30s, RPO < 5s
https://azure.microsoft.com/en-us/documentation/articles/sql-database-business-continuity-design Designing your application for business continuity requires you to answer the following questions:
1. Which business continuity feature is appropriate for protecting my application from outages? 2. What level of redundancy and replication topology do I use?
When to use Geo-Restore
SQL Database provides a built-in basic protection of every database by default. It is done by storing the database backups in the geo-redundant Azure storage (GRS). If you choose this method, no special configuration or additional resource allocation is necessary. With these backups, you can recover your database in any region using the Geo-Restore command. Use Recover from an outage section for the details of using geo-restore to recover your application.
You should use the built-in protection if your application meets the following criteria:
1. It is not considered mission critical. It doesn't have a binding SLA therefore the downtime of 24 hours or longer will not result in financial liability.
2. The rate of data change is low (e.g. transactions per hour). The RPO of 1 hour will not result in a massive data loss.
3. The application is cost sensitive and cannot justify the additional cost of Geo-Replication
NOTE: Geo-Restore does not pre-allocate the compute capacity in any particular region to restore active databases from the backup during the outage. The service will manage the workload
associated with the geo-restore requests in a manner that minimizes the impact on the existing databases in that region and their capacity demands will have priority. Therefore, the recovery time of your database will depend on how many other databases will be recovering in the same region at the same time.
When to use Geo-Replication
Geo-Replication creates a replica database (secondary) in a different region from your primary. It guarantees that your database will have the necessary data and compute resources to support the application's workload after the recovery. Refer to Recover from an outage section for using failover to recover your application.
You should use the Geo-Replication if your application meets the following criteria:
1. It is mission critical. It has a binding SLA with aggressive RPO and RTO. Loss of data and availability will result in financial liability.
2. The rate of data change is high (e.g. transactions per minute or seconds). The RPO of 1 hr associated with the default protection will likely result in unacceptable data loss.
3. The cost associated with using Geo-Replication is significantly lower than the potential financial liability and associated loss of business.
NOTE: If your application uses Basic tier database(s) Geo-Repliation is not supported When to choose Standard vs. Active Geo-Replication
Standard tier databases do not have the option of using Active Geo-Replication so if your application uses standard databases and meets the above criteria it should enable Standard Geo-Replication. Premium databases on the other hand can choose either option. Standard Geo-Replication has been designed as a simpler and less expensive disaster recovery solution, particularly suited to applications that use it only to protect from unplanned events such as outages. With Standard Geo-Replication you can only use the DR paired region for the recovery and can create only one secondary for each primary. An additional secondary may be necessary for the application upgrade scenario. So if this scenario is critical for your application you should enable Active Geo-Replication instead. Please refer to Upgrade application without downtime for additional details.
NOTE: Active Geo-Replication also supports read-only access to the secondary database thus providing additional capacity for the read-only workloads.
How to enable Geo-Replication
You can enable Geo-Replication using Azure Classic Portal or by calling REST API or PowerShell command.
Azure Classic Portal
1. Log in to the Azure Classic Portal
2. On the left side of the screen select BROWSE and then select SQL Databases
3. Navigate to your database blade, select the Geo Replication map and click Configure Geo- Replication.
4. Navigate to Geo-Replication blade. Select the target region.
5. Navigate to the Create Secondary blade. Select an existing server in the target region or create a new one.
6. Select the secondary type (Readable or Non-readable) 7. Click Create to complete the configuration
NOTE:
The DR paired region on the Geo-Replication blade will be marked as recommended. If you use a Premium tier database you can choose a different region. If you are using a Standard database you cannot change it. The Premium database will have a choice of the secondary type (Readable or Non- readable). Standard database can only select a Non-readable secondary.
PowerShell
Use the New-AzureRmSqlDatabaseSecondary PowerShell cmdlet to create Geo-Replication
configuration. This command is synchronous and returns when the primary and secondary databases are in sync.
To configure Geo-Replication with a non-readable secondary for a Premium or Standard database:
$database = Get-AzureRmSqlDatabase –DatabaseName "mydb"
$secondaryLink = $database | New-AzureRmSqlDatabaseSecondary –PartnerResourceGroupName "rg2" – PartnerServerName "srv2" -AllowConnections "None"
To create Geo-Replication with a readable secondary for a Premium database:
Copy
$database = Get-AzureRmSqlDatabase –DatabaseName "mydb"
$secondaryLink = $database | New-AzureRmSqlDatabaseSecondary –PartnerResourceGroupName "rg2" – PartnerServerName "srv2" -AllowConnections "All"
REST API
Use Create Database API with createMode set to NonReadableSecondary or Secondary to programmatically create a Geo-Replication secondary database.
This API is asynchronous. After it returns use the Get Replication Link API to check the status of this operation. The replicationState field of the response body will have the value CATCHUP when the operation is completed.
How to choose the failover configuration
When designing your application for business continuity you should consider several configuration options. The choice will depend on the application deployment topology and what parts of your applications are most vulnerable to an outage. Please refer to Designing Cloud Solutions for Disaster Recovery Using Geo-Replication for guidance.
3.3.2 Implement self-service restore
From http://blogs.technet.com/b/dataplatforminsider/archive/2014/05/05/azure-sql-database- service-tiers-amp-performance-q-amp-a.aspx :
Self-service Restore: SQL Database Premium allows you to restore your database to any point in time within the last
35 days, in the case of a human or programmatic data deletion scenario. Replace import/export workarounds with self-service control over database restore. For more on using Self-service Restore, see Restore Service
documentation.