I recently read this blog from Rick Vanover from Veeam. I thought that rather than try to summarize this I would just share it. Very pertinent information for many organizations. I hope that you find this information useful!
We’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:
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
Jon Eyberg, PEI
