Backup Strategy Optimization

[PeteMartell]

Hi,

I recently tried to tidy up my backup structure which has been handed to me by my predecessor, changed a couple of things, rolled with it for a while. Basically we had one backup job for one virtual machine each.

While I was at it, I tried having all VMs backed up by a single job to streamline the process, make things simpler and maybe profit off of some task balancing.
Now while that was alright for the time being, I recently had to work on some applications on VMs which I wanted to backup an increment of beforehand. But since all of my VMs included in the job now have to be backed up I had to wait an hour and a half instead of a few minutes.
Also I implemented d2d2t and while at the time being it’s not a concern, in the future I might not want to archive my printer server or WSUS to tape anymore. But with just a single job for all VMs, I can’t choose (or did I miss it?).

So now I’m sitting here thinking about it again. Should I do two jobs, one for critical VMs that definitely go on tape and have to be archived as long as the storage space allows and one for less critical machines that two weeks’ worth of backup are plenty and tape is not necessary, leaving me with ever so inflexible increments, backup files and restore points – or should I go all the way and make an individual job for every VM again to achieve maximum flexibility? I honestly don’t see much cons to that, except for worse overview and more room for human error. But seeing as I can manage storage space, restore point keeping, d2d2t better and safe time on irregular but critical maintenance, I would like to do it this way again. But with like 28 jobs, do I let all the backup jobs run simultaneously and does Veeam still balance the workload in a good way or is a scheduled, consecutive structure better? The limit of concurrent tasks probably still applies?

As I'm new here I've read most of the FAQ and a couple of blog posts from Veeam before, but I'm interested in hearing advice on my situation

Kind regards

[csydas]

Hi there,

I think Quick Backup is an option you can consider to simplify the multi-VM jobs: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4

We don't use it too often as usually we're good to just do an extra run, but I believe it meets your need of a one-off increment for the jobs.

As for managing the tape backups, I think that's just your preference. My jobs are organized by our Application Clusters, so when I call back tapes, I know exactly what I need. Having several Backup Jobs makes the offloading to tape pretty convenient for us, but it's a matter of preference.

For me, that many jobs is mostly just a management annoyance. If you're relying on the inline dedupe, you also lose out there. For me it's just a headache.

[PeteMartell]

Hey csydas,

thanks for the guidance, I actually didn't even know about Quick Backup and have not tested it yet, but it looks like a solution to almost all of my problems.
That and your point of losing effectivity of dedupe will probably make me stay on one job for now and split that one into two as soon as I need more than two LTO5 tapes for a full backup of my whole cluster. Or maybe try and apply for funds for a replacement of my ten year old library sooner rater than later.

But I'm still interested, is Veeam capable of auto balancing the jobs similar to how it does with multiple VMs in one job? Would 28 jobs with the same starting time be similar to one job with 28 VMs in performance or take considerably longer, maybe even a shorter amount of time?

[foggy]

In the general case, parallel processing makes performance similar in both configurations. However, for example, in the case of backup from storage snapshot, a single job might perform faster due to processing multiple VMs from the same storage snapshot.

[ejenner]

Go with individual jobs. It's a pain to set up. But as long as you've got a sensible naming convention you can sort by columns in the Backup & Replication console to order your job definitions according to the view you want at the time. I've got 190 backup jobs defined and a similarly large number of copy jobs.

Shouldn't underestimate the benefits of granularity in the backup world. It solves so many problems.

Some of the ones you didn't mention are when you have to migrate your storage because you're replacing or upgrading back-end disk. Trying to do the whole thing as a lump is quite impractical. The other angle is failure. If you have failures of backups for some reason external to Veeam (and out of your control) it is much better that the failure is isolated to just a small number of jobs which you can recover quickly from.

I get that there is admin overhead, but it is all in the configuration rather than the management. It takes me seconds to check the success of my jobs each morning.

[GregorS]

Put all VMs into a single backup job. Leverage per-vm backup files.

[Ne0x]

I think is better one vm = one job. Easy to find what is the problem when a backup fails

[Regnor]

I personally don't see a benefit there if you have one job per VM. Finding and solving problems for a single VM won't differ much in a single large job.

[PeteMartell]

Put all VMs into a single backup job. Leverage per-vm backup files.

You are trading deduplication for performance and granularity then, same as with individual jobs but less work to configure but less flexibility again when it comes to d2d2t for example.
Didn't know about this option yet, so thanks for the heads up. It's actually kind of funny how Veeam gives you so many ways to achieve almost the same result but with little trade-offs.

I still have not changed my one-job-setup as Quick Backup is sufficient for my needs for now.
In my relatively small scale scenario I don't need backups often, especially not unforeseen (knock on wood) so if my regular backup job was to fail and the whole increment is unusable, the last and next increment will serve me just fine and I would rarely get use out of a few VMs being saved, the dedupe is more important to me in that case.

But thanks for all the input, very much appreciated