Is auto VM-protection a good idea?

VMware snapshot backups rock. They are fast, easy and frankly quite popular.  The ability of a data protection product to leverage changed block tracking is proof positive of the power of the hypervisor.

One topic we frequently debate at Actifio is whether you should auto-protect every VM in the environment.  I got thinking about this again after watching this recent EMC video in which they declared that Avamar would offer auto-protection as a feature (they also declared that “Backup is broken” – which is not really good news for everyone who has bought their backup products).

Auto-detecting new VMs as they get created is easy, but having found them, should we automatically start protecting them?   The whole motivation to auto-protect is simple: The fear of unprotected systems….  the fear that something important will be missed.

It happens…. so it is a genuine fear.

But is auto-protection the solution?   Or should we be thinking somewhat smarter? There are three considerations that the system administrator needs to be aware of if you auto-protect every VM the moment it gets created:

  1. You will start consuming Disk, Network, ESX Server CPU resources immediately.  This is not in itself a sin:   after all if you were going to protect that VM anyway, you might as well start straight away.  But every shop, regardless of size, has VMs that do NOT need to protected.  They are either transitory or unimportant or duplicate.  Why are we wasting resources on them?   I did a quick survey of some of my clients and found that all of them had VMs they did not want to protect, or need to protect.
  2. You will place a default level of protection on that VM, regardless of what level of protection that VM needs or deserves. If you are scanning through your VM list and spot that every VM is protected, you will now get a false sense of security.  But what if these recently created automatically protected VMs deserve a far higher protection level than they get from your default protection level?  You may say: “That’s fine, I will pick this up on audit”, but wasn’t the whole point of auto-protection that your admins are probably too busy to audit?
  3. Some VMs actually cannot be protected by snapshot based backups.  For instance Cisco Call Center systems or VMs running MSCS (since they are using bus mastering) or VMs where the VMDK size is greater than 1.9TB (since snapshots don’t work) or VMs with pRDMs. Now this list sounds scary, but in reality these are exceptions, not norms. But the whole issue here is that automatically protecting these guys will just cause errors you don’t want (and in case you are wondering, Actifio has other smart ways of protecting that VM data).

So what is the better solution?   I think that the process of provisioning should include a protection decision at that point, with the relevant Service Level being set during the process.  Automation or provisioning tools should be setup to achieve this.   I would love to hear your opinions on this.

Equally, particularly if you studied sociology, I would love to hear your opinion of that EMC video.

2013-08-08_19-26-50

I found their choice of what looks like a battered Bridge from BattleStar Galactica, with badly concealed Apple Logos (check out the Macbook on the left) flanked by scary Borg Women blasting me with their eyes, was quite bizarre.   Maybe it’s just me?

About Anthony Vandewerdt

I am an IT Professional who lives and works in Melbourne Australia. This blog is totally my own work. It does not represent the views of any corporation. Constructive and useful comments are very very welcome.
This entry was posted in Actifio, vmware and tagged , , , , , . Bookmark the permalink.

4 Responses to Is auto VM-protection a good idea?

  1. Tas says:

    A native featureset of vSphere 5 virtual machine objects that often gets missed is the custom attribute flags that can be set easily and automatically by any orchestration engine with the right API call. This then allows extending a level of meta-data classification to the virtual machine fleet that is being auto-provisioned by the orchestration engine. A good backup solution should be able to leverage this meta data easily to allow for smart backup and data protection policies to be enabled as required by the orchestrated SLA.

  2. Pingback: Is auto VM-protection a good idea? | Storage CH Blog

  3. Sean Lee says:

    Hi Anthony
    I think in many cases it’s an extension of the same mentality that caused (causes?) the VM sprawl. It’s “easier” to backup all VMs just as it is easier to have 2 SQL Server VMs than two SQL Server instances running on the same physical box (it is easier, but up to a point).
    Once a limit (budget, storage space, network resources, backup window, etc.) is hit, some folks are bound to be disappointed as the resources will have to be prioritized… No technology can provide the equivalent of unlimited IT resources, so IMHO prioritizing – before the fact – is the way to go.
    Regards
    Sean

Leave a comment