Tape backup was not created for 17/08/2019: there are no new restore points between

[dcampregher]

Hello!

In many environments i see the following warning in the GFS tape jobs:

Tape backup was not created for 17/08/2019: there are no new restore points between 09/07/2019 and 17/08/2019: JOBNAME."

I don't understand the reason of the message because the backup job included in the GFP tape job was running every day in the spcified time.

So what is the reason of the message ?

[Dima P.]

Hello Diogo,

This message usually indicates that there are no restore points for GFS tape job to be used for synthetic full creation. If you can confirm that some restore points were created by the disk job and should be processed by tape job, kindly, raise a support case and share the case ID with us. Thanks!

[dcampregher]

Hi Dima! Thanks for your answer. The case ID is: 03741514 and logs are i nthe FTP to the support engineer to check.

And yes, the source backup jobs run every day so between the the days in the message there are many restore points for all the VMs.

[adept1]

We've started using GFS in 9.5 update 4b a few months ago and most of our jobs are working fine.

However, we do have a few stubborn jobs that always come up with this error. Example:
Tape backup was not created for 10/4/2020: there are no new restore points between 3/23/2019 and 10/4/2020
Tape backup was not created for 10/24/2020: there are no new restore points between 3/23/2019 and 10/24/2020

However, the message is wrong. We do have restore points. Our job that backs up to ExaGrid is working fine. Furthermore I don't even know why it's using this date of 3/23/2019 when we didn't even use GFS tape back then (we were using Veeam tape, but not GFS).

I've looked around the forums and tried the usual things. Disable and reenable the job, rescan the repository, etc. We do have a ticket open for it (04445197). Maybe someone has some suggestions.

Thanks!

[Natalia Lupacheva]

Hi @@adept1,

moved your post to the existing thread to keep the same issues together.
Thank you for providing case id, appreciate it.
I see you've already tried solutions from the forums, so let's wait for the suggestions from the Support team, they will be able to dig into the logs.

Thanks!

[knorman]

I have this same Issue with a new GFS -Tape configuration in 2022, was there a resolution to the Issue

[Dima P.]

Hello Kevin,

This issue was resolved 2 years ago and unfortunately we do not have much details left to share. Please raise a support case if you faced similar behavior and share the case ID with us. Thank you!

[carlos.garcia.seidor]

Hello,

I am encountering a problem with a recurring alert on the tape jobs I set up to GFS type pools. The problem is as follows:

Usually, I configure the backup based on a backup job, not a repository. In the first case, the backup runs every day. In the second, only from Monday to Friday (in both cases a synthetic full backup is launched on Friday or Saturday).

In both cases, the retention applied from the GFS pool is to retain daily, weekly, monthly and annual backups (at least 14d, 4s, 3m, and 5a). As I said, one of the jobs has backup to disk daily, and the other only on weekdays.

In both cases, we receive daily messages like the one below: "01/10/2022 22:00:11 :: Tape backup was not created for 24/09/2022: there are no new restore points between 03/09/2022 and 24/09/2022". In the case of this particular message, it is remarkable that it occurs in a Monday to Sunday backup strategy.

In the first case, I understood that the problem was that, although there were daily disk backups, I could not find GFS points and that is why I was sending alerts. I tried to remove the Daily retention from the GFS pool and put the daily backups in a Standard retention pool. With that, in addition, the jobs to tape from the GFS pool would be launched only on Saturdays. However, with this new configuration (only look for GFS on Saturday for weekly, monthly and yearly tape backups) this type of alert keeps appearing.

I am probably starting from a lot of misconceptions when configuring a job to tape for a GFS pool. I need your advice to be able to properly configure a job to tape for this type of pools, preferably including the daily backups (although it is not essential) and that does not return this type of alerts. The use of a GFS pool is essential in both projects as it is the cleanest way to manage GFS backups (standard pools work with a different philosophy).

I look forward to your comments.

Best regards

[HannesK]

Hello,
I merged your question to an existing thread with the same question. Did you already check with support (what is the Veeam support case number)?

Best regards,
Hannes

[heavy]

Hi all,

sorry for the rather abstract title. I was also sure there had been a topic on this at some point, but I could not find it using the search function.

I have quite a few clients that use "catch-all" job definitions - as in: source ist a VM folder, an entire host or cluster or a VM tag. The reason ist usually a "keep it simple"-approach so that new VMs do not explicitly need to be added to backup jos but rather automatically join.
When such a job is used as a source for a tape backup job, the following may happen:
- VM has some amount of successfull backups
- VM is removed from backup jobs scope (as in: deleted, moved, added as an exception...)
- next run of that tape job spits out the following warning "Tape backup was not created for (date) there are no new restore points between (date) and (date)"


While technically correct, this is rather confusing. The backup as whole was correctly written to tape - one or more restore points are missing, which may or may not be intentional.
My suggestions:
- add the name of the VM(s) affected to the message (if I researched correctly, this information is present in the text-style logs)
- add an option to make this message informational (not a warning)

I hope I did not miss anything although I'd be glad to read these options already exist,

Thanks,
Thomas

[HannesK]

Hello,
are you using GFS media pools? If yes, there are other threads around this topic and I would merge the threads later. Also if it's a GFS media pool, please open a support case to check what's the reason for that message.

Best regards,
Hannes

[heavy]

Hello Hannes,
yes, both source jobs and tape jobs are GFS. Feel free to merge, i wasn't able to find the right thread although i felt like remembering some thread about this topic existed at some point.

No need for a support ticket, I could easily find the affected VMs - just my client was (understandibly) confused by this warning.

Again: My idea would be be to add the name of the affected object to this warning - bonus points for adding an option to make this informational

Thanks and best regards,
Thomas

[HannesK]

Hello,
I merged the question to the existing thread.

We can only fix / improve it, when we see the log files. That's why I asked for the support case number

Best regards,
Hannes

[lukklin]

Hello,

any news on this?

I see this issue in multiple customer environments and also in our own.

The Setup is mostly identical:
Primary Backup Job is scoped by dynamic objects (i.e. folders or tags)
GFS-Tape Job is scoped by veeam repo

If a VM gets deleted on vSphere, after a short period of time this message appears in the job stats:

08.05.2023 08:00:26 :: Tape backup was not created for 4/30/2023: there are no new restore points between 11/17/2022 and 4/30/2023

Thanks & kind regards,
Lukas

[Dima P.]

Lukas,

Thank you for sharing! We will discuss with RnD folks how to correct this behavior for machines that are no longer present.

[Dynamic]

Hi there, any news on this?
We having the same issue on different installations.
Also this was discussed on the latest VMUG germany: https://community.veeam.com/vug-germany ... tween-4933

Thanks and best regards Markus

[HannesK]

Hello,
no news beyond what I shared in the user group. It's confirmed as bug, but no time estimation when it gets fixed.

Best regards,
Hannes