Some VMs were not processed during the copy interval

[Daniel2]

Hi there,

I have a backup job that runs daily.
I have a backup COPY job job for it with an interval of 2 days.
The backup job contains 333 VMs and was completely successful.
The backup COPY job contains 333 VMs and was completely successful.

I still see the message "Some VMs were not processed during the copy interval".




Two questions:

1. How can it be that some VMs were not processed when every single of the 333 VMs was successful? The COPY job was even waiting for 24 hours for its next interval.
2. Where do I see WHAT VMs in PARTICULAR were not processed???

[PetrM]

Hi Daniel,

1. Most likely there were no "new" restore points created for some VMs by primary backup job, backup copy was waiting for these restore points, have not found such points and sync interval is completed with the message above. The "new" restore point is identified by this selection rule.

2. I'd check html-report of backup copy job: those VMs which have 0 Mb transferred are most likely VMs you're looking for.

Thanks!

[Daniel2]

Hi Petr,

yes, we have some VMs that are turned off (no changes on the block level). I can see them in the HTML report with "0,0 B". It would make sense that this VM is not copied because the copy target already has the most up2date backup file.

I find the info message misleading, though. Wouldn't it be better if it said something like: "Some VMs were not processed during the interval because the restore point in the copy target is already up-to-date?"

Cheers

[PetrM]

I think this is the interesting idea.
On the other hand, there are many different reasons why VM can not be processed during the interval and different VMs within the single job
can have specific reasons. If we write such reason for every VM, session statistics will contain too many messages and will become uncomfortable to use.

The actual message reflects the final result only: VM is not processed during the interval.
If we needed to get info about reasons, we'd examine statistics of the individual task, html-report etc.

Anyway, thanks for the feedback!

Thanks!

[Daniel2]

> The actual message reflects the final result only: VM is not processed during the interval.
> If we needed to get info about reasons, we'd examine statistics of the individual task, html-report etc.

That is understandable. But this requires quite a lot of knowledge about the specific cases where this message may be displayed. And it's still guess-work. Even you were uncertain if it's really those VMs which have 0 MBs transferred.

> Those VMs which have 0 Mb transferred are most likely VMs you're looking for.

How about adding the information and reason about skipped VMs in the backup report sent by mail? Since the VM status is successful, you could add the information and reason that a VM has been skipped into the detail column.

[PetrM]

Hi Daniel,

We will consider this idea and implement changes as long as we have enough similar requests.

Thanks!

[Daniel2]

I can very much imagine that this is something that would be helpful, but many people just not taking in the time and work to let you know about it.

Please do not consider making changes only based on the amount of similar request, but think if such a change would be helpful without having a negative impact on others. Which I strongly believe this is.

[techcure]

I agree more details are needed. I just came across this post after a failed job. I clicked sync now to make sure everything was ok but was greeted with processing finished with warning messages. Some restore points were not processed. This sounds like a huge problem but from what I'm reading hear it just means that there was nothing to process because everything is already up to date. Very misleading and needs to be corrected

[PetrM]

Hi Tyler,

Thanks for the feedback! What kind of information would you like to see in your case?
Some specific example would be fine.

Thanks!

[spiritie]

Hi PetrM

I could maybe add something to this, experiencing the something similar in our environment, which often leads be to manually checking if the backup copy data actually has been created.
As other states the behavior of these jobs are very misleading

Every morning I'll have a glance of my jobs in the VBR console and everything non success will of course catch my eye.
Using the backup copy with intimidate function with "Include database transaction log backups..." gives us results all over the place, and this status seems to be also be marked as a warning
if just any given SQL transaction log backup from the source source job haven't transferfed any data (could simply be because there is no SQL transaction on a particular SQL server at the time)

I think the status of these messages should simply just reflect the actual intent of the backup copy job, which is to make a copy of my backup job,
if this has already been done it should be shown and successful and not throw a warning just because it already has done what it supposed to do.

This "last result" message in the UI can be triggered from a success to a warning by simply running the job by pressing the "sync" button and a warning email will be send with
"0 B transferred at 0 KB/s Some restore points were not processed".

Regards.

[Dima P.]

Hello spiritie,

Thank you for the detailed feedback. Checking this behavior with our QA team, stay tuned. Cheers!

[Dima P.]

spiritie,

Can you please raise a support case and share the case ID with me: QA folks asked to share the debug logs with them. Thank you in advance!

[spiritie]

Hi Dima
I've created an case: #04217629

Here you can see the problem I was describing earlier, where the backup copy status is now warning, simply because no data was copied for some of the SQL VM's transaction log backups. I really hope this is something you can change with a upcomming patch

Status in console for the overview:


Job status:


Also an email is send every time this happens, I'm close to disabling warnings for these types of jobs, until this behavior can be changed

[Dima P.]

Thanks for the details and the case. Investigating with QA folks!

[spiritie]

Hi Dima P

Any news on this subject, are you planning on changing the behavior in future versions of Veeam?

Regards.

[foggy]

Hi Gert, looking at the case notes, this comes down to some unnecessary file locks and I can see that we attempted to address the issue in v10a update, however, you're still seeing the unwanted behavior, right? Please continue looking into this with the help of our engineers.