Feature Request - Roll backs

[Iain_Green]

Hi,

Would like to request a change or the option to change the roll back behaviour.

It is very frustrating when you have a backup that fails and the on the next run it performs a roll back before doing anything else.
The current setup causes us further failures as it can spend several hours (on some backups) of the backup window performing a roll back. Not leaving enough time to complete the actual backup.

An option we would like to see is the roll back taking place at the end of the failed backup (even if the window is closed). Windows are in place to stop backups impacting perform on production, however the roll back would have no impact and is just correcting the backup data. So by getting it to perform after the failure would mean that when the backup runs again the next night its ready to go straight away.

[Vitaliy S.]

Hi Iain,

Rollback is required before the actual job run for a few reasons:
1. Need to prepare backup files for incremental job pass
2. Need to prepare all the metadata not to corrupt the existing backup chain

Running this operation right after job failure might be a good idea, however what if you never run this job again, or just decide to run active full etc. I'm not saying that it is a can of worms, but this change can potentially impact all existing deployments/usage scenarios.

On a side note, can you please give us a bit more details on our job set up, so we could understand why they are failing that often and prevent you from running subsequent jobs within the defined backup window.

Thanks!

[Iain_Green]

Surely doing this at the end of the backup that fails would achieve the same result?
If the job was never run again after a failure a roll back would never take place currently, so the metedata has not been prepared.

Problem we have is that we have no way to judge how long a roll back will take. Most of the time its hours, and with some of our tight backup windows this becomes problematic.
There is no one job we have that it effects it's just something we have noted over time.

A Customer backup this week has brought it up again. I had a tight backup window of two SQL servers, which were disconnecting when snapshots were being taken by veeam. Usually this would take place at 3 am so the customer would work around it.
However after a job failure the snapshot times would move as it needed to perform roll backs and would not start the backup until several hours later. Causing the disconnects to move from 3 am to 5 and 6 am. Right when there reports were being generated.

In end I have manged to correct the issue by starting the backup early and "guessing" when the roll back will complete. Now it has completed successfully I can get back to the original schedule.

[Vitaliy S.]

Iain,

Surely doing this at the end of the backup that fails would achieve the same result?

Yes, absolutely it should be possible to do, I was just trying to say that this change might change the already established process for existing customers, which is highly undesirable.

Problem we have is that we have no way to judge how long a roll back will take. Most of the time its hours, and with some of our tight backup windows this becomes problematic.
There is no one job we have that it effects it's just something we have noted over time.

What's the usual reason for rollback? Why does the job fail frequently?

Thanks!