This article provides an overview of Datto's agentless backup solution. To learn about the differences between agent-based and agentless backup solutions, see this article.
- Protected Machine Compatibility
- Hypervisor Compatibility
- System RequirementsCSHost System Prerequisites
- Pairing a Target Machine for Agentless Backups
- Frequently-Asked Questions
- Additional Resources
Datto SIRIS appliances (both physical and virtual instances) can perform 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.
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.
- 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: if you prefer, you can still back up your machines using the Datto Windows Agent, Datto Linux Agent, Datto Mac Agent, or the ShadowSnap Agent.
- If you choose to leverage an agent-based solution, see our article about Cluster Shared Volume (CSV) compatibility for important deployment considerations.
- SIRIS Virtual (and thus agentless backup) is not supported in 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.
- ESXi shared volumes, multiple volumes using the same GUID, and volumes formatted using Microsoft's ReFS are not supported.
- Dynamic Disk Technology is unsupported.
- 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 agentless backup solution can protect the same operating systems as the Datto Windows Agent and the Datto Linux Agent. To determine if your production system can be protected by the agentless solution, see the following articles:
- Getting Started with the Datto Windows Agent: Compatibility
- Getting Started with the Datto Linux Agent: Compatibility
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
Target virtual machines must be running virtual machine hardware version 7 or higher. See VMware's Virtual machine hardware versions article for more information on how to determine if your virtual machine's hardware profile is up-to-date.
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.
Linux agentless backups support the following file systems:
The host hypervisor and protected virtual machines must be in a healthy, stable state. For more information see Agentless Backups: Best Practices.
The networking environment of the Datto appliance and the hypervisor must meet the requirements defined in the SIRIS, ALTO and DNAS Bandwidth & Networking Requirements article.
Pairing a Target Machine for Agentless Backup
To pair a target machine for agentless backup protection, see the Pairing a Target System for Agentless Backups article.
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.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.
- Virtual Disk Transport Methods (external link)
- Changed Block Tracking (CBT) on virtual machines (external link)
- Changed Block Tracking is reset after a storage vMotion operation in vSphere 5.x (external link)