Recovery Considerations

• For SQL Server 2012 with AlwaysOn configured, only a restore of the primary replica is supported.

• AlwaysOn availability groups have special procedures for creating the availability group, failing or moving primary replica responsibility, removing databases from AlwaysOn service, and recovering failed nodes. Consult your Microsoft SQL Server AlwaysOn Availability Group documentation for specific procedures. Note that DPX is not designed to be used as a tool to seed secondary replicas. The creation of a secondary replica requires specific procedures which enable the copy to be brought into the availability group and synchronized with the primary.

• Restoration of an availability database does not restore system databases; this is significant if SharePoint Logins are hosted in the SQL MasterDB database. Consult Microsoft documentation on SharePoint 2013 configuration with SQL 2012 AlwaysOn Availability groups for more information on logins and review the newer SQL 2012 functionality pertaining to Users with Passwords for Contained Databases.

• To restore an availability database to an availability group, some databases must be present on the primary replica for the restore browser to recognize the availability group. If no database is present (the group is empty), it must be added manually. Consult your Microsoft SQL Server AlwaysOn Availability Group documentation for specific procedures. The recovery process requires a standalone database with the desired name to be available on the primary replica node to accept the data transfer. Subsequently this database will be merged into the availability group. You cannot overwrite an existing database under an AlwaysOn availability group control; the existing copy must either be deleted, renamed, or moved out of the availability group so that the restored instance can be added to the availability group.

• Restoration of an availability database that is in stand-by mode is not supported.

• Restoration of AlwaysOn databases cannot be done directly into an active availability group; this is a Microsoft limitation. If you need to recover data into a SQL instance that is part of an availability group, you must use Microsoft supplied WSFC and AlwaysOn management tools to bring the affected database out of the availability group, perform the restore action, and then bring the database back into the availability group.

• Large and complex multi-site deployments that include all resources in a single job may pose challenges that prevent the job from running successfully. Network stability, latency, failover, and planned maintenance cycles may result in large complex jobs being prone to failure. In these cases, it will be more convenient to break up the data protection into separate jobs containing SQL components and physical servers. Since WSFC cluster configurations can be very complex, recovery operations can be complicated and should be prepared and practiced in advance. In many cases of WSFC AlwaysOn availability groups, you may need to plan the steps in the process. Steps include the following: Recover individual physical nodes using BMR, join them back into the cluster, correct SQL startup issues, rejoin the instance to the availability group, and then coordinate SQL database restores to standalone SQL databases before they can be placed back into the availability group for replication. In some cases, it may be better to consider procedures which quickly recover the primary replica copy, and then use that copy to produce the necessary secondary replicas.

• The Instant Access (IA) Map feature of DPX cannot be used to rapidly replace devices or databases that are under availability group control. IA MAP is commonly used with standalone SQL servers, but it does not work for clustered machines. As indicated above, AlwaysOn functionality has very specific procedures for bringing primary and secondary replicas into the availability group. IA Map can be used to access any SQL data from a standalone database, and that data can be copied into a clustered database as needed. Attaching the SQL data devices to the physical node could be performed by the backup/restore administrator; however, the recovery and transfer of data would have to be coordinated by the DBA using SQL management tools.

• The Instant Virtualization, Full Virtualization, and RRP features cannot be used to recover cluster instances. Also note that agentless backup of SQL server nodes is not guaranteed to be application consistent. Additionally, the agentless restore of a SQL server participating in a WSFC cluster may require some significant manual effort to correct application-related inconsistencies before it can be rejoined to an availability group and seeded with a new secondary replica database.

• SQL Server 2012 imposes some additional security requirements that were not the default in previous versions of SQL Server. Read knowledge base article 46322.

• The AlwaysOn backup and restore support does not have any special interaction with SQL transaction logs. All backup coordination is done through VSS, which decides exactly what occurs during the backup and recovery cycles. Transaction log management is central to the operation of AlwaysOn availability groups; therefore, DPX does not do anything specific to manage, control, or truncate these logs. If there are any special procedures necessary for maintaining transaction logs, this task is explicitly left to the DBA to manage. Currently, there is no direct support for point-in-time restore of SQL AlwaysOn availability group databases.