Microsoft Azure Essentials Fundamentals of Azure Second Edition e-optimized 5x11 pdf

Business continuity 
SQL Database provides several options to address business continuity requirements. One way in which 
SQL Database provides protection is through infrastructure redundancy. At any time in an Azure 
datacenter, there could be a hardware failure (such as hard drive, network, or entire servers). SQL 
Database provides high availability in the case of such hardware failures by keeping copies of the data 
on physically separate nodes. Three database nodes, or replicas, are always running: one primary 
replica and two secondary replicas. For write operations, data is written to the primary and one of the 
secondary replicas before the write transaction is considered complete. In the event of a failure of the 
primary replica, SQL Database detects the failure and fails over to a secondary replica. If needed, a 
new replica is then created. 
Furthermore, business continuity with respect to databases often includes two categories: database 
recovery and disaster recovery. Database recovery refers to the ability to mitigate risk and recover 
from database corruption or an unintentional modification or deletion of data. To assist with database 
recovery, SQL Database provides a feature called Point-in-Time Restore. Point-in-Time Restore allows 
you to restore a database to any previous point. The timeframe from which you can restore varies 
based on the selected SQL Database tier: 7 days for Basic, 14 days for Standard, and 35 days for 
Premium. 
To restore a database to a previous point, first select the desired database in the Azure portal and 
then click Restore, as shown in Figure 6-6. 
 
Figure 6-6  Option to restore a database.  
Clicking the Restore button opens a new blade, as shown in Figure 6-7, that allows you to enter the 
name for the restored database (or keep the autogenerated default name) and the restore point (date 
and time, at one-minute intervals). 

---

165 
CHAPTER 6  |    Databases 
 
 
Figure 6-7  Database restore settings.  
The restore operation might a long time to complete. The exact time to restore can be difficult to 
predict because it depends on several factors, including the size of the database, the restore point in 
time selected, and the activity log that needs to be replayed to get to the restore point. For some 
large databases, this process could take several hours. 
If you have deleted a database, you can restore the entire database. To do so, first select the SQL 
Database server that contained the database and then select Deleted Databases in the Operations 
group of the SQL Server blade. This opens a new Deleted Databases blade, as shown in Figure 6-8. 

---

166 
CHAPTER 6  |    Databases 
 
 
Figure 6-8  Restoring a deleted database.  
If there are multiple deleted databases, select the database to restore. On the resulting Restore blade, 
provide a name for the database to be restored, as shown in Figure 6-9. The database can only be 
restored to the point at which it was deleted. After you click Create, the restore request will be 
submitted. Just like a point-in-time restore, the process to restore a deleted database could take a 
long time to complete. 
 
Figure 6-9  Settings for restoring a deleted database.  
Point-in-Time Restore is helpful when you need to recover a database to a known good point, which 
is often a result of user error. However, this is only one aspect of business continuity, the other being 
disaster recovery. Disaster recovery refers to the ability to restore operations to a working state in the 
event a disaster renders the primary region unrecoverable or unavailable for an extended period of 

---

167 
CHAPTER 6  |    Databases 
 
time. SQL Database provides additional features that can be helpful in preparing a disaster recovery 
plan: Geo-Restore, Standard Geo-Replication, and Active Geo-Replication.