Using VEB in middle sized organizations

[rodo]

Hello,

We have some problems with VEB in middle sized organizations. I think it can be useful to write about it, because we have a scenario typical for middle sized paying customer
Generally we are happy with this product, it has big potential but need a lot of improvement for enterprise users. I also use VEB for home with no problems.

Description:
HQ:
Veeam Backup & Replication Enterprise
VMware vSpehere with 5 hosts (3 for servers VM, 2 for VDI)
One NAS on site
One NAS on remote site
Two physical servers

28 branch offices with local branch office server with VEB. Some of them are connected with HQ with slow 2Mbs line.

On these servers we want to backup to HQ only one directory with 2-20GB of data in case of total disaster of branch office. Changes are about 30-200MB/day, so is it not huge amount of data to backup. For backup target we choose Veeam Repository in our HQ on NAS.

Problem 1:
When VEB calculate digest and source directory has 20GB, it takes 7-8 hours on 2Mbs line. And it will eat a whole line. VEB calculate delta file against previous backup on the remote repository. We are able to plan backup in the night, but we would prefer to cut the backup time down. We would prefer to have the archive of backup copies on local server and then transfer it to remote Repository, so VEB will calculate the delta file against the local copy, not a remote backup.


Problem 2:
When we press cancel during calculating digest, we have to wait to end of this operation (sometimes several hours). We need to have a choice to cancel the operation in minutes, not hours.

Problem 3:
When the line fails and scheduled backup did not run, VEB begin the backup again. And we got to the problem no. 2. . We need more granularity on retry. We need a way to tell VEB not to run scheduled backup after missing one. Or we need to specify a backup window.

Problem 4:
For us is very important, that we have only one console to check backup jobs on daily basis. This is why we choose VEB. But there are a only few features, which we can control or see. It would be great to have a full control over VEB through console. Now we have to log on to 28 servers to make some changes on VEB.

Problem 5:
We need more granularity on backup schedule. Windows Task Scheduler is great example. In our case we do not need backup in weekends, because there are no changes to backup.


I understand that VEB is for free, but we have no problem to pay for some "enterprise" features or an enterprise version of VEB.

Thank you for reading this to the end.

[Vitaliy S.]

Hello Roderik,

Problem 1:
When VEB calculate digest and source directory has 20GB, it takes 7-8 hours on 2Mbs line. And it will eat a whole line. VEB calculate delta file against previous backup on the remote repository. We are able to plan backup in the night, but we would prefer to cut the backup time down. We would prefer to have the archive of backup copies on local server and then transfer it to remote Repository, so VEB will calculate the delta file against the local copy, not a remote backup.

What backup mode are you using with VEB? If you select to store backups locally, do you also see 7-8 hours process of digest calculations?

Problem 2:
When we press cancel during calculating digest, we have to wait to end of this operation (sometimes several hours). We need to have a choice to cancel the operation in minutes, not hours.

I believe this is done to prevent backup data from corruption, but thanks for the feedback.

Problem 3:
When the line fails and scheduled backup did not run, VEB begin the backup again. And we got to the problem no. 2. . We need more granularity on retry. We need a way to tell VEB not to run scheduled backup after missing one. Or we need to specify a backup window.

So having something similar to a backup window like we have in Veeam B&R would work for you?

Problem 4:
For us is very important, that we have only one console to check backup jobs on daily basis. This is why we choose VEB. But there are a only few features, which we can control or see. It would be great to have a full control over VEB through console. Now we have to log on to 28 servers to make some changes on VEB.

Yes, we've heard this feedback already, and in our short term future we are planning to release integration with LabTech.. Thanks for confirming that this central console is needed.

Problem 5:
We need more granularity on backup schedule. Windows Task Scheduler is great example. In our case we do not need backup in weekends, because there are no changes to backup.

Yep, there are existing topics with the same request > search.php?st=0&sk=t&sd=d&sr=posts&keywords=schedule&fid%5B%5D=33

Thank you!

[rodo]

Hello Vitaliy,

What backup mode are you using with VEB? If you select to store backups locally, do you also see 7-8 hours process of digest calculations?

We are using file level backup, because we need to backup only one folder for each branch office. Size of this folder is in range 2-20GB.
I just try to store backup locally, here are results:
First local backup (first backup is always full) takes 27 minutes.
Second local backup (this should be incremental) takes 6 minutes
Incremental backup to Veeam repository in HQ takes 8 hours. It seams, that VEB is calculating incremental backup against previous backup in repository in HQ over our slow 2Mbs line 8 hours.

So having something similar to a backup window like we have in Veeam B&R would work for you?

Or just switch "Do not retry missed scheduled backup"

Yes, we've heard this feedback already, and in our short term future we are planning to release integration with LabTech.. Thanks for confirming that this central console is needed.

We already have central console in Veeam B&R, but the options for Endpoint backup jobs are gray-out there:


Thank You!

[Dima P.]

Hello Roderik,

We have some problems with VEB in middle sized organizations. I think it can be useful to write about it, because we have a scenario typical for middle sized paying customer

And we are here to listen. Thanks for sharing your thoughts – it’s highly appreciated.

Veeam repository in HQ takes 8 hours.

What is the repository type? Any difference if you backup to the same repository but in endpoint’s job specify the shared folder destination?

So having something similar to a backup window like we have in Veeam B&R would work for you?

Or just switch "Do not retry missed scheduled backup"

You can use VBR’s global network throttling rules even now

We already have central console in Veeam B&R, but the options for Endpoint backup jobs are gray-out there

Since there is no tight control some options are indeed missing. May I ask what options you miss the most? Thanks!

[rodo]

Hello,

What is the repository type? Any difference if you backup to the same repository but in endpoint’s job specify the shared folder destination?

Windows Storage Server 2012R2 IBM System x3650 M4 BD with 10GBs NIC. I will try the shared folder destination.

Since there is no tight control some options are indeed missing. May I ask what options you miss the most? Thanks!

Run, cancel, configure backup
Disable scheduled backup
Show backup job Stats

[Dima P.]

Thanks, I will await for the results then!

[Vitaliy S.]

First local backup (first backup is always full) takes 27 minutes.
Second local backup (this should be incremental) takes 6 minutes
Incremental backup to Veeam repository in HQ takes 8 hours. It seams, that VEB is calculating incremental backup against previous backup in repository in HQ over our slow 2Mbs line 8 hours.

Yes, this could be the case. What about creating backup repository locally in every site to store Endpoint backups and then use backup copy jobs to transfer these files to HQ? What performance do you have for the backup copy jobs?

[lowlander]

We also experienced some waiting time when syncing backups via VPN.

When syncing 20 GB without changing anything the backup duration was about 12 minutes with a bandwidth of 1 MBps;
When we added a 3 GB of data and performed a backup, the duration was about 1 hour;

1) E.g. Total backup time = digest calculation + ( Delta vs Bandwidth )

What are expected values to calculate the digest calculation ?

Another question : Will this be the same for all three backup modes : Entire computer (recommended) / Volume level backup / File level backup (slower)

Feature request for in a future version:
- Creating multiple types of backup jobs that run based on type of network connection
A) Entire computer for on premise (LAN) access;
B) File level backup for remote workers (VPN) access (+WAN acceleration for improving bandwidth)

When end user is in the Main Office, entire will be backed up.
When end user is out of office, only important documents will be backed up via VPN.

[Vitaliy S.]

What are expected values to calculate the digest calculation ?

To the best of my knowledge it depends on the backup mode and the number of files/connection etc.

Another question : Will this be the same for all three backup modes : Entire computer (recommended) / Volume level backup / File level backup (slower)

It should be different.

Feature request for in a future version:
- Creating multiple types of backup jobs that run based on type of network connection
A) Entire computer for on premise (LAN) access;
B) File level backup for remote workers (VPN) access (+WAN acceleration for improving bandwidth)

When end user is in the Main Office, entire will be backed up.
When end user is out of office, only important documents will be backed up via VPN.

Thanks for the feedback, multiple jobs seems like indeed demeaned by Corporate IT.

[rodo]

Yes, this could be the case. What about creating backup repository locally in every site to store Endpoint backups and then use backup copy jobs to transfer these files to HQ? What performance do you have for the backup copy jobs?

Yes, with local backup repository it works great. Thank You! Case closed.

[Vitaliy S.]

And what are the performance rates? Just for my own records

[rodo]

Backup duration on branch office servers is typically 7-15 minutes.
Backup copy jobs from branch office servers to HQ is 4-9 minutes.

[Vitaliy S.]

Got it, thanks!