"Initial copy did not complete" and missing backup copies

[Anguel]

Hi,

I think this is actually a problem reported many times and I think I know what is causing it, however I am fighting with it since many years and I have still not found a satisfying solution.
The warning "Initial copy did not complete, and will resume on the next copy interval" appears for backup copy jobs for Veeam Agent endpoints that do not perform backups for a longer time, e.g. notebooks that are used very rarely. Let's say I create a backup copy job scheduled to run every day but the last backup from a notebook is a couple of weeks old. In this case it looks like Veeam will simply not copy this old backup to the copy job repository but instead completely skip it. This is not what I expect from a decent backup program, because in case my primary repository fails, I will have no copy of this endpoint at all.
If I remember correctly there are some workarounds like setting the interval to a long time and then setting it back to 1 day, or manually starting up those rarely used notebooks and performing a new backup. However, it looks like I sometimes forget it and notice later that important backups are actually missing in the secondary repository.
So I still wonder why Veeam does not simply copy the last available backup it finds in the primary repository if there is no backup at all for that endpoint in the secondary repository. I think this would avoid many bad surprises...

Thanks,
Anguel

[wishr]

Hi Anguel,

Have you ever considered using Backup Copy in the immediate copy mode introduced in v10 which copies the backups every time they appear on the repository?

Thanks

[Mildur]

Hi wishr

If he uses Notebooks, i think immediate mode is not possible today. Only „backup agent managed by backup server“ can be copied by immediate mode.

Veeam Agent for windows workstation operates in the „managed by agent“ mode.

[Anguel]

Indeed, this is Agent Free running on the notebooks. Also, will "immediate mode" pick up already existing backups?

[Mildur]

The immediate mode chooses always the last created restore point from the source job. It doesn‘t look for RPs in a specific timeframe (like the interval in periodic copy). If a new restore point is created, it will be copied immediately after the source job is done.

Immediate mode could help you with your issue, but you have to backup your notebooks with the server license edition of veeam agent for that. Veeam Community Edition could be a solution for your free agents (10 server agent are included).
That will create new sorts of issues, like scheduling the backup job. You will get failed notifications each time a notebook is not running.

A disclaimer:
Only use free or community products for your own company or homelab. We are not allowed to used it for offering services to third partys (customers)

[wishr]

The immediate mode indeed does not support standalone agent backups and backups created by backup policies managed by agent. Only agent jobs managed by backup server are supported.

Immediate copy processes backups as soon as they are created on the repository. Thus, once a managed agent job or a policy creates a backup file, it will be further processed by the copy job. In the case when you just created an immediate backup copy job, it will transfer the latest available backup.

Thanks

[Mildur]

Wishr, do I missing something? From your link:

Mind that for immediate copy mode, only Veeam Agent backups created by jobs managed by the backup server are supported.

He has notebooks to backup, which are most likely Windows Workstations. And the guide tells us, that workstations are processed by „managed by Veeam Agent“ Mode.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

With this option selected, the backup job will be managed by Veeam Agent installed on the protected computer — you do not need to select the job mode.

Is there some missunderstanding from my site or is there an issue with guide?

[wishr]

Yes, I apologize, you are right. Just checked it myself. I'll modify my post above to not confuse future readers.

Regarding the initial issue with periodic mode, let me check with our QC team if that is expected behavior.

[Anguel]

Thanks, I also see another thing in v11:
One PC that backs up regularly to VBR also shows as warning: "Initial copy did not complete, and will resume on the next copy interval"
But turns out that here the problem is very different as the detailed log reveals: "Source backup file has different block size. Expected block size: 1024"
Not sure if this warning message is the "correct" one in this case.

[Mildur]

Thanks wishr.

But turns out that here the problem is very different as the detailed log reveals: "Source backup file has different block size. Expected block size: 1024"
Not sure if this warning message is the "correct" one in this case.

Looks like you are mixing source jobs with different block size in the copy job.
Please check the data compression setting.
Should be „Local Target“ on each source Job from the backup copy job.

[Anguel]

Thanks Mildur, I already fixed the problem, just wanted to point out that IMHO the warning message is a little misleading in this case.

[wishr]

Gentlemen,

I had a talk with our QC team. Below are the outcomes.

The behavior of the periodic copy described in the initial post is expected. The "Copy every" setting not only controls the time when the job starts its activity but also controls the backup selection logic. Basically, this setting is somewhat similar to an RPO target. E.g. if you set its value to one day, the job will run once a day and will only select the latest backup from all the backups created during the last 24 hours. If a backup falls out of this period, it will not be copied. The workaround for this situation is to increase the "copy every" interval so that the latest backups of all workloads will fall under it. While we cannot change this behavior in the current version, we are planning to add alternative enhancements in future VBR versions which will also simplify this particular usage scenario with standalone Agents, so stay tuned for updates.

Regarding the warning message text, it's a generic error when there are block size inconsistencies that may appear in several scenarios. To dive deeper into your particular situation, we need the product logs to be supplied through our support team so that we could understand what scenario is that.

Thanks

[Anguel]

Many thanks wishr,

enhancing #1 sounds great, I really hope that they will add some additional option, because this "specific" behavior is known since many versions but nothing changed until now. I bet that many people simply don't know that they miss backup copies because of this "feature"

Regading #2: The situation is clear here, one PC just had "LAN Target" instead of "Local Target" (as all other PCs in the copy job), so it failed. I only wanted to point out that such a generic warning confused me and did not point me right to the real cause.

[wishr]

Thanks for commenting.

Regarding #2 - we'll see what can be improved there. By the way, here is a guide that describes what block size each option implies.