As you know backup is very critical when it comes to virtualized environment.
In the traditional days, when you lose a server, you lose that particular server, however in server virtualization it’s not just another server, if you lose that host, you lose your entire infrastructure servers, and Hyper-V Cluster/Replica won’t protect you against data corrupting malware, unforced user errors, misbehaving applications, and updates that go awry…
My favorite backup component is System Center Data Protection Manager (DPM)…
Yes, it’s true there are many modern products out there for Hyper-V and VMware, and their preferred color is Green :) , but DPM protect all my physical and virtual workloads, including SQL, users files, Hyper-V Item-level recovery (ILR), etc… it’s awesome!
Let’s jump into the challenging piece on how to isolate DPM backup traffic and protect our Virtual Machines in Hyper-V.
The backup network for Hyper-V is not listed as requirement by Microsoft, but I strongly recommend to isolate the backup traffic from the host Management OS, and by leveraging the converged network in Hyper-V were combining multiple physical NICs with NIC teaming and QoS we can isolate each network traffic while maintaining resiliency as shown in below diagram:
Now how can we force DPM and Hyper-V to use that Backup vNIC from the Management OS?
Let’s jump to our DPM server and list the backup network address using PowerShell:
As you can see we don’t have any Backup Network set yet, by default DPM use the production network address.
Given the following scenario:
DPM.DEMO.com server Backup Address = 10.10.88.7
DPM.DEMO.com server Production Address = 172.16.20.106
HV01.DEMO.com server Backup Address = 10.10.88.20
HV01.DEMO.com server Production Address = 172.16.20.252
First, the prerequisites for backup network functionality are as the following:
DNS resolution on DPM server for the Protected Hyper-V Server should be able to resolve the backup IP (10.10.88.20).
DNS resolution on SQL Server for the DPM Server should be able to resolve the backup IP (10.10.88.7).
This will also work using the Host file since most likely the backup network will not have a DNS Server.
1- Add the FQDN and Backup NIC’s IP address of the DPM Server to the protected Hyper-V server under C:\Windows\System32\drivers\etc\hosts file. This forces the protected Hyper-V Server to communicate with the DPM server over the backup NIC (DPM.DEMO.com 10.10.88.7).
2- Add the FQDN and Backup NIC’s IP address of the protected Hyper-V Server to the DPM server under C:\Windows\System32\drivers\etc\hosts file. This forces the DPM server to communicate with the protected Hyper-V Server using the backup NIC (HV01.DEMO.com 10.10.88.20).
Second, now that we have the Backup NIC is set, the backup subnet address and mask should be configured on the DPM Server through Add-BackupNetworkAddress PowerShell cmdlet.
PS C:\Add-BackupNetworkAddress -DpmServername DPM -Address 10.10.88.0/24 -SequenceNumber 1
PS C:\Add-BackupNetworkAddress -DpmServername DPM -Address 172.16.0.0/16 -SequenceNumber 2
(Note that you also need to configure the production network as a 2nd backup network for a fallback plan and also for protected servers that are not configured with a backup network).
Last, DPM Agents (DPM and Protected Servers) should be restarted to ensure that the backup network settings are in effect. (Stop any active backup jobs, then run net stop DPMRA / net start DPMRA on both DPM and Protected Server).
Now run the backup jobs and notice the backup traffic flow now :)
To list the configured backup networks use:
PS C:\Get-DPMBackupNetworkAddress -DpmServername <DPM>
To Remove backup networks use:
Ps C:\Remove-DPMBackupNetworkAddress -DpmServername <DPM> -Address 172.16.0.0/16
For more information on how to Improve performance with backup network address Read this Microsoft Article.
Last but not least, by keeping the backup traffic off your production network allows you more bandwidth without having to wait for off working hours to get backups of your data, but this does not mean that you will not see potential performance issues as the servers are backed up, but the impact will be much less especially when you isolate the backup traffic as described above and throttle the network bandwidth of your servers.
Until next time… Enjoy your day!