Few people would disagree with the statement that the best way to backup virtual machines is some type of agentless method. And yet, years after this practice became common we still find some people putting backup agents in their VM. Why would that be?
First, let’s take a look at the reasons that we wanted to stop using backup agents in our VM’s in the first place. The biggest reason was the way traditional backup software worked. It created a significant I/O load on the VM being backed up. This is because traditional backup software performs occasional full backups and “full file” incremental backups. When a single byte changes in a file, it changes that file’s modification time (in Linux) or archive bit (in Windows), which causes the entire file to be backed up. Occasionally backing up an entire server and daily backing up entire changed files has always had an undue impact on the servers that were being backed up, the networks the backups used, and the backup devices they were sent to. Replace a physical server with a VM that is sharing an I/O infrastructure with dozens of other VMs and you have a real problem. There simply isn’t enough I/O bandwidth in the shared infrastructure to complete traditional backups.
The other reason people wanted to move away from backup agents in their VMs was the act of managing and updating those agents. Installing and maintaining a single agent in a VMware or Hyper-V server requires significantly less management than doing so in dozens of VMs. VMware and Microsoft created agentless backup for VM’s to solve these challenges. However, there are still situations where a backup agent in a VM might be necessary.
One such situation is the backup of an application that is not supported by the agentless backup option. This is most common in Linux VMs. Most Windows applications are supported by Volume Shadow Services (VSS) that can automatically put an application in the appropriate mode prior to taking a snapshot and backup. Linux has no such process, so users might not be able to perform a backup of an application running inside a VM without putting an agent in that VM.
Another reason to run an agent inside a VM is to facilitate restores. The agentless backup options of VMware and Hyper-V focus only on the backup method. They offer a way to backup a consistent image of the virtual machine. What they did not create was a mechanism for putting individual files into a virtual machine in order to facilitate restores. The only way this is possible with most backup software packages is to place an agent in the VM.
The good news is that many backup agents no longer do the things that caused them to be banished from VMs in the first place. Specifically, many backup agents have gone to a block level incremental forever system that places a significantly lower I/O burden on the VM than traditional backup software. Some backup software products also automated the installation and update of their agents, removing this objection to them as well.
StorageSwiss Take
If your backup agent no longer performs full backups and full file incremental backups, and it can update itself, the objections to backup agents in VMs disappear. That means the choice to put an agent in a VM is just that – a choice. You may choose to do so in order to increase restore capabilities, or you may do so in order to support an application not supported by VSS. The good news is that doing so is not the incredibly bad idea that it was a few years ago.
Sponsored by Commvault
W. Curtis Preston (aka Mr. Backup) is an expert in backup & recovery systems; a space he has been working in since 1993. He has written three books on the subject, Backup & Recovery, Using SANs and NAS, and Unix Backup & Recovery. Mr. Preston is a writer and has spoken at hundreds of seminars and conferences around the world. Preston’s mission is to arm today’s IT managers with truly unbiased information about today’s storage industry and its products.
StorageSwiss.com - The Home of Storage Switzerland 