AlwaysOn Database Backup
Last updated
Last updated
Before implementing DPX Block Data Protection for SQL Server AlwayOn Availability Groups, read this topic, which describes concepts and considerations related to backup, recovery, and storage sizing.
DPX supports Microsoft SQL Server 2012 backups, including SQL Server 2012 AlwaysOn Availability Groups for primary replica backup and recovery. In addition, DPX supports SQL Server 2012 standalone SQL instances and traditional Windows clustered SQL instances.
This topic reviews the supported capabilities and known limitations for SQL Server Availability Group backup and recovery. Note that SQL Server 2012 AlwayOn is supported for Block backup, not file-level backup. The following sections describe concepts and considerations.
DPX protects SQL Server 2012 AlwaysOn Availability Groups. which are designed to improve the resiliency of SQL Server instances. AlwayOn Availability is configured by setting up a Windows Server Failover Clustering (WSFC) resource, joining servers with SQL instances to AlwaysOn availability groups, and then arranging for primary and secondary copies of SQL databases to join the availability group. The WSFC cluster and availability group services manage the monitoring, failover, and request redirection for the database availability group. For a technical overview of SQL Server 2012 AlwaysOn Availability Groups concepts, see in Microsoft Learn Database.
Note the following important protection considerations, described in more detail below:
Restoration of a SharePoint database under Microsoft AlwaysOn Availability Group requires that the group already exist and be configured with an active listener. The availability group must have at least 1 database configured in the group in order for DPX to recognize it as a valid destination for restore. See .
Restore can only occur on the node acting as the primary replica for the availability group. DPX cannot recover an availability group database if the desired database is already active in the availability group. To restore data, a standalone SQL database with the desired name must be created on the availability group primary replica node. When the database is restored, it is first restored to the standalone instance on the primary replica node and then merged into the Availability group when the data transfer is completed. Suppose you are recovering to an existing database. In that case, you must either rename the active database, delete it, or move the database out of the availability group so that the recovered copy can be added to the availability group.
Backup of high-availability primary database copies is supported. Backup of secondary replicas is not supported.
Secondary storage and Catalogic Software product license consumption will roughly equal the sum of all the storage devices across all cluster nodes.
SQL Server 2012 and later provides a high-availability feature of database-level replication, the replication databases are organized logically by using availability groups, which create Windows cluster resource within the failover cluster management console. The replica of an availability group can be an SQL instance and the availability group listener is optional, depending on the requirement to connect to the replica of an availability group.
From the SQL Server management console, an availability database displays on both the availability group and the local instance that hosts the replica. However, in the DPX resource browser, the availability databases display on the availability group under the SQL cluster virtual node. The database does not display on the primary replica node because the backup will not work after a failover is initiated on the database to the replica node.
The Microsoft Windows Server series supports Distributed File System (DFS).
A DFS Namespace is a shared resource so you can add shared folders from different servers in different locations into one directory. In the namespace, you only see a list of shared folders, while the actual structure of the namespace can consist of a number of different servers, in multiple locations, sharing the folders in the namespace.
Use DFS Replication to synchronize folders on multiple servers across a network. The content is then synchronized to each server locally. A replication group is used to manage the files, ensuring that a replicated file updated in one location updates the other files in the replication group with the changes in accordance with the replication topology selected during the replication setup. Consult your Microsoft documentation for more information on replication topology.
For Windows Server 2012 and later, Catalogic DPX supports Block backup of a namespace server. In the namespace, you only see a list of shared folders, while the actual structure of the namespace can consist of a number different servers, in multiple locations, sharing the folders in the namespace. This topic describes considerations for Block backup and restore of the namespace servers.
DPX supports the Backup and restore of a standalone namespace server. The following considerations apply:
A Block backup of the system state of the namespace server is required for the Block restore to have the necessary components to restore the namespace components.
Block restore of a namespace server is only supported for the Original Location destination.
A Block restore of a namespace server that also serves as a replication group host requires that the replication group be manually restored. Manual restoration of the replication group can be conducted through the Folder Replication Wizard in the DFS management console. Consult your Microsoft documentation for more information.
After a successful Block restore of a namespace server, reboot the server to complete the restoration process.
For Windows Server 2012 and later, Catalogic DPX supports Block backup of DFS replication folders. DFS Replication allows you to synchronize shared folders by adding them to a replication group. The content is then synched to each machine locally. In the Catalogic DPX Block Backup Wizard, the replicated folders on the client node appear under a container named DfsrReplicatedFolders. This topic describes considerations for Block backup and restore of these folders.
The Catalogic DPX Block Data Protection support of DFS Replication is for Windows Server 2012 and later only.
Block level backup of a replicated folder requires a backup of the local volume that the replicated folder resides on. When a folder is selected under the DfsrReplicatedFolders container, the entire volume is backed up automatically.
During the DFS replication group sync process in Windows, a Primary Member is designated. Note that the Primary Member is only used for the initial setup process and has no effect on the backup or restore procedures in Catalogic DPX.
For DFS Replication Block Backup, the recommended best practice is to disable replication writes on the volume or folder to be backed up.
Block restore of a replicated folder is only supported for the Original Location destination.
For stable operation of the folder replication, Microsoft recommends that the staging quota for replicated folders be set at 30% of the size of the shared folder. Consult your Microsoft documentation for more information on adjusting the properties of a replicated folder.
The application of configuration settings and updates to replicated files can be delayed by a variety of factors when being distributed to a replication group.
This delay can be shortened by manually applying the changes using the following command in Microsoft Windows PowerShell:
Selection of the Original Location destination for a replicated folder is required to maintain the replication relationships. Restoring the replicated folder by navigating through the volume level backup is possible, however the replication service is no longer extended to the folder and its contents. A volume level restore of a replicated folder should only be done if the folder replication is no longer required and a backup destination is selected that is not Original Location. If the restore is done through the volume level backup to Original Location, the data in the replicated folder can become corrupt.
Microsoft recommends that any troubleshooting efforts for DFS start with a restart of the Windows service; DFS Replication.
Files restored during a Block restore are automatically deleted and replaced by Windows if modified copies of the file are present in the replicated folder. Delete files modified after the selected Block backup was made from the replicated folder prior to the Block restore.
Conflicted files, such as files replaced by Windows in the above consideration, appear in the folder named conflictedandeleted. This folder resides in the hidden folder DFSprivate; viewing this folder might require a change to the folder options to view hidden files and folders, consult your Microsoft documentation for more information.
During the Block restore, Windows automatically places files restored by Catalogic DPX into a folder named preexisting in the DFSprivate folder. Catalogic DPX automatically removes the files in this folder and places them back in the Original Location during the restore. Note that this process also restores files that were present in the directory before the Block restore was run.
See also. For general information about the Catalogic Block Data Protection, see .
Catalogic DPX supports the backup and restore of one or more namespace servers in a domain. In addition to the considerations listed in above, a Block backup is required of both the namespace server and the domain controller that manages it, to ensure that the namespace is properly restored on the domain controller. It is recommended that the Block backup and restore of the namespace server and the domain controller is done by the same Block backup and restore jobs.