How many jobs -- multiple VM or singles?

[averylarry]

Before going into some specifics, it just feels like a big risk to have a single point of failure for each backup job (and subsequently for a group of multiple VMs) if using 1 backup job for multiple VMs. I can see a lot of benefits (deduplication, compression, linear job processing/retries) but I'd like some feedback . . .

I spent 3 months or so testing Veeam, using temporary backup storage locations and moving things around a lot and just generally -- testing. Anyway -- I had corrupt/unusable backups happen several times to the point where I had to delete jobs and start over. This has made me -- concerned -- about setting up multiple VM's in 1 backup job.

I don't have a huge data center -- VMware essentials plus -- Veeam essentials plus -- 3 SANs, 3 ESXi hosts -- 15 VMs -- ~2Tb of data. I really don't have a ton of extra disk space for backups. Most of my servers are Windows and I believe that 1 or 2 jobs with multiple VMs would be recommended. However -- I have the following concerns:

1) Differing retention policies. I know -- different jobs or whatever. Consider this an enhancement request. Different VM's have different retention policies in the same backup job. (Also -- more traditional retention policies of days, weeks, months, quarters, years etc.)

2) Corrupt backup. If my backup gets corrupted (remember, it did multiple times during my testing) -- then first, I lose all backups for all the VMs in the job; and second, I have to start over with full backups of all the VMs, which can take a very long time. And please don't just tell me "this almost never happens". I have a backup job right now that isn't corrupt, but it fails when trying to transform previous full backup chains into rollbacks. Not that I've contacted tech support -- but the easy way to fix it is to start a new backup job and then delete that one when the retention is finished. Or perform a new full backup job to start over. I don't have enough disk space left to do that, however, for that VM.

3) I can anticipate times where "perform full backup job" would be useful. For instance, on my Exchange server, I just moved ~400Gb of data from one drive to another. Instead of a huge .VRB file that doesn't shrink, OR a huge .VIB file that takes a long time to be removed by retention; I could run a full backup to start the retention chain over. But I can't do that for just 1 VM in a multiple-VM job.

[Gostev]

And please don't just tell me "this almost never happens".

This is not really inviting to the discussion when you say something like "don't tell me this and that".

I will not say that but will say even more, this never happens unless there are issues with underlying backup storage. I saw this backing up remotely to some low-end or software NASes. And unless you find and resolve storage issue, your data will not be safe no matter of how you setup your job.

I have a backup job right now that isn't corrupt, but it fails when trying to transform previous full backup chains into rollbacks. Not that I've contacted tech support -- but the easy way to fix it is to start a new backup job and then delete that one when the retention is finished.

Well, this has nothing to deal with backup corruption, as you correctly pointed out the backup is still recoverable and its data is not corrupted. This was a bug with transform logic, and it is resolved in previous maintenance updates, that you probably just do not have installed because you have been testing something you have downloaded a few months ago.

Bottom line, of course it is totally up to you how to create the jobs, and you can go ahead with whatever you are most comfortable with. We give you the flexibility to do things one way or another. But if you are interested to learn how other customers are doing this - then I can tell you that virtually everyone groups VMs together, and it is common to have backup files of a few TB in size containing dozens/hundred VMs. You are right, your environment is quite small in comparison, we do have customers with hundreds, and even thousand of sockets licensed. With tens of thousands of VMs there, of course there is no option but to group the VMs into a very large jobs.