Agent and Agentless Backups
-
Agentless backups are the darling of the backup world. They are the shiny new technology that everyone wants, but do they really make sense?
First, agent based backups refer to backups where a software agent is installed on an operating system and the backup is taken from "inside" the OS. This requires deploying an agent to each OS instance (normally a VM) which many find inconvenient.
Agentless backups use an intrinsic backup agent and API from a hypervisor (or similar virtualized storage mechanism technically) to take backups of workloads running on top of the platform. This does not require deploying anything (other than the backup backend, of course) to the end points.
Both have their place, they are two different mechanisms to do the same thing. One is not dramatically different from the other. They just take place in two different layers. Both have gaps that must be addressed even higher in the stack for certain workloads. Both are mature and robust.
The core benefits from agentless are associated with not needing to install and maintain agents, and through robust tools like change block tracking. However, it must be noted that change block tracking is not unique to agentless, so this is not a benefit of this approach. So the core benefit is not needing to deploy agents.
One must ask, of course, "what is the overhead of installing agents?" There is overhead, but generally it is very low. Agents can be easily built into system images, deployed by script or state, or even pushed by the backup system itself. Agent management is, traditionally, not an itch needing to be scratched.
At their heart, agent and agentless systems share all the same infrastructure. They back up to the same places, do the same things. Often vendors make both and they are used interchangeably.
Agentless backups are ideal when you want to push backup duties to the platform team, leaving system admins free to ignore backups completely.
Agent backups are ideal when you want to push backup duties to the systems team, leaving platform admins free to ignore backups completely.
For smaller shops, systems and platform people are the same people and this separation of duties benefits are null.
In both cases, the systems actually have agents, just one is built into the platform. Both have limitations in what they can support and require careful understanding of workloads, scripting or alternative management of certain data types, etc. The bulk of backup duties are shared between the approaches, there is essentially no difference in effort or technique.
Agent based backups have some unique benefits that are often overlooked. The key one is platform agnosticism. Agentless backups require that the platform in question have all of the necessary backup infrastructure built into it, and then requires API access to that "agent". This can be limiting making products often only work with one or two key platforms.
Agent based has to be written for each OS in use, but today the number of broadly deployed OSes is much smaller than the number of deployed hypervisors. For production servers Linux, Windows, Solaris, FreeBSD and AIX are essentially all that there are. With Linux and Windows representing nearly all deployed servers. For hypervisors, we have to consider not only the base products but resulting variants so the base products like KVM, Xen, Hyper-V, and VMware ESXi (plus type 2s perhaps), plus appliances like Scale, Nutanix, Simplivity, etc. and then cloud vendors like AWS, Vultr, Digital Ocean, Linode, etc. The range of needed support is far bigger and no vendor has broadly tackled this market.
Because of this, agent based backups typically offer a single, unified backup strategy that agentless is unable to provide. Agent based backups work on any platform, solving the problem of having different, moving between, or having unsupported platforms under the OSes. Agent based backups allow for the modern idea of the hybrid environment with VMs able to move from one platform to another, even to cloud. Agent based also allows for physical workloads, which still exist in many environments.
Agentless can be a great technology. But there are two large human behaviours that I commonly see associated with it that make it very dangerous. One is to believe that it is magic and requires no knowledge or management ignoring standard backup knowledge that has existed for decades. Two is to see agentless backup, with its minimal advantages, as so critical and important, that the desire to use it often drives all other decision making when nearly all other factors are more significant. A tertiary concern is that often agentless vendors who have agent products are misunderstood and seen as agentless only and so a desire to work with a vendor often drives people to agentless even when that vendor has a great agent based product.
These factors are my greatest concerns about seeing agentless backups deployed broadly. They are often deployed for the wrong reasons with major misunderstandings, and often by VARs who have seen a decline in margins on agent based backups and have seen agentless as a way to ramp up profits again in a space that seemed to have died out.
Agent and agentless approaches can be mixed, of course, often from a single product or vendor, there is no need to use exclusively one or the other unless the desire for unified approach is so great, then agent based takes the clear lead. Both should be seen as tools in the toolbox, never should a trendy new buzzword or tech trend be used simply because marketing pushes it or the market sees it as fashionable. Agentless backups have given us a new tool to leverage, and will continue to improve and spread. But for the foreseeable future, agent based backups are more flexible and robust and often less costly while providing us more ability to design our infrastructures around the needs of our business, rather than the needs of a favourite backup product.
-
@scottalanmiller said in Agent and Agentless Backups:
Agent based has to be written for each OS in use, but today the number of broadly deployed OSes is much smaller than the number of deployed hypervisors. For production servers Linux, Windows, Solaris, FreeBSD and AIX are essentially all that there are. With Linux and Windows representing nearly all deployed servers. For hypervisors, we have to consider not only the base products but resulting variants so the base products like KVM, Xen, Hyper-V, and VMware ESXi (plus type 2s perhaps), plus appliances like Scale, Nutanix, Simplivity, etc. and then cloud vendors like AWS, Vultr, Digital Ocean, Linode, etc. The range of needed support is far bigger and no vendor has broadly tackled this market.
Rose colored glasses in action if I ever saw it.
-
@jaredbusch said in Agent and Agentless Backups:
@scottalanmiller said in Agent and Agentless Backups:
Agent based has to be written for each OS in use, but today the number of broadly deployed OSes is much smaller than the number of deployed hypervisors. For production servers Linux, Windows, Solaris, FreeBSD and AIX are essentially all that there are. With Linux and Windows representing nearly all deployed servers. For hypervisors, we have to consider not only the base products but resulting variants so the base products like KVM, Xen, Hyper-V, and VMware ESXi (plus type 2s perhaps), plus appliances like Scale, Nutanix, Simplivity, etc. and then cloud vendors like AWS, Vultr, Digital Ocean, Linode, etc. The range of needed support is far bigger and no vendor has broadly tackled this market.
Rose colored glasses in action if I ever saw it.
In what way? Very realistic. Almost every company trying to go agentless runs into the "but it doesn't support X" that they do. In both the SMB and the enterprise, having the ability to throw money at platform decisions in order to have something the backup can support is unrealistic. A few tiny companies get lucky, but often end up not realizing that they don't have the backups that they thought that they did (consulted on this with an MSP pushing agentless to make quick sales and tried to convince the customer that app support wasn't needed - leaving their entire business unprotected and backing up nothing of value just for show.)
These days, companies use lots of different things for platforms, that flexibility keeps costs down and capabilities high. Even small ones, where saving money is often more important.
-
Completely depends on the existing environment, and a lot of other factors.
If you are doing server images and/or use something like SaltStack for example that can make agent installation and configuration automated and easy, then sure.
Weighing the number of agents you would need and if the backup software costs per agent, VS agentless that costs per hypervisor... that could also sway one in a specific direction.
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
It comes down to a lot of factors and to simply say agent-based backups should always be used I think is not a good statement.
-
@obsolesce said in Agent and Agentless Backups:
Weighing the number of agents you would need and if the backup software costs per agent, VS agentless that costs per hypervisor... that could also sway one in a specific direction.
Pricing models never apply in a discussion of this nature. Not in this way, anyway. You can sum it up as "cost is a factor", but this is IT, cost is always a factor. Agent and agentless don't have different pricing models. Agentless can easily price per VM if they want, agent can price by the physical server if they want. There is no assumed licensing model as that is purely at the discretion of the vendor. And both can be free, or locked together as is often the case.
-
@obsolesce said in Agent and Agentless Backups:
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
No, also not a factor. Both agent based and agentless do both of these options. That's why I didn't bring these things up. So many of the assumed benefits of agentless backups are myths. Lots of agent based backups do this stuff.
-
@obsolesce said in Agent and Agentless Backups:
It comes down to a lot of factors and to simply say agent-based backups should always be used I think is not a good statement.
And it was never said, nothing is an "always use". However, agent based backups are probably the more common use case. Agentless requires a very niche scenario to work, or to work alone without agents added on. Agents work in nearly all scenarios.
There aren't as many factors as people often state, which is part of my goal here. So many factors that people believe drive then to agentless aren't really valid factors - like cost, licensing approach, restore capabilities, change block tracking, etc.
-
@obsolesce said in Agent and Agentless Backups:
If you are doing server images and/or use something like SaltStack for example that can make agent installation and configuration automated and easy, then sure.
Even without something like that, what situation is there where agent deployments is hard or cumbersome? Salt is one answer, sure, and a great one, I agree. But Group Policy, system images, or if you have only one or two VMs, just manual installs. Agent installations are typically so easy that no one ever thinks about them.
-
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
No, also not a factor. Both agent based and agentless do both of these options. That's why I didn't bring these things up. So many of the assumed benefits of agentless backups are myths. Lots of agent based backups do this stuff.
How does an agent installed in a VM back up the VM as a whole? That doesn't make sense. You would still need to re-create a blank VM on the host, and after that, restore the VM data from backup as if it was a physical box.
-
@obsolesce said in Agent and Agentless Backups:
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
No, also not a factor. Both agent based and agentless do both of these options. That's why I didn't bring these things up. So many of the assumed benefits of agentless backups are myths. Lots of agent based backups do this stuff.
How does an agent installed in a VM back up the VM as a whole? That doesn't make sense. You would still need to re-create a blank VM on the host, and after that, restore the VM data from backup as if it was a physical box.
They really can do that
It's been something that agent based backups have been able to do for a really long time. -
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
No, also not a factor. Both agent based and agentless do both of these options. That's why I didn't bring these things up. So many of the assumed benefits of agentless backups are myths. Lots of agent based backups do this stuff.
How does an agent installed in a VM back up the VM as a whole? That doesn't make sense. You would still need to re-create a blank VM on the host, and after that, restore the VM data from backup as if it was a physical box.
They really can do that
It's been something that agent based backups have been able to do for a really long time.You'll have to show me an example, I've not seen it... unless we are misunderstand each other here. I find it hard to believe.
-
Do you mean that the agent on teh VM makes contact with the hypervisor to backup itself at the host level?
-
@obsolesce said in Agent and Agentless Backups:
Do you mean that the agent on teh VM makes contact with the hypervisor to backup itself at the host level?
No need to back up at the host level. You can get the entire VM from inside the VM. Change Block Tracking, Snapshots and similar tools have made this possible since the 1990s (very end of.)
-
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
Do you mean that the agent on teh VM makes contact with the hypervisor to backup itself at the host level?
No need to back up at the host level. You can get the entire VM from inside the VM. Change Block Tracking, Snapshots and similar tools have made this possible since the 1990s (very end of.)
Pull your head out of your ass. That is not what he is stating.
-
@obsolesce said in Agent and Agentless Backups:
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
No, also not a factor. Both agent based and agentless do both of these options. That's why I didn't bring these things up. So many of the assumed benefits of agentless backups are myths. Lots of agent based backups do this stuff.
How does an agent installed in a VM back up the VM as a whole? That doesn't make sense. You would still need to re-create a blank VM on the host, and after that, restore the VM data from backup as if it was a physical box.
The answer is they don't. You have to recreate the VM and then restore.
-
@obsolesce said in Agent and Agentless Backups:
@scottalanmiller said in Agent and Agentless Backups:
@obsolesce said in Agent and Agentless Backups:
Preference on whether or not you would rather simply restore a VM as a whole to a host of choice (or in the cloud), versus creating a new virtual machine and configuring it, then booting to a restore image so you can restore the agent-based backup... also a factor.
No, also not a factor. Both agent based and agentless do both of these options. That's why I didn't bring these things up. So many of the assumed benefits of agentless backups are myths. Lots of agent based backups do this stuff.
How does an agent installed in a VM back up the VM as a whole? That doesn't make sense. You would still need to re-create a blank VM on the host, and after that, restore the VM data from backup as if it was a physical box.
Okay, so there is a mix here. Agent CAN back up as a whole. That it can do. All that I know (there might be exceptions, and there definitely can be, the tech is there but I doubt anyone cares) handle restores by loading a restore ISO and it then restores the VM. Yes, you create a blank to install into, but that can be automated making it the same as agentless, because that's what agentless is doing, too.
-
Pretty sure Datto does this, but I've not used it. But I know that it does agents, and does instant recovery without recreating any VMs. They've been doing that a long time.
-
Ah, Datto has added agentless now, but it was doing this before adding that.
-
@scottalanmiller said in Agent and Agentless Backups:
@jaredbusch said in Agent and Agentless Backups:
@scottalanmiller said in Agent and Agentless Backups:
Agent based has to be written for each OS in use, but today the number of broadly deployed OSes is much smaller than the number of deployed hypervisors. For production servers Linux, Windows, Solaris, FreeBSD and AIX are essentially all that there are. With Linux and Windows representing nearly all deployed servers. For hypervisors, we have to consider not only the base products but resulting variants so the base products like KVM, Xen, Hyper-V, and VMware ESXi (plus type 2s perhaps), plus appliances like Scale, Nutanix, Simplivity, etc. and then cloud vendors like AWS, Vultr, Digital Ocean, Linode, etc. The range of needed support is far bigger and no vendor has broadly tackled this market.
Rose colored glasses in action if I ever saw it.
In what way? Very realistic.
You are painting agents in a magic light to suit your argument.
You toss out "Linux" under the agent based strength like it is a thing when it most certainly is not. Let's look at Veeam. Their agent works on "Windows" server and desktop versions. And the "Linux" agent works on deb and rpm based systems. That is a far cry from your magic everything. Also we know for a fact that 6 months ago it did not work on current Fedora systems.
Then Unitrends has an entire breakdown for all the various ways you have to setup the agent to work
-
When it comes to the agentless argument you then throw out cloud providers mixing them in with hypervisors solutions when that is an entirely different segment.
There are Type 1 solutions and the HCI solutions and then the cloud solutions.
Cloud solutions should leverage the cloud providers infrastructure. Most of them have an API of some sort to let you handle backing up your services if you need full backups. Moving things to places like this though should generally move to stateless control and only backing up of the data separately, etc.
HCI solutions have their own backup backed in also. Scale's solution work nice from what I have witnessed.
Type 2 should never be considered.
