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?
-
TechnoChimp
- Lurker
- Posts: 1
- Liked: never
- Joined: Apr 08, 2013 2:57 pm
- Full Name: Tommy Grissom
- Contact:
-
Gostev
- Chief Product Officer
- Posts: 31804
- Liked: 7298 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Backup Jobs - Small vs Large
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: 182
- Liked: 48 times
- Joined: Sep 03, 2012 5:28 am
- Full Name: Yizhar Hurwitz
- Contact:
Re: Backup Jobs - Small vs Large
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
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: 31804
- Liked: 7298 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Backup Jobs - Small vs Large
...like backup file portability aspect, for example. 20 TB files are kind of hard to move around, when such need arises for whatever reason 
Who is online
Users browsing this forum: Bing [Bot], dbeerts, Stabz and 161 guests