What happens if the repository reboots whilst backing up

[eduesterhaus]

The server that hosts my Veeam B&R installation, and my backup repository (iSCSI "local" disk) needs to be rebooted, but I have two endpoints that have been slowly doing their initial FULL backup up over a 3mbit/sec link for the past 60 hours.

They are half done, and I don't want the backup to fail and need to start over from the beginning.

Do I wait another 60 hours until it is finished, or will the backup resume/retry after a server reboot?

How will endpoint backup behave when the repository gets rebooted while an endpoint backup job is happening?

[JaxIsland7575]

The jobs would have to restart from the beginning. There is no logic in the application that would allow it to take half of the backup and resume the job. I believe that is what you are asking.

Cheers

[eduesterhaus]

Yep, that answers my question. I wasn't sure if it would just time out and give up immediately, or if there would be an incomplete full it would resume it the next time the job kicked off.

I'll just wait a few more days before rebooting the server that hosts the repository, since it sounds like an interruption would erase everything it's uploaded so far.

Thanks!

[JaxIsland7575]

Glad I could help!

Cheers!

[Vitaliy S.]

Thanks Ryan for chiming in.

@eduesterhaus, can you please tell us a bit more about your configuration? Do you have these endpoints installed in the remote site? What are you protecting with VEB?

[eduesterhaus]

We have about 18 file servers with 100-200GB of files that also do DHCP, printer sharing etc. for our remote locations (they are a mix of Dell T310s and T320s). Most of our remote locations that house these servers are very rural, and for several, a 3mbit/sec internet connection is the fastest we can get.

We currently do file-level backup using DFSR to get the files to a vm back to our main location, but we are now testing VEB on 4 of our endpoints so we can get backups that will let us do a bare-metal restore. The other 14 servers are going to make their way back to our main location for OS upgrades, so the initial backup is going to be much faster.

One thing is for sure - if we have to do any more fulls over the WAN, I'm just going to ship them an external HD and have them connect it to their server, then ship it back when the job finishes

[Vitaliy S.]

Given your usage scenario, have you considered sending backup files to local Veeam repository and then use backup copy jobs and WAN accelerators to send this data to HQ? In this case when the connection to the main repository (HQ site) fails, your job will be resumed due to WAN accelerator usage. Let me know if you need any other clarification.

[Dima P.]

if we have to do any more fulls over the WAN, I'm just going to ship them an external HD and have them connect it to their server, then ship it back when the job finishes

For Endpoint backups such approach is valid for local and network targets while backup to the VBR repository creates a new full anyway.

[eduesterhaus]

Given your usage scenario, have you considered sending backup files to local Veeam repository and then use backup copy jobs and WAN accelerators to send this data to HQ? In this case when the connection to the main repository (HQ site) fails, your job will be resumed due to WAN accelerator usage. Let me know if you need any other clarification.

I had not thought of using backup copy to get the backups back here. I'll actually have storage there soon to use as a local repository soon as part of another project.

Do I need to have a local backup proxy as well, or does VEB write directly to the repository?

Thanks!

For Endpoint backups such approach is valid for local and network targets while backup to the VBR repository creates a new full anyway.

Good to know! That saved me from making an unfortunate mistake.

[Vitaliy S.]

Do I need to have a local backup proxy as well, or does VEB write directly to the repository?

Proxy server is not required, VEB can write data directly to Veeam backup repository.

Please check out this thread with a similar question that should clarify other details > incremental backup