Comprehensive data protection for all workloads
Post Reply
TechnoChimp
Lurker
Posts: 1
Liked: never
Joined: Apr 08, 2013 2:57 pm
Full Name: Tommy Grissom
Contact:

Backup Jobs - Small vs Large

Post by TechnoChimp »

We'll soon be replacing our backup repository to a new device, and while we're doing this I'd like to look at how we might be able to optimize our backup jobs.

Prior to parallel VM processing there was obviously a need to split up large amounts of VMs into smaller grouping to allow more proxies to chunk away at the data. Now with parallel processing, this doen't seem to be an issue anymore.

Are there any techical issues with having 1 job with 100 VMs as opposed to 5 jobs with 20 VMs?

Are there any scalability limitations to having large amounts of VMs in a single job?

Should a single 100 VM job take about as long as 5 jobs with 20 VMs each?
Gostev
Chief Product Officer
Posts: 31455
Liked: 6646 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Jobs - Small vs Large

Post by Gostev »

In version 7.0 or later, there are no known scalability limitations. Also, with parallel processing enabled, a single large job will take the same amount of time to complete as multiple smaller jobs.
yizhar
Service Provider
Posts: 181
Liked: 48 times
Joined: Sep 03, 2012 5:28 am
Full Name: Yizhar Hurwitz
Contact:

Re: Backup Jobs - Small vs Large

Post by yizhar »

Hi.

I would prefer to keep the 5*20 setup vs 1*100.

The reasons are other factors regardless of parallel processing, such as size of VBK files.
It's difficult to explain the reasons but I would say that it is similar to design of Exchange server -
If you have 1000 mailboxes with total of 1000gb, you would probably separate them to about 4 databases.
Going back to Veeam, you can look at the job and corresponding VBK as a kind of database, and having 5 smaller VBK vs 1 large one is better and *safer* for some actions, such as running synthetic full.
Also - if/when a need arises, you have more granular control of job execution - for example you plan to install service pack on some server, and wish to run backup on them (only). It is easier if you don't need to run the 100 VMs job.
Also if you wish to add a second repository in the future and put some jobs on it, having several jobs makes it easier.

Of course - don't go to the other side and don't create 100 jobs...

There are other reasons for not having all VMs in single job.

Yizhar
Gostev
Chief Product Officer
Posts: 31455
Liked: 6646 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Backup Jobs - Small vs Large

Post by Gostev » 1 person likes this post

...like backup file portability aspect, for example. 20 TB files are kind of hard to move around, when such need arises for whatever reason ;)
Post Reply

Who is online

Users browsing this forum: Ivan239 and 194 guests