imageWe've all been there. A system starts out as some form of development or test platform. The application administrator tells us that they will let us know when it is production and would need to be backed up. Then the system mysteriously graduates silently into production. And then, of course, a failure occurs and the system is not backed up. As a system administrator, this would drive me crazy, especially in a realm that limited the number of backup agents I could install on systems. Virtualization, and more specifically, Veeam Backup & Replication, can help eliminate this problem! There are a lot of strategies for designing backup jobs and for making sure that VM backup is uncomplicated (see the recorded version of my webinar from last year titled: 5 Key Ways to Protect Multiple VMs). One of the tricks I like is to backup at the vSphere datastore level. This backup can also be done with other vSphere constructs, such as a folder, host, resource pool, vApp, cluster, datacenter, etc. VMs are then inventoried on the datastore for the backup, rather than by adding specific VMs to a job. This option is shown in the Veeam Backup & Replication wizard in the figure below: image This will, in turn, backup each VM that is inventoried on the datastore. If you have a job for each datastore, which is what I do in the SSA Lab, each VM that is inventoried on the datastores will be backed up when the job runs. Using the datastore as a container is an excellent way to back up VMs so that there are no omissions in the data protection strategy. The real benefit with doing backups by datastores (or folders) is that the net-new virtual machines are automatically included in the job as the datastore is inventoried. In this fashion, when that VM silently graduates into a production without proper notice; it is automatically backed up. Here are a few tips on designing jobs this way:

  • Keep like operating systems on a datastore (or in a folder) to increase Veeam deduplication
  • Self-document datastores (or folders) to include a nomenclature that states whether or not that container is backed up
  • Designate a datastore (or folder) for templates and CD-ROM .ISO files and back that up as well; but likely on a less aggressive schedule
  • Configure a job with multiple datastores that are sourced from the same SAN or NAS device

There are endless ways to arrange backup jobs with Veeam Backup & Replication. Leveraging the container aspect of these vSphere constructs will help you solve the problem of having VMs that are not being backed up (or replicated), but that need to be protected. What tricks have you leveraged to ensure that everything is backed up? Share your comments below.

GD Star Rating
VM backups: Forget me not!, 4.8 out of 5 based on 4 ratings

View posts related to category:

All Veeam Products Top List
Technology Bloggers on Air
  • Pete

    Using this method, how do you avoid backing the same VM multiple times when that VM spans more than one datastore? Or if that VM has an ISO mounted from another datastore?

  • Martin

    @Pete good question

  • Rick Vanover

    Hi guys – sorry for missing this reply. If the VM is inventoried on each datastore, it would be backed up twice. I’d use an exclusion for the (presumably) rare case of a VM residing on two datastores OR have it backed up twice.

  • George@Backup solutions

    It would be important also that each datastore is unique in the manner it is constructed to avoid any multiplicity of minor problems. Very helpful article

  • Pingback: The Data Center Journal Customers Improving VM Recovery with ExaGrid and Veeam Joint Solution()