Feature request Tape jobs when using reverse inc logic

[moondew]

Feature request as a result of call 03231264

I have been working with support to sort out my D2D2T solution. 3 Fileserver jobs are being protected by the tape job and the D2D was set to reverse incremental. These 3 Fileservers used to be one big Fileserver which had grown too large.

Reverse Incremental worked when I had one large Fileserver, but with 3 smaller fileservers the solution runs into issues. Reverse incremental almost suited our design goals of having a point of time backup of the system, where any one tape could be used to restore the system from the day the tape job ran. Restores were not dependent on any other tapes and the job ran quickly as the tape job was committing a synthetic full which was already on the D2D locally attached storage. It was also as space efficient on the tape as it can be, as no incrementals are being stored. The reverse incremental runs every two hours and the design falls over here.

This is what happens:

The first backup job’s VBK gets committed to tape and during this time the reverse incremental job for that Fileserver is unable to run, as the VBK is locked. This is expected, the job will run once the VBK is no longer in use by the tape job.
Once the first VBK is committed to tape, the 2nd VBK from the 2nd Fileservers backup job is committed to tape, then finally the 3rd.
I had expected the tape job to end here, successfully, as 3 VBK’s, one for each Fileserver has been committed to tape. However, and this is what I wish to change, the tape job monitors and understands that while the tape job has been running, the other two VBK’s have been modified and thus the tape job insists on committing these new modified files to tape.
This loop will run on forever until I either disable the 3 reverse incremental jobs which run every 2 hours(thus stopping the VBK’s from changing) or I cancel the tape job.

I am sure that the above logic is needed elsewhere in the product, but what I would like is a tick-box on the tape job to stop it monitoring VBK’s which have changed during the tape backup if committed successfully to tape already. This would allow only one version of each VBK per backup job.

Presently I am testing forever forward with a synthetic backup map, but this seems to run slower than a reverse incremental being committed to tape. Perhaps this is because to create this map the storage must look at a larger number of restore points to build its synthetic on the fly.

[PTide]

Hi,

I would like to ask you if the Backup to Tape job is configured to run "As new backup file appears"?

Thanks

[moondew]

Good morning

No, its not setup to run as it appears. The 3 File servers are backing up to disk every 2 hours and then the tape drive commits the most recent version runs on a schedule, every weekday daily at 7PM

kind regards