• EN
Question

Uploading backup to storage

S
Userlevel 1

Greeting,

I'm trying to put together a solution for saving backups to a remote location.

I created a batch procedure that installs Wireguard to the remote storage and transfers a complete backup using the Robocopy program. This solution turned out to be the best, regarding reliability and bandwidth utilization.

The problem is the following: I expected that the .vbk file changes only once during retention time when a synthetic full backup is created, so that Robocopy sends me only incremental files daily, however it seems that is not the case because every day I also receive a 200GB .vbk which is not acceptable since it is uploaded at a speed of 50 Mbit/sec. Have I misunderstood something or am I doing something wrong?

Please comment...

8 comments

MicoolPaul
Userlevel 7
Badge +20

Depends on your backup chain type whether it’s forward incremental, forever forward incremental, or reverse incremental.

 

Is this a Veeam Agent Backup or a Server Backup via Veeam Backup & Replication? If the latter then I suggest you use a backup copy job to perform the copy in a way that Veeam understands to provide assurances that your backup chain is usable in a recovery scenario.

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
S
Userlevel 1

greeting,

Thank you for your reply.

The question is about Veeam Agent Backup (it's about small users with one or two physical or virtual servers - the best things in life are mostly free :-)).

As for the usability of backup remotely saved by “robocopy”, it has been tested and works without problems. I didn't understand the remark related to the choice of backup type (forward incremental, forever forward incremental, or reverse incremental) because I didn't see where and how I could control it. If you have a more detailed explanation... I look forward to it...

Regards

MicoolPaul
Userlevel 7
Badge +20

Hi @Satman are you providing consultancy or support services to other companies? If so just be sure you’re not using the Free/Community Edition as that’s in violation of the licensing agreement with Veeam.

 

Glad to hear robocopy is working without problems for you, as long as you keep testing it 😁

Veeam Agent is slightly different to Veeam Backup & Replication in that regard, so you can ignore the comments around backup type, instead have a read of:

Retention Policy in Free and Workstation Editions - Veeam Agent for Microsoft Windows Guide

 

In summary:

When you start your backups for the first time, you get a VBK, then you’ll have VIBs created for each incremental point. Your backup job will be configured for X number of days retention, when an incremental point reaches that X number of days retention, the newer backups might require blocks that were backed up during the to-be-deleted retention point, so Veeam injects those blocks into the VBK, hence the VBK transformation you’re seeing here. So the behaviour you’re witnessing is by design.

I’d suggest deploying a VBR server to manage the agent jobs and then configuring the VBR server to perform a backup copy job, this way Veeam will process just that which has changed instead of copying a whole VBK again.

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
coolsport00
Userlevel 7
Badge +17

I will back Michael’s suggestion to implement Veeam Backup Server into the mix. Sure, it’ll add a little bit more complexity, but you will also have greater flexibility in configuring your Agent jobs, among other things.

And yes..your VBK will not be static perpetually..occasionally, based off your retention settings, it needs to get ‘transformed’ to meet your retention period configuration.

Shane Williford - Veeam VMCA/VMCE | Veeam Legend | VUG Leader | VCP-DCV | Twitter: @coolsport00
S
Userlevel 1

Hi @MicoolPaul ,

...O.K. let's repeat once more, have we agreed on the important things...

So, the .vbk is changed only once, at the end of the retention cycle, when a new synthetic full backup is created?

Am I right?

if i am:

The syntax "robocopy [source] [destination] /MIR" mirrors (as you know) the source to the destination in such a way that it copies from the source only if the file in the destination is different. It also deletes files in the destination that no longer exist in the source. Therefore, I expect .vnk to be copied only once in the retention period, and new .vibs every day.

However, robocopy on the .vbk file detects a change every day, and tries to copy it every day.

This is a problem for which I am looking for either a solution or an explanation that I misunderstood something

thank you

as for the license, I found the community version already installed when I first visited user (that's not allowed to be used or??) and I'm working with what I found...

MicoolPaul
Userlevel 7
Badge +20

Hi!

RE the community edition license: https://www.veeam.com/eula.html

Section 4:

”You may not use the Free and Community Edition Licenses to provide services to third parties (including support and consulting services for existing Free and Community Edition License installations) or to process third-party data.”

 

So you’ll need to sell the customer a license to be compliant with the Veeam EULA.

 

With that bit out the way, it’s per retention processing. So Everytime the backup job runs, once you’ve hit your retention, you have an inject/merge operation taking place, so it’s every backup cycle, not just a one off.

What you’re seeing is that the backup VIBs are one by one no longer part of the chain (at the source side) with the relevant blocks preserved in the VBK, as you’re mirroring, if the robocopy completes successfully you should find due to the /mir flag that the expired VIB is deleted, a new VIB is created, and the VBK gets updated.

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social
S
Userlevel 1

”You may not use the Free and Community Edition Licenses to provide services to third parties (including support and consulting services for existing Free and Community Edition License installations) or to process third-party data.”

I am not doing any of that!

User has it installed according with the policy… “  Free and Community Edition License products can be used in Your own production environment and only by You in accordance with the terms and conditions of this EULA and the Licensing Policy “

… I am just copying files from A to B…

 

thanks

MicoolPaul
Userlevel 7
Badge +20

Cool, I’m just making you aware if you weren’t and were falling accidentally foul of the EULA.

 

To bring it back to the copying files from A to B, the second half of my comment still stands. Veeam Agent will inject redundant retention points into the full backup file at the end of each job run. So the user will need to leverage a native backup copy function within VBR to allow Veeam to efficiently copy the data. This shouldn’t be a problem as there’s no extra licenses consumed for a backup copy.

Michael Paul - #VeeamLegend | #VeeamVanguard | Veeam Certified Architect | VMware vExpert | https://micoolpaul.com | Twitter: @MicoolPaul | Mastodon: @micoolpaul@masto.nu | Bluesky: @micoolpaul.bsky.social

Comment


Terms & Conditions