Datto SIRIS appliances (both physical and virtual instances) can take agentless backups of virtual machines running on VMware vSphere. Agentless backups leverage the capabilities of the host hypervisor to capture a snapshot of the production VM even when it is shut down. For more information about the differences between agent-based and agentless backups, see this article.
Agentless backups do not require the installation of a backup agent on the target machine to facilitate communication with the Datto appliance. See the Backup Process section of this article for a technical overview of how agentless backups function.
- Target System Requirements and Compatibility
- Pairing a Target System for Agentless Backup
- Backup Process
- Additional Resources
- Because you no longer have to download an agent to your target VM, adding VM targets to Datto appliances has become quicker and easier.
- Backups are more efficient now that they are done through VMware's data storage API (VADP).
- Agentless backups work on both Windows and Linux virtual machines.
- We can run a backup even when a VM is powered off.
- Other common functions of the SIRIS remain the same.
- You are not forced to go agentless: you can still back up your machines using the Datto Windows Agent, Datto Linux Agent, Datto Mac Agent, or the ShadowSnap Agent.
Host System Prerequisites
Agentless backups run on physical SIRIS and Virtual SIRIS powered by vSphere versions 5.5, 6.0, and 6.5.
- vSphere Essentials
- vSphere Essentials Plus
- vSphere Standard
- vSphere Enterprise
- vSphere Enterprise Plus
To enable backups on a Windows VM, VMware Tools needs to be present on the target VM. For backups on Linux, install open-vm-tools-lts-trusty. This package includes the necessary VMware Snapshot Provider service.
Datto supports agentless backups of the following operating systems:
- All Windows Editions after 2000 / XP
- Ubuntu 12.04, 14.04 and 16.04.
- Debian 7.x and 8.x.
- Fedora 20, 21, 22, 23 and 24.
- Centos 5, 6.x and 7.x.
- RHEL 5, 6.x and 7.x
- openSUSE 13.1 and 13.2
- openSUSE Leap 42.1
- SUSE Linux Enterprise 11 sp4
- NOTE: VMware vCenter Server is unsupported.
- SUSE Linux Enterprise 12 sp1
- SUSE Linux Enterprise sp2 and openSUSE 42.2
Linux agentless backups support the following file systems:
- Agentless backups do not currently support Microsoft's Resilient file system (ReFS).
- SIRIS Virtual (and thus agentless backup) is not supported on the free version of vSphere (vSphere Hypervisor).
- Agentless backups are unable to work on encrypted VMs.
- Spanned volumes are not supported. Spanned volume support is available for agent-based backups only.
- Volumes formatted as ReFS are not supported.
- Agentless backups from a Physical Device (and failover for Virtual SIRIS) operate over Network Block Driver Transport Method; consequently are restricted in speed they may operate at, specifically to a maximum of 40% of the management network interface.
- Network Block Driver Transport Method backups are limited in concurrency dependent on the host's version of VMware.
The following is the process to pair a machine for backup:
From the GUI of your Datto appliance, click the Protect tab. You will see the window shown in Figure 1.
Figure 1: Protect a System
Click Agentless Systems. You will see the window shown in Figure 2.
Figure 2: VMware machines to protect
Check the boxes next to each target system that you want to back up. You can select multiple systems.
If your VM is not listed, click the Add Hypervisor Wizard link to create a new hypervisor connection.
The rest of the pairing process is the same as for agent-based systems. See the Agent Installation Wizard article for more information.
When the process is complete, you will see a Successfully Paired notification appear next to each selected system, as shown in Figure 3. You will also see a new entry for each agent on the Protect tab of the GUI when you click Return to Agent Overview.
Figure 3: Successful pairing
Before a Datto appliance can take an agentless backup, it needs to be connected to your hypervisor. For hypervisor connection steps, see the article Connecting A Datto Appliance To A VMware Hypervisor.
Unlike agent-based backups, which are VSS-dependent, in an agentless backup, the Datto appliance interacts directly with your hypervisor to snapshot and back up a virtual machine. It does so by taking the following steps:
- The Datto uses the hypervisor connection to connect to the vSphere environment.
- It uses the VMware snapshot provider (part of VMware tools), to take a snapshot of the VM.
The first two steps also occur when the Datto pairs with the target VM.
- If the Datto device is a virtual appliance, it can use hot add (through vddk-fuse) to directly attach the VMDK from the VMware snapshot to itself. Using hotadd, the backup data is transferred over the vSphere management network.
As a failover, or if the Datto device is a physical appliance, it connects to the VMDK from the VMware snapshot using the Network Block Device (NBD) protocol. With this type of connection, the backup data is transferred over the VM network.
- The Datto appliance uses libguestfs to analyse the disk image to get necessary information about the disk structure and the file system(s) on it.
- The appliance transfers the backup data from the VMware snapshot of the VMDK to itself, and takes a ZFS snapshot of the disk images in the live dataset, just like an agent-based backup.
Figure 4 illustrates the data flow for the agentless backup process.
Q: Are the backups saved on the datto device thin or thick provisioned?
A: Agentless backups transfer to the Datto appliance as a sparse image, a type of disk image file that takes up only as much disk space as is stored in it. Sparse images grow in size as the user adds data to them.
Sparse images are similar to a VMware thin-provisioned VMDK. Unlike a thick-provisioned VMDK, a sparse image file should not take up the full size that the virtual disk was originally provisioned as.
Over time, as files are deleted or overwritten by the production VM, both a thin-provisioned disk as well as a sparse image file will grow. This is because VMware has no way to tell that these files have been removed or altered; even though these blocks are marked as free in the filesystem, they will copy into the backup image.
As an example, a 100 GB VMDK with only 30 GB used, but an additional 50 GB of disk change, could produce a backup of 80 GB. See VMware's article about Growing, thinning, and shrinking virtual disks for VMware ESXi and ESXi for information about resizing these types of disks.
Q: Does agentless have any size limitations for the VMDK hosted on the hypervisor?
A: When backing up a protected virtual machine, virtual Datto appliances use a hot-add vddk protocol, which attaches the protected machine's disks directly to the Datto device. Virtual disk size is only limited by the amount of free disk space on the appliance's array.
Physical SIRIS devices leverage the NBD vddk protocol. Virtual Datto appliances will also failover to the NBD protocol if hot-add fails. With NBD, VMware recommends using virtual disks that are no larger than 1TB in size.
Note that while using the NBD protocol, the VMkernel will automatically cap each session for stability. This cap can result in lower backup throughput, but the kernel does this so that VM management and other VMkernel traffic are not bottlenecked by NBD transfers. The VMkernel’s primary function is to orchestrate VM processes.
You can counteract this problem by designing your backup policies and job configurations to distribute the load over multiple ESXi hosts, instead of having multiple backup jobs run from the same ESXi host simultaneously.
Q: How are incremental backups accomplished without having agent software running in the Protected VM's guest OS?
A: Agentless backups leverage the VMware Changed Block Tracker (CBT), which keeps track of changed or newly-written blocks within a virtual machine. Every time a new backup task begins, the Datto solution uses the VMware CBT values to detect disk change and only back up the changed data.
If a virtual machine's hardware version is version 6 or older, or the CBT is corrupt, every backup for that machine will be a full backup until you upgrade the hardware version or repair the CBT.
Q: What are some of the other things that can cause a full backup on a virtual machine?
A: Certain code issues in unpatched versions of ESXi 5.1 and ESXi 5.5 have been known to cause frequent full backups. Datto recommends keeping your hypervisor versions patched and up-to-date to help avoid these issues.
Running third-party agentless solutions alongside Datto's agentless solution on the same production machine can cause full backups by corrupting the CBT. Datto does not recommend running multiple agentless backup utilities on a production machine at the same time.
Q: Without agent software installed in the protected virtual machine's guest OS, how is Datto able to take application-aware backups?
A: The Datto solution leverages a VMware feature called quiesced snapshots. When taking a quiesced snapshot, VMware pauses writes to the virtual machine's virtual disk to achieve a consistent state. To back up a Windows guest OS, the Datto solution also uses the virtual production machine's VSS writers. If a quiesced snapshot of a VM fails to complete, a backup job will not run.
Without quiescing, VMware snapshots are only crash-consistent.
Q: I have a vSphere cluster, and I'm trying to set up a hypervisor connection to it from my SIRIS. Should I connect to an individual ESXi host, or to the vCenter Management Server?
A: VMware has two values that it uses to assign each Virtual Machine a unique identifier the vmID, and the morefID. vmIDs are only unique at the ESXi host level. morefIDs are unique across an entire vCenter cluster. If you're going to be using a clustered environment, you will need to connect to the vCenter management server.
If you use a standalone connection to an individual ESXi host instead, the vmID of any vMotioned virtual machine will change. Because the standalone connection only uses the vmID, backups will fail until you determine what the replacement vmID is and you reassociate the backup chain to the new vmID.
The easiest way to tell the difference between a morefID and a vmID is their format. A morefID will be proceeded by the prefix vm-. A vmID will not have this prefix. As an example, a valid morefID is vm-9463. A valid vmID is 17.
If you start agentless backups via a standalone connection, and you later switch to a vCenter cluster connection, you must change all vmIDs to morefIDs on the back-end of the device to get backups running again.
Q: Are VMware snapshots a good backup strategy? Should I take some manually and keep them around just in case?
A: Snapshots are useful as a secondary backup method for short-term or ad-hoc backups. Note that while snapshots are growing in size, the entire LUN that a VM resides on needs to be locked by the Datto appliance, slowing down I/O performance for that VM and all other VMs sharing the same LUN. Keeping snapshots for a long period of time will also negatively impact the performance of your production VMs. Finally, consolidating a virtual disk that has long-term snapshots takes a very long time, and can cause a negative impact to the I/O performance of that VM.
By default, the snapshots that Datto appliances take persist for only as long as it takes to backup any given target virtual machine.