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.

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

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.

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.

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...

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.

”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

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.