Activate Data Datalabs Configuration
Activate Data Datalabs Configuration
Activate Data Datalabs Configuration
To get started with Veeam DataLabs, we need to create and configure the necessary components detailed above. This is done
with Veeam Backup & Replication™ by locating the “SureBackup” section on the “backup infrastructure” page.
Virtual Lab
The following section contains the configuration steps taken to get a Virtual Lab and proxy appliance in place to start leveraging
Veeam DataLabs.
NOTE: While the Virtual Lab settings can be changed after creation, the name of a Virtual Lab cannot.
Note: If you are defining a datastore for write cache, this may disable storage vMotion. This could be applicable when it comes
to Staged Restore later on in this publication. If you have a use case where you are moving a workload from a Veeam DataLabs
into another storage system, this should be noted.
This proxy appliance has at least two network adapters. One connects to the production network and has an IP address that
can be assigned either via DHCP or a static address. The other network adapters are connected to the various networks
configured within your LAN.
A key point to mention here is as we move through the configuration of the proxy appliance, the configuration should mimic the
production gateway configuration on the isolated environment side.
Note: It is highly recommended to have the proxy appliance production network on the same network where the Veeam Backup
& Replication server resides. If this is not possible, then routing rules should be added to the network to allow for connectivity.
Networking
The networking page provides us with three options. For the purpose of this walkthrough, I am choosing “Advanced Single-Host
(Manual Configuration)” as I believe this will be the most common configuration setting that people will use.
A virtual switch is deployed on the designated host and the corresponding port group is created with the same vLAN ID as the
production port group.
This option also allows for multiple production networks to be present within the Virtual Lab, ideal for scenarios when VMs have
dependencies on other VMs located in different networks but on the same ESX(i) host.
Note: SureBackup Jobs can only allow the selection of a single host on which to run the tested guests. All tested guests will use
single-host resources.
Note: This is only available in VMware vSphere and will require licensing that enables DVS technology.
If this option is used, special attention should be paid to the distributed switch vLANs as the vLAN IDs configured for the
DataLabs should be unique and must be tagged on the network equipment.
When you reach this page, you will have already defined your production network on the proxy page. A friendly name will also
be shown for the isolated network that can be edited should you wish.
This page configures the connectivity for the proxy appliance, adding the vNICs to the Linux-VM proxy appliances. The gateway
IP address of the production networks should be used on the vNICs, allowing the proxy appliance to act as a gateway for the
isolated guests without reconfiguring them.
The vNIC located within my isolated network has been configured with the address 10.0.40.1, which is my default gateway in
the production network.
The masquerade IP address is the IP range that will allow for connectivity from the production network into the isolated
network.
Note: The masquerade IP range should not be already in use on the production network.
The proxy appliance can also act as a DHCP server within your isolated network, providing IP addresses to applicable guests.
DNS servers can then be specified also.
Route network traffic between vNICs: This option has to be selected when the proxy appliance is acting as the router between
multiple isolated networks. This also means that the proxy appliance will act as the network gateway between them. I have not
selected this because I am only using one isolated network for the walkthrough.
Static mapping allows us to define access from a production IP to a specific masquerade IP server running within the isolated
network. As mentioned previously, this route is already added to the Veeam Backup & Replication server, however, static
mapping allows for any production machine to also gain access to this isolated environment. This includes the creation of DNS
entries on the production network(s) and allows ease of access throughout.
Note: The access IP must be on the same network that the proxy appliance is residing in.
Example: I have a web server running in a SureBackup Job that I would like access to, and the isolated IP address of that
machine within Veeam DataLabs is 10.255.254.100. From the Veeam Backup & Replication server — without any static mapping
— I can easily access that machine or offer this out to a group of workers. I could then define an IP address on my production
network that will be assigned to the proxy appliance, allowing access from any machine on the production network. I can then
use access tools such as PuTTY to SSH from anywhere in my production network to 10.0.40.200, providing me access to the
running web server in the DataLabs.
It is also possible to bypass the static mapping and just define the route on the system with which you want to access the
Virtual Lab. An example would be to enter the following command on the system (applicable on both Windows and Linux):
Application group
In this section, we will set up an application group where we specify the role of every VM, its boot priority and boot delay. We
will also touch on some configuration options we have here.
The next thing you will want to do is edit each of the machines you have selected in the previous step and define some
settings. I have skipped over roles here as this is covered in more detail in the following SureBackup section.
Startup options are applicable if you are looking to decrease the memory footprint of the VM. This can be based on a
percentage of memory allocated to the VM, or we can reduce the total memory assigned to the VM when it is powered on
within Veeam DataLabs. We can also define within this page the boot time and application timeouts, applicable if you have
certain VMs that may take a while to boot. You also have the boot verification tick boxes, which will ensure a heartbeat is
present and that a network ping is successful.
Summary
Once you have defined the startup options for your VMs, a summary is shown with the option to complete the wizard. The
application group configuration can be edited should you need to add additional configurations or new VMs from different
sources.
SureBackup/SureReplica
For the purpose of this walkthrough, I will be creating a SureBackup Job. You can access the SureBackup Jobs wizard from
either the backup infrastructure page previously shown or from the home ribbon at the top of the console.
Note: The SureBackup Job also allows for additional VMs to be added to the process during this wizard.
When the Virtual Lab is up and running, the linked jobs processing will commence and start all selected VMs. Powering on three
VMs in parallel is the default value configured in the SureBackup Job wizard.
Optionally, after the VM has been powered off, a cyclic redundancy check (CRC) can be run against the backup file.
Note: This operation is resource consuming and should be wisely selected, especially if the SureBackup timeframe is limited or if
the repository storage is not meant to serve intense IOPs.
Depending on the use case, you may wish to schedule a SureBackup Job so that it runs after a backup job or replication job.
We will cover differing use cases for this in the next section, but it is very simple and easy to schedule SureBackup Jobs to run
on a recurring basis, e.g., a daily or monthly basis or after a specific job.
Also, if a SureBackup Job is scheduled independently from the linked jobs or if multiple backup jobs are selected to be verified,
the option “wait for backup job” will allow the SureBackup Job to wait for backup completion.
• Veeam reconfigures the VMs and connects them to the isolated port groups of the Virtual Lab. If a network connection is
configured to be connected to a port group that is not available in the Virtual Lab, those networks are disconnected
automatically.
• Veeam creates a snapshot for the VMs in order to redirect write operations to the production datastore selected during the
Virtual Lab configuration and on which the virtual appliance files will be deployed.
• If the domain controller role is selected, registry settings are injected in the VM to ensure the NETLOGON service will not shut
down due to missing peer communication.
• During boot, VMware Tools announces the IP configuration of VMs. The SureBackup Job waits for this information to stabilize.
Note: If VMware Tools is not installed on the VM, the job will wait for the duration of the maximum allowed boot time
configured for the VMs. This will slow down SureBackup Jobs significantly. Therefore, it is always recommended to install
VMware Tools on a verified VM.
• PING tests are initiated according to the masqueraded network configuration. The ping is sent from the Veeam backup server
using the static routes added during the job execution. Since the masquerade network is not part of the Veeam backup
server's own subnet, the packet is sent to the gateway matching the Virtual Lab network (usually the Virtual Lab appliance).
• Application-specific testing uses scripts and is enabled based on the roles assigned to a VM in the application group
configuration. The built-in roles will check corresponding TCP ports for a given service. The built-in role for SQL Server
provides additional testing (see next section), and custom scripts may be used for third-party applications. Requests are sent
from the Veeam backup server, and the routing to the VM is handled by the Virtual Lab proxy appliance.
• CRC verification is optionally available and is disabled by default. If enabled, it will ensure all content of the backup file is
consistent with the hash values at the time they were written. This consistency check uses the CRC algorithm for hashing.
• Note: This feature reads the entire backup file and requires significant time to complete.
• Custom scripts are stored on the Veeam backup server and are launched by the account that controls the Veeam backup
service. The authentication mechanism used to run remote commands on the tested guests will depend on the operating
system.
• Windows script: Veeam Backup & Replication starts a new shell (cmd.exe) as the user running the Veeam Backup &
Replication service (default being “Local System Account”) and using the switch “/NETONLY” to access the specified
credentials (e.g., database user in the tested environment) only when through a remote connection. This is imposed by the
fact that the credentials needed for testing (specified in the credentials configuration tab) might not be existent in the domain
where Veeam backup services are running.
• Linux scripts will use a utility software called “plink.exe” to run remote commands over the Virtual Lab gateway. “plink.exe” is
executed by the account running Veeam services, while all subsequent commands in the script will use the credentials
specified in the SureBackup script configuration tab.
There are some included application tests within the application group creation wizard. Below, you will see a list of common
applications and roles that your VMs may be running, and you are able to leverage these scripts as part of your verification
tasks. Be sure to order the VMs in the correct order of boot sequence while also being aware that your selection of roles can
have an effect on boot times.
If a particular application script is not built-in, then there is also a custom script input where you can define a particular script
that you would like to inject into the process and verification stage.
SureReplica offers similar recovery verification of data, however, the use case here is that it allows you to simulate the
recoverability of your replicated workloads at your secondary location, simulating a disaster recovery (DR) failover. Like
SureBackup, this is executed in an isolated manner and without impacting performance or your production workloads.
SureReplica uses the same SureBackup wizard to configure and schedule this task. The difference here comes in the form of the
application group. Within the application group setup, instead of using a backup or storage snapshot as the source component,
you would select “from replicas.”
Similarly to SureBackup, within the application group, you will choose the VM(s) that you wish to add as well as the restore
point applicable to the test.
Different from the SureBackup process, however, is that vPower NFS is not used or required; the VM replica is an exact copy of
the VM with a set of restore points. This data is in an uncompressed format and is stored within your VMware environment in
the secondary location. This means the data is already there, and you do not need the additional vPower NFS step to present
data from the backup repository.
Veeam Backup & Replication re-configures the VM replica settings for recovery verification, connects the VM replica to the
isolated Virtual Lab and powers it on.
• A VMware snapshot is taken of the replicated VM. This snapshot is taken to protect the VM from any changes made during
the verification process. All changes that are made during the SureReplica process are stored in the delta file.
• VM, OS and application testing is performed against the VMs within the application group.
• Once verified, the delta file and any subsequent writes that occurred during the above process are removed.
Name
Firstly, we need to name and describe the application group.
That is the application group complete. Now, we need to create a SureBackup Job.
As well as the email reports, there are also more granular ways of receiving detailed information about recovery verification
tasks by utilizing Veeam ONE™. Veeam ONE is a monitoring and reporting platform that enables complete visibility into your IT
environment, including virtual and Veeam-protected physical and cloud workloads. Reports can be scheduled to run but are also
available on an on-demand basis. There are two notable reports available from Veeam ONE that include detailed information of
all your SureBackup Jobs.
This report helps administrators to review quickly the results of completed SureBackup Jobs and confirm that the created
backups and replicas are recoverable and error-free. This ensures that production VMs are reliably protected against failures
and data corruption.
• The total number of VMs for which the latest SureBackup Job session completed successfully
• The total number of VMs for which the latest SureBackup Job session completed with warnings
• Total number of VMs for which the latest SureBackup Job session failed
• Total number of VMs for which SureBackup Jobs have not been run at all
More details about these reports can be found in the following user guide links:
Verified VMs