Feature request: Running Copy/tape job retention hold

[kkuszek]

When my monthly full tape archive is running it takes longer to archive than the time window between backup jobs. The backup job kicks off again and per retention policy deletes the oldest point and begins the newest one. The tape job looks for these old files and fails out because the files planned to tape no longer exist by the time it goes to archive them.

The workaround for this is to disable my backup jobs until completion and hope I remember them while living with having a missing restore point. I don't think this is a proper way to handle things.

I would imagine this applies to wan replication and other copy jobs.
If the backup to tape job were to copy files from oldest to newest this would be reduced... but even better.
If multiple backup jobs were aware of each other when running that would be even more intelligent. If a file is listed to be archived for a running job, shouldn't the backup job cleanup be intelligent enough to recognize these files are required?

[veremin]

What type of tape job are you using? Backup to tape or file to tape one? Thanks.

[kkuszek]

I am using Backup to tape jobs.
There have been instances where monthly full archives have taken 48 hours to run (sas lto6 library, only 3 tapes) and my nightly backups would get in their way.

This is a byproduct by the awful speed veeam gets with tape however I think it reveals a subsystem fault with lack of inter-job awareness and orchestration.
I had a ticket around this happening (01886298) and the solution was to temporarily increase retention time or create unsupported scripts to disable/enable backups as part of the tape job. I disagree and feel managing and locked file coordination as part of the product design requirements.

[veremin]

This should be addressed in 9.5. We're planning to add ability to automatically postpone source backup job until secondary tape one ends. So, stay tuned. Thanks.