VBR Backup Job Design

[gingerdazza]

Hi all,

interested to hear what backup job designs seem to be the way forward these days...? Fewer big jobs with dozens of VMs? Or SLA focussed jobs with dozens of VMs? Or lots of little jobs with service focussed small amounts of VMs? Or separate jobs for SQL and Sharepoint? etc. ?

[tyler.jurgens]

I prefer individual jobs per VMs. Only because you can get really granular with a single VM job, rather than larger jobs. If that's too daunting (too many VMs), then I go for grouping like VMs into like Jobs. Eg: AD servers may all have the same retention policy, AAP settings, etc, so group them together.

Its mostly a case of 'what do you want to manage?' rather than what the community in general uses. I've seen countless company's Veeam setups and I am telling you - no two setups are the same. Veeam is so powerful and so configurable, you can accomplish the same task multiple different ways.

Have an end goal in mind and configure toward that.

[gingerdazza]

Per VM would be too painful. Probably I'd likely setup as follows:

Prod - AD
Prod - SQL
Prod - Sharepoint
Prod - General
Non-Prod - SQL
Non-Prod - Sharepoint
Non-Prod - General

Something like this.

As you say, it's the outcome that drives the design to some degree.

[MarkBoothmaa]

For our clients i tend to go with creating jobs based on logical grouping like above.
It has the advantage then that usually if a new member of the team joins restore requests should be quite easily identified based on job grouping.

This approach also aids when looking at a recovery plan in the event having having to recover from something catastrophic.