Inside Look: System Center 2012 R2's New Data Protection Manager
Microsoft System Center 2012 R2 Data Protection Manager is now better suited for virtual environments, Linux servers, SQL Server support and provides more consistency.
With the recent release of the new Microsoft System Center 2012 R2, the company has added some compelling features to the Data Protection Manager (DPM) component. Though the new DPM largely resembles the previous release, Microsoft did add some important capabilities, including changes to how it protects the company's SQL Server database, support for Linux clusters, support for virtual deployments and improved consistency.
Upon evaluating the new DPM release, these improvements should be welcomed by those responsible for ensuring adequate business continuity. While most shops use third-party data protection software, they often use DPM alongside it or to back up servers or virtual machines (VMs) separately.
Improved Virtual Protection
Technically, DPM has worked in virtualized environments for quite some time. I have personally deployed some of the older DPM releases in Hyper-V VMs when I've needed to quickly deploy a DPM server to experiment on for an article I was writing. Even so, DPM has never been officially supported in virtualized environments until now.
If you're considering running DPM in a VM, there are a few things you'll need to consider. First is tape drive support. Hyper-V doesn't natively provide any sort of tape drive emulation. This is a problem for DPM, because DPM generally uses tape for long-term protection of data. There's even an option to use tape for short-term data protection. According to Microsoft, the only supported method for writing data from DPM to tape when DPM is running in a VM is to use an iSCSI-attached tape drive. When doing so, Microsoft recommends using a dedicated physical NIC for tape drive connectivity.
Another important consideration is storage. As noted, when DPM is running on a physical machine, it takes control of one or more physical disks and treats those disks as a dedicated storage pool (A DPM storage pool is different than a Windows Storage pool).
The requirement for a DPM storage pool doesn't go away just because DPM is running on a VM. Fortunately, there are a number of different types of disks that can be used by DPM, including:
- Pass-through disks that exist as DAS for the Hyper-V host (keep in mind the impact this configuration will have on live migrations)
- A pass-through iSCSI LUN initiated at the host level
- A pass-through Fibre Channel LUN initiated at the host
- A VM-initiated iSCSI target
- A Fibre Channel LUN connected to the VM using the Hyper-V Virtual Fibre Channel feature
In addition, you can install DPM to a virtual hard disk (VHD). VHD and VHDX files are both supported, although there are a number of restrictions around their use. For instance, Microsoft doesn't support the use of VHDs built on top of Windows Storage Spaces. VHDs are also not recommended for scaled up environments.
In addition, Microsoft doesn't support deduplication of volumes hosting VHDs used by DPM. You must also avoid using other NTFS features, such as compression or encryption (including BitLocker encryption). You can read the full support requirements for the use of VHDs with DPM here.
Domain Membership Considerations
If you're considering virtualizing your DPM server, one of the most important considerations you must take into account is the DPM server's domain membership.
Oftentimes Hyper-V administrators create two separate Active Directory forests. One forest is a management forest. All of the Hyper-V hosts are joined to a domain within this forest as a way of making the hosts easier to manage. There's also usually a VM-level forest that includes virtualized domain controllers and all of the production VMs.
Like other System Center products, DPM has a dependency on the Active Directory forests. As such, you'll have to make some decisions with regard to which forest your DPM servers will be joined. If you join your DPM servers to a VM-level forest, then you'll be able to perform backups of the individual VMs. On the other hand, if you join your DPM servers to the management domain, then you'll be able to back up entire Hyper-V host servers. These types of host-level backups offer sufficient granularity to restore individual VMs or files, folders and applications within a VM.
Generally speaking, it's best to join your DPM servers to the management domain. If you don't use this type of Active Directory structure, then I recommend deploying DPM in a way that will facilitate backing up your Hyper-V servers at the host level. I'll talk more later on about why this can be so important.
One of the big things that Microsoft has attempted to do in the System Center 2012 R2 product release is to provide better support for Linux. As such, it should come as no surprise that DPM now offers the ability to create online backups of running Linux VMs.
The documentation pertaining to Linux backups for DPM is quite lacking and there's a lot of contradictory information on the Internet. That being the case, I decided to put the Linux backup capabilities of DPM to the test by deploying some Linux servers of my own.
For this test, I created two Hyper-V VMs. One is running SUSE Linux Enterprise Server 11 SP3. The other is running Ubuntu 13.10. The host server also contains several Windows VMs, some of which are running and some that aren't.
When I created a protection group for the VMs, the Create New Protection Group Wizard indicated whether each VM would be backed up online or offline. I fully expected the Windows VMs running to be backed up online (which they were) and the VMs turned off to be backed up offline. What surprised me, however, was the way my Linux VMs were backed up.
As you can see in Figure 1, an Ubuntu VM is backed up offline (which holds true to what I expected, even though the VM was running and I had manually enabled the Hyper-V Integration Services). On the other hand, my SUSE Linux VM was backed up online. So,why the difference?
Again, the documentation for DPM Linux support isn't very good, but according to one TechNet post Windows Server 2012 R2 only has online backup support for SUSE Linux Enterprise Server 11 SP3, but support for other Linux versions is in the works.
One thing to keep in mind, however, is that even though online backups of Linux VMs are possible in some situations, online backups for Linux only offer file-level consistency. DPM doesn't provide application-consistent backups for Linux.
As noted, if you were going to run DPM within a VM to which you'd have to choose which Active Directory forest to join the DPM servers, it becomes especially important if you need to back up Linux VMs.
Though you can join a DPM server to your production domain and then back up individual physical and virtual servers, this approach requires you to deploy a DPM agent to each machine you want to back up. The problem with this is that there are no DPM agents for Linux VMs. Therefore, if you need to back up Linux VMs, then you should join your DPM servers to the management domain so that you can back up Hyper-V servers as a whole, which will allow you to back up your Linux VMs.
New SQL Server Protection
DPM has always depended on SQL Server and with this new release Microsoft has made a number of changes regarding support for the database. For starters, you must deploy SQL Server before you begin deploying DPM. Some of the previous versions of DPM would allow you to deploy SQL Server as a part of the DPM deployment process. However, this option doesn't exist in the System Center 2012 R2 version.
On the topic of SQL Server deployments, there's a bug in the DPM Setup program that can be particularly frustrating. During the prerequisite check, Setup will verify it can communicate with SQL Server and everything is configured correctly. Once all of these checks complete and the actual installation process begins, however, you might receive an error message telling you to make sure the SQL Server Reporting Service is running and is configured correctly.
When the prerequisite checks occur, Setup verifies the SQL Server Reporting Service (and some of the other SQL Server services) are running using either the local system account or a domain-based service account. From what I've been able to determine (there's no definitive documentation), for deployments using SQL Server 2012 SP1, the SQL Server services must be running under a domain service account. Setup will fail if you attempt to use the local system account. DPM also supports using SQL Server 2008 R2, but I've only tested for the bug when using SQL Server 2012 SP1.
Another change Microsoft has made regarding SQL Server is there's now a 1-to-1 relationship between SQL Server databases and DPM servers. This goes a long way toward improving scalability because it can help you distribute the database workload across multiple SQL Servers, rather than having a single SQL Server that's responsible for everything.
Perhaps the most significant SQL Server-related change Microsoft has made is that DPM now supports the use of SQL Server clusters. In fact, the Setup program for DPM even includes a prompt (see Figure 2) asking if you want to use a standalone SQL Server instance or if you would prefer to make use of a SQL Server cluster.
Before you get too excited about support for SQL Server cluster support, it's important to understand how DPM uses SQL Server. Unlike Microsoft SharePoint Server, DPM doesn't use SQL Server as its primary data repository. Instead, SQL Server is a mechanism for storing indexing data and other types of data necessary for the overall functionality of DPM.
The actual backup data exists outside the SQL Server database. DPM requires the reservation of one or more disks it can use as a storage pool. DPM will then convert this disk to a dynamic disk and then automatically create a series of volumes it will use to store the protected data. Figure 3 shows how you can create a DPM storage pool.
Over the years, I've heard of a number of people completely abandoning DPM due to its data consistency problems. For those who are not familiar with this issue, backup data sometimes becomes inconsistent with the resource that's being protected. When this happens, a manual consistency check is required as a way of bringing everything back into a consistent state. Sometimes it can be impossible to resolve a consistency problem and the administrator is forced to delete and recreate the protection group, which means losing any previously created backups.
The good news is Microsoft has done a lot of work around protection group consistency lately. Although the problems related to inconsistencies haven't been completely resolved, Microsoft has finally built in automated consistency checking. In fact, you can schedule consistency checking when you create a protection group, as shown in Figure 4. This feature isn't new to DPM 2012 R2, but it is such a helpful feature that I wanted to mention it for those who might have had bad experiences with DPM in the past.
Although System Center 2012 R2 Data Protection Manager doesn't boast a huge list of new features, the features Microsoft has introduced are important. DPM is better equipped than it's ever been to function in a heterogeneous virtual datacenter.