Understanding Windows Server 2016’s Disaster Recovery Features
A solid understanding of the Disaster Recovery (DR) options that your systems have can help you build a reliable DR plan for your organization. Most businesses are using some version of Windows Server as core part of their IT infrastructure and understanding Windows Server’s built-in DR capabilities can definitely help you protect your mission-critical systems and applications from data loss and downtime. Let’s take a closer look at Windows Server’s built-in DR features.
Windows Server Backup
Backup is the most fundamental DR technology that’s been a part of Windows Server since the very beginning. However, the latest versions of Windows Server 2016 don’t actually install Windows Server Backup by default. Instead, it is an optional feature that you have to install using Server Manager or PowerShell. Windows Server Backup is functional although fairly limited in backup and scheduling options. In addition, it doesn’t provide advanced features that you’ll find in third-party backup products like encryption and deduplication. While it does provide the ability to backup Hyper-V VMs most businesses are using VM-specific third-party backup tools to take image-level backups of their VMs.
Windows Failover Clustering
Primarily a technology that’s designed to provide high availability for mission-critical applications, Windows Failover Clustering (WFC) is used to provide server-level protection from both planned and unplanned downtime. Windows Failover Clusters can have up to 64 nodes on Windows Server 2012, 2012 R2 and 2016. Like Windows Server Backup, WFC is an optional feature for Windows Server that you must install using Server Manager or PowerShell. WFC provides automatic failover in the event of an unplanned server failure. WFCs can run on either physical systems or VMs. WFCs usually use shared storage. However, starting with Windows Server 2012 it has been possible to build clusters without the use of shared storage. Applications must be cluster-aware to take full advantage WFCs. For instance, to protect SQL Server with a WFC you must install SQL Server using the specific cluster installation options rather than the standalone instance setup option. If one of the cluster nodes fails then the SQL Server service is started on one of the remaining nodes. There is no data loss because transactions are stored on shared storage and then uncommitted transactions are applied to the new SQL Server instance. Depending upon the workload that is running there can be a delay of many minutes for the failover process to complete as the service is restarted and the outstanding transactions are applied. WFC can be used in a DR scenario by creating a geographically dispersed cluster where different cluster nodes are in different locations. In this type of scenario SAN replication typically replicates the shared storage for the different locations.
With Windows Server 2016, Microsoft introduced a new DR technology to Windows Server called Storage Replica. Storage Replica will allow block-level replication of entire servers or even entire clusters. This makes it possible to stretch a WFC over metropolitan distances without relying on third-party storage replication technologies. Storage Replica supports both synchronous and asynchronous replication:
- Synchronous replication is designed for low-latency networks site and mirrors data to ensure zero data loss at the file-system level in the event of a failure.
- Asynchronous replication id designed for metropolitan networks with higher latencies but can experience some data loss in the event of a failure.
First announced with Windows Server 2012, Hyper-V Replica is designed to provide DR protection for Hyper-V VMs that run on a Windows Server Hyper-V host. Hyper-V replica enables you to create and maintain an updated copy or replica of selected VMs on another Hyper-V host. When you enable Hyper-V Replica for a selected VM the Hyper-V host server will create an identical copy of that VM on the target Hyper-V host. After the initial replication completes the primary host will begin capturing a log of the changes to the primary VMs virtual hard disks. The log file is then periodically forwarded and applied to the secondary Hyper-V host at the specified replication frequency. Hyper-V Replica doesn’t provide automatic failover to prevent false failovers in high latency networks that might experience lengthy disconnects. Hyper-V Replica also provides the ability to extend the replication to a third replica site. The Hyper-V Replicas can be in a separate geographical location or they can be in Azure.