Perform Application Aware Veeam backups in DEV STG LAB Environments

For those of you who are running lab environments for development and staging, first off, kudos. Development and testing should always be done in a development and staging environment. Many smaller development shops may find it difficult to change the mentality and process of either developers or IT changing things in production on the fly without proper testing. Having a lab that as closely resembles production as possible is a great way to properly test changes and perform regression testing. However, challenges can present themselves when it comes to backing up development and staging environments that have the same server names and IP addresses. When you are using a backup server that exists on the production LAN with the same servernames on the production LAN as exist in lab environments how can you perform application aware backups? Let’s take a look at how to Perform Application Aware Veeam backups in DEV STG LAB Environments.

Perform Application Aware Veeam backups in DEV STG LAB Environments

Let’s take a closer look at the problem that is presented in this scenario.  Below we have a crude layout of the problem scenario.  We have a Veeam Backup & Replication server that exists on the production network along with a Veeam server housing the proxy role.  We have two VMs that are named the same name and have the same IP addresses.  One is found in the production environment and one is found in the development, staging, or lab environment.  A simple image-level backup of the VMware virtual machine will be successful for both virtual machines.  Veeam in that case just needs to talk to VMware vCenter Server and perform the snapshot operations on the virtual machines as they exist in inventory.  However, what if we want to perform “application aware” guest processing, such as truncating SQL logs, etc?  In the scenario below, what is not shown in this simplistic representation is that we have NAT’ing and DNS records that allow the VeeamBackup server to communicate at a network level to the Server1 in the DEV environment.  If we want to perform application aware backups such as SQL log truncation, we would have a problem.

Problem:

• The Veeam proxy server would talk to the VMware tools of the VM that is located in the DEV lab and get the IP address for the server and the server name as well.  Instead of performing the application aware backup on the DEV instance of the server, Veeam would think the server that needs to have application aware processes ran would be the server in production.

According to Veeam, the following is how the application aware backup process works:

How Application-Aware Processing Works – found at https://helpcenter.veeam.com/docs/backup/vsphere/application_aware_processing.html?ver=95

If you enable application-aware processing for the job, Veeam Backup & Replication performs the following operations as a part of the backup or replication process:

1. Veeam Backup & Replication deploys the runtime process on the VM and detects if the VM runs VSS-aware applications.
2. Veeam Backup & Replication collects information about applications installed on VMs; this information is required for VSS-aware restore.
3. Veeam Backup & Replication prepares applications for VSS-aware restore (VSS-aware restore is performed when the VM is started after you restore it from the backup or fail over to a VM replica).
4. Microsoft VSS communicates with applications and quiesces I/O activities at a specific point in time.
5. Veeam Backup & Replication acts as a VSS requestor and triggers a VM VSS snapshot.
6. Veeam Backup & Replication triggers a VMware vSphere snapshot of the VM.
7. Microsoft VSS resumes quiesced I/O activities on the VM guest OS.
8. The job session proceeds as usual.
9. If you have instructed Veeam Backup & Replication to truncate transaction logs, Veeam Backup & Replication truncates transaction logs on the VM guest OS after the backup or replica are successfully created.

The solution to the problem is two-fold.  First, we would place an additional Veeam Backup & Replication Proxy server inside the lab environment.  The Veeam Proxy server would “know” about the Server1 server in the DEV environment.  We can IP the Veeam proxy server in the DEV environment to reside on the same VLAN and subnet of the DEV virtual machine.

Secondly, we would need to make sure the Backup Proxy used for the specific job(s) in the DEV lab that need application aware processing, would use the VeeamProxy2 server for both the Backup Proxy as well as the guest interaction proxy.

Below as examples, you can manually select both the backup and guest interaction proxies for both operations.  This would need to be done on a backup job that was performing application aware backups of a server that is using the same server name and IP address in a DEV STG LAB environment.

Takeaways

Creating DEV STG and LAB environments are a great way to perform development and testing operations without impacting production.  This is also a compliance requirement for organizations falling under certain regulations such as PCI-DSS.  If you have servers that are using the same IP addresses and server names in a DEV STG LAB environment, performing application aware backups will fail.  However, thinking about and having the mobility of where the proxy role is deployed will allow you to customize how backup traffic is funneled from the DEV STG and LAB environments over to the Veeam Backup server.  The only other option is to move a Veeam Backup server over into the network environment the DEV STG and LAB versions are running in.