Note: this post offers some graphics to clarify some of the concepts detailed in the last post.
I have discussed the two good ways of backing up VMware with current methods: 1) Avamar agent in each guest OS, and 2) Avamar backup of VCBs, preferably from a proxy server. Both offer significant storage savings (in terms of backup storage capacity) and both offer significant network savings--particularly important in the first case.
The first case is described in the following picture:
In this case we can see that there is a backup client (or agent) in each virtual system. Basically this means that we are treating the virtual system just like a physical system: every system gets a backup client, and all data to be backed up is examined by, and routed through, that system. In the case of VMware, as mentioned, this introduces a significant CPU and network load on each VM.
The second case looks like this:
In this case, rather than putting backup agents on the ESX server, we offload backup entirely. There is no direct backup load on the physical (ESX) server at all. The LUNs on which vmfs resides are on SAN storage, probably a Clariion, and these will be snapped, and then mounted to our proxy server. It is the proxy server that will do all the heavy lifting of the backup: looking at the .vmdk files, examining them for duplicate segments and deduplicating as necessary, and transmitting the data to the Avamar backup server (represented by "backup disk" in the diagram above).
But it turns out that the 2nd approach does have some limitations that may impair the ability to scale the environment: the biggest one of these is that the proxy server cannot access a vmfs (.vmdk file) at the same time that a ESX and the guest OS is accessing it (simple case of file locking conflicts). As a result, I need to make a copy of the .vmdk file, and mount that to my proxy server. And it turns out that I have to do that sequentially for each .vmdk resident on the ESX host, and that the whole thing needs to move over the SAN each time. (Which is better than moving it over an IP network, but still not ideal if I have 100s of TB of vmfs data.) So there is a load on the SAN, and a sequential series of (very short) interruptions to service on the ESX physical server.
So what are we going to do?
Simple. Integrate Replication Manager (RM) with ESX and Avamar.
What does this do?
Array level snapshots with zero downtime for vmfs. Which means virtually (ahem) instantaneous backup and recovery of the vmfs filesystem and every guest OS resident on it.
Further, we will do so with file-level consistency right down to the guest OS level. Even if you are using Exchange, SQL, or Oracle. That's right: guest-level consistent snaps of application servers.
In the picture above, we would see an RM server that would chat with both the physical server and the array to achieve array snaps with application consistency.
And of course you can recover the snaps from disk. If you want to keep them on primary storage, and for as long as you keep them. Because you might, as many people do, keep several snaps around (they don't take up much space) to recover to a recent point in time.
You can also make these snaps available to an Avamar backup client, and from there perform the usual Avamar wizardry and deduplicate the backups for longer term retention within the backup application. (Most customers I have encountered tend to keep snaps for a relatively short period of time--often no more than 3 days. A recovery from any time before that will come from the backup application).
With Replication Manager and Avamar I get:
- Instant backup
- Guest OS file-level consistent backups (even for major applications)
- Restore a single VM, an entire VMFS space, or at the guest file level
- Minimized backup storage capacity. Usually 90-180 days of backups can be stored in less space than the original source volume.
This is everything that VMware backup has been needing.
And with VMware, Avamar, and Replication Manager, you can scale from easy guest OS level backups to instant array based snapshots for backup with deduplication and no downtime and no impact to production.
This is very powerful stuff. And it is simply the best VMware backup choice available anywhere today.