Discussion: Need more flexibility when handling old chains

[cparker4486]

Hello,

I'd like to open a topic for discussion on how Veeam approaches old backup chains and the lack of flexibility given to the customer.

(I tried to make this short but it didn't work. )

I recently realized I had accumulated 85 restore points for a backup job that was slated to have only 32. How did my backup chain get so big without me noticing? Well, I'm a one man shop (limited time), backup jobs normally run without issue (I check 1-3 times per week on job results), and my backup target has plenty of storage available. So, basically, nothing came up on my radar to cause me to investigate further.

Because I hadn't checked in on the backup files themselves for a while, I did that recently and noticed the massive collection of restore points. 1 VBK + 84 VIBs.

I opened a ticket with support and they quickly pointed out that the problem was due to me having set the full backup to occur on Saturdays with the problem being that my job doesn't run on Saturdays. I strongly believe the job setup window should be "smarter" and warn about this kind of misalignment in job settings. Having said that, that's not what I want to discuss here.

Once the error was pointed out to me I also noticed that the job was in a mode that I had intended to change: from Incremental to Reverse incremental. I like the concept of Reverse incremental more and the performance hit is not a problem for me (backups complete well within my backup window and I'll be improving hardware here soon anyway.)

I fixed the issue with the full backup by moving that schedule to Friday. I also changed the backup job type but I now have an "old" chain of 85 restore points that will remain untouched until my "new" chain reaches 32 restore points. This is where the problem lies: I have clearly stated that I want 32 restore points but, by design, my settings will not be followed because Veeam takes an unsophisticated approach to protecting my data.

The reason this approach is unsophisticated is because it incorrectly assumes that all customers will always have enough storage capacity to accommodate such situations. If I am to run out of storage space I will be forced to destroy the old chain which is the opposite of protecting my data (something I believe Veeam strives very hard to do). Having to destroy an old and long chain is far worse than B&R being able to override the default behavior and rollup the old restore points on each job run as needed. This is a little like throwing the baby out with the bathwater.

To state clearly what I am saying, I propose that Veeam take a less rigid approach to protecting old chains and allow the customer, when needed, to give permission to B&R to rollup those old chains. I can see this being a good use of the PowerShell snapin.

Another improvement that could be made is for a job to be given a warning state and message alerting the user to a possible misalignment of schedules in a job when it exceeds the stated restore point count. "Hey, buddy. There might be a scheduling problem in your job because I'm not able to remove old restore points and you now have more than the stated restore points in this chain."

[cparker4486]

I don't like to bump my own posts but I think this is an important one. I'm going to add a tl;dr to make this easier to digest.

I believe Veeam needs to give its customers the option to override the default behavior when it comes to old backup chains if and when appropriate (see my original post). Specifically, we should be able to instruct B&R to rollup old chains so that our desired restore point count is respected.

[Gostev]

Hi, please remember to include support case ID when posting about any issues, as requested when you click New Topic. At a minimum, this saves us a lot time, as we no longer need to ask you many additional questions to find out all the required details about your deployment, as well as the behavior you are seeing.

Manual roll up of previous full backup chains is a good idea, I will take a note on this for future versions.

I opened a ticket with support and they quickly pointed out that the problem was due to me having set the full backup to occur on Saturdays with the problem being that my job doesn't run on Saturdays. I strongly believe the job setup window should be "smarter" and warn about this kind of misalignment in job settings. Having said that, that's not what I want to discuss here.

Now, this is something I would REALLY be interested to investigate. Because from what I remember, this was fixed long ago. The job should always run on the day when full backup is scheduled. Are you seeing this behavior in v8?

[cparker4486]

I Gostev,

Sorry for not including the case # and thanks for addressing this! The number is 01097087.

[foggy]

Chris, any chance the job in question is chained to some other job to start after it?

[cparker4486]

Yes. I have three jobs. They are all chained to run after the first one. I have two that are exhibiting this behavior and they are numbers 2 and 3 in the chain.

[foggy]

Then the reason of your issue is the fact that the job is actually started on the next day, not the one the full backup is scheduled at. This is one of the undesired consequences of jobs chaining, which we typically do not recommend to use.

[Gostev]

Yes, I still punish myself for adding this scheduling option... it is absolutely useless starting v6, and yet causes way too many various support issues

[cparker4486]

Then I will be sure to schedule each job manually. But having said that, I hope that Veeam still considers improving the intelligence of the job setup wizard. This kind of thing can be caught before it becomes a problem. It would save Veeam support time and it would certainly save your customers some grief and feelings of self-loathing.