Hello Veeam team and Veeam gurus,
As a MSP with hundreds of VBRs on field we must rely on some tools to alert us if there are issues with backups.
Until this moment we didn't find a solution for a critical issue - Backup Copy jobs creating way more restore points than job retention.
The tool reporting job status (Backup Radar) will never report this.
We found even chains with 200 restore points instead of 30.
While this doesn't happen so often it's still something that creates major problems like clients being billed for more data or even exceeding quota.
If anybody found a solution to create such an alert (restore points exceeded) I'm willing to try it.
Thanks,
-
- Service Provider
- Posts: 19
- Liked: 5 times
- Joined: Mar 30, 2015 2:51 pm
- Full Name: Constantin
- Contact:
-
- Product Manager
- Posts: 20734
- Liked: 2402 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Feature request - restore points count
Based on the brief description, the situation seems a bit odd. Do you happen to have a screenshot or a record of the short and long-term retention settings for the problematic backup copy jobs and for the modes they were running in (periodic or immediate)?
Thanks!
Thanks!
-
- Service Provider
- Posts: 19
- Liked: 5 times
- Joined: Mar 30, 2015 2:51 pm
- Full Name: Constantin
- Contact:
Re: Feature request - restore points count
Hi Vladimir,
Your message says that this is unexpected while for me/us is a common issue probably because of the high number of VBRs deployed.
That's why I am looking for a solution.
As you are aware the only best place to discover the number of existing restore points is from Backups/Cloud and then expanding each job.
Anyway I have this Backup Copy job, periodic with 30 restore points (not days) no synthetic fulls or GFS configured.
When we discovered it all 5 VMs had 113 restore points.
Properties were showing a full somewhere in September and than daily incrementals, not any incomplete - just a clear chain of 113 restore points
The job was disabled and not deleted so I can show it in a remote session.
During time we had some Veeam tickets but nothing preventing this happening somewhere else.
Thanks,
Your message says that this is unexpected while for me/us is a common issue probably because of the high number of VBRs deployed.
That's why I am looking for a solution.
As you are aware the only best place to discover the number of existing restore points is from Backups/Cloud and then expanding each job.
Anyway I have this Backup Copy job, periodic with 30 restore points (not days) no synthetic fulls or GFS configured.
When we discovered it all 5 VMs had 113 restore points.
Properties were showing a full somewhere in September and than daily incrementals, not any incomplete - just a clear chain of 113 restore points
The job was disabled and not deleted so I can show it in a remote session.
During time we had some Veeam tickets but nothing preventing this happening somewhere else.
Thanks,
-
- Product Manager
- Posts: 20734
- Liked: 2402 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Feature request - restore points count
Overall, there's no better place than the UI to determine the number of restore points. I think the process can be automated using PowerShell or Veeam ONE (if you have it installed).
However, I still feel that we might be addressing the problem from the wrong angle. The root cause is that the backup copy job is somehow not cleaning up restore points according to the specified retention period, and that's the issue that needs to be investigated first.
If you still have a problematic job, I would recommend contacting our support team, collecting debug logs, and allowing the engineers to get to the bottom of it — because the product is clearly behaving unexpectedly.
Thanks!
However, I still feel that we might be addressing the problem from the wrong angle. The root cause is that the backup copy job is somehow not cleaning up restore points according to the specified retention period, and that's the issue that needs to be investigated first.
If you still have a problematic job, I would recommend contacting our support team, collecting debug logs, and allowing the engineers to get to the bottom of it — because the product is clearly behaving unexpectedly.
Thanks!
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 12 guests