Exclude disks from disaster recovery

This article describes how to exclude disks from replication during disaster recovery from on-premises to Azure with Azure Site Recovery. You might exclude disks from replication for a number of reasons:

• So that unimportant data churned on the excluded disk isn't replicated.
• To optimize consumed replication bandwidth, or target-side resources.
• To save storage and network resources by not replicating data that you don't need.
• Azure VMs have reached Site Recovery replication limits.

Supported scenarios

You can exclude disks from replication as summarized in the table.

Exclude limitations

Typical scenarios

Examples of data churn that are great candidates for exclusion include writes to a paging file (pagefile.sys), and writes to the tempdb file of Microsoft SQL Server. Depending on the workload and the storage subsystem, the paging and tempdb files can register a significant amount of churn. Replicating this type of data to Azure is resource-intensive.

• To optimize replication for a VM with a single virtual disk that includes both the operating system and the paging file, you could:

  1. Split the single virtual disk into two virtual disks. One virtual disk has the operating system, and the other has the paging file.
  2. Exclude the paging file disk from replication.

• To optimize replication for a disk that includes both the Microsoft SQL Server tempdb file and the system database file, you could:

  1. Keep the system database and tempdb on two different disks.
  2. Exclude the tempdb disk from replication.

Example 1: Exclude the SQL Server tempdb disk

Let's look at how to handle disk exclusion, failover, and failover for a source SQL Server Windows VM - SalesDB*, for which we want to exclude tempdb.

Exclude disks from replication

We have these disks on the source Windows VM SalesDB.

1. We enable replication for the SalesDB VM.
2. We exclude Disk2 and Disk3 from replication because data churn on those disks is temporary.

Handle disks during failover

Since disks aren't replicated, when you fail over to Azure these disks aren't present on the Azure VM created after failover. The Azure VM has the disks summarized in this table.

In our example, since Disk3, the SQL tempdb disk, was excluded from replication and isn't available on the Azure VM, the SQL service is in a stopped state, and it needs the F:\MSSQL\Data path. You can create this path in a couple of ways:

• Add a new disk after failover, and assign tempdb folder path.
• Use an existing temporary storage disk for the tempdb folder path.

Add a new disk after failover

1. Write down the paths of SQL tempdb.mdf and tempdb.ldf before failover.
2. From the Azure portal, add a new disk to the failover Azure VM. The disk should be the same size (or larger) as the source SQL tempdb disk (Disk3).
3. Sign in to the Azure VM.
4. From the disk management (diskmgmt.msc) console, initialize and format the newly added disk.
5. Assign the same drive letter that was used by the SQL tempdb disk (F:)
6. Create a tempdb folder on the F: volume (F:\MSSQL\Data).
7. Start the SQL service from the service console.

Use an existing temporary storage disk

1. Open a command prompt.

2. Run SQL Server in recovery mode from the command prompt.

   Net start MSSQLSERVER /f / T3608
   

3. Run the following sqlcmd to change the tempdb path to the new path.

   sqlcmd -A -S SalesDB		**Use your SQL DBname**
   USE master;		
   GO		
   ALTER DATABASE tempdb		
   MODIFY FILE (NAME = tempdev, FILENAME = 'E:\MSSQL\tempdata\tempdb.mdf');
   GO		
   ALTER DATABASE tempdb		
   MODIFY FILE (NAME = templog, FILENAME = 'E:\MSSQL\tempdata\templog.ldf');		
   GO
   

4. Stop the Microsoft SQL Server service.

   Net stop MSSQLSERVER
   

5. Start the Microsoft SQL Server service.

   Net start MSSQLSERVER
   

VMware VMs: Disks during failback to original location

Now let's see how to handle disks on VMware VMs when you fail back to your original on-premises location.

• Disks created in Azure: Since our example uses a Windows VM, disks that you create manually in Azure aren't replicated back to your site when you fail back or reprotect a VM.
• Temporary storage disk in Azure: The temporary storage disk isn't replicated back to on-premises hosts.
• Excluded disks: Disks that were excluded from VMware to Azure replication aren't available on the on-premises VM after failback.

Before you fail back the VMware VMs to the original location, the Azure VM disk settings are as follows.

After failback, the VMware VM in the original location has the disks summarized in the table.

Hyper-V VMs: Disks during failback to original location

Now let's see how to handle disks on Hyper-V VMs when you fail back to your original on-premises location.

• Disks created in Azure: Disks that you create manually in Azure aren't replicated back to your site when you fail back or reprotect a VM.
• Temporary storage disk in Azure: The temporary storage disk isn't replicated back to on-premises hosts.
• Excluded disks: After failback the VM disk configuration is the same as the original VM disk configuration. Disks that were excluded from replication from Hyper-V to Azure are available on the failback VM.

Before you fail back the Hyper-V VMs to the original location, the Azure VM disk settings are as follows.

After planned failover (failback) from Azure to on-premises Hyper-V, the Hyper-V VM in the original location has the disks summarized in the table.

Example 2: Exclude the paging file disk

Let's look at how to handle disk exclusion, failover, and failover for a source Windows VM, for which we want to exclude the pagefile.sys file disk on both the D drive, and an alternate drive.

Paging file on the D drive

We have these disks on the source VM.

Our paging file settings on the source VM are as follows:

1. We enable replication for the VM.
2. We exclude DB-Disk1 from replication.

Disks after failover

After failover the Azure VM has the disks summarized in the table.

Our paging file settings on the Azure VM are as follows:

Paging file on another drive (not D:)

Let's look at example in which the paging file isn't on the D drive.

We have these disks on the source VM.

Our paging file settings on the on-premises VM are as follows:

1. We enable replication for the VM.
2. We exclude DB-Disk1 from replication.

Disks after failover

After failover the Azure VM has the disks summarized in the table.

Our paging file settings on the Azure VM are as follows:

Next steps

• Learn more about guidelines for the temporary storage disk:
  • Learn about using SSDs in Azure VMs to store SQL Server TempDB and Buffer Pool Extensions
  • Review performance best practices for SQL Server in Azure VMs.
• After your deployment is set up and running, learn more about different types of failover.