Feature Request prioritize Fulls (with Incs enabled)

[andyman3000]

Hello,

I have a problem with the way Fulls are cloned to tape when Incrementals are also enabled on the same job to a separate media pool. Veeam seems to allow incrementals to write to tape even though there are Fulls still needing to complete.

For Veeam B&R (VMware backups) I have 10 separate backup-to-tape jobs, one for each 10 source backup jobs each of varying number of VM's set to run continuously as backup files appear. Additional caveat is that I am backing up to HP Store Once Catalyst shares, and backup-to-tape jobs will always be interrupted when the source job starts which limits my window of backups cloning to tape. With that in mind, that shortens my windows where backups can be cloned to tape -- and my goal is to have all "Weekend Fulls" completed to tape and offsite Monday morning doing active Fulls every Friday (backing up the latest backup chain). I would like to leave Archive Incrementals to tape enabled, but the problem I have is that jobs begin writing Incrementals as they are created even though there are still fulls that need to clone to tape for the currently weekly full.

So what I do is disable incremental archives until all Fulls are complete, offsite the Full media pools' tapes, and then I enable incremental (which causes a Failure as the job restarts, dings my report, as well it is a manual step). I am working on a script to enable incrementals once I know all fulls are complete to lessen the ammount of clicking I need to do, but it would be nice if Veeam B&R did not even attempt to write any .VIM files to tape if there is still .VBK's that have not been written to tape.

Another side note with Catalyst on HP Store Once is that it seems pretty well known that the read/re-hydration of backups is already very slow/taxing on the throughput. I cannot leave Incrementals enabled on Source jobs that reside on Catalyst shares because it will kill throughput from ~350-600 MB/s to <5 MB/s. My guess is that it is trying to enumerate all the files causing more I/O on the StoreOnce. So wondering if the way backup-to-taps jobs are handling the Full/Inc chains could be improved in any way -- Only Focus on Fulls , then get the Incrementals.

On a almost separate note, I use Veeam Agent for Physicals backing up source jobs that go to CIFS shares (off the StoreOnce sadly).
The CIFS share backups-to-tape do not get interrupted by source job which allows to jobs to run almost continuously which is good for me. But, In my case I have about 27 source jobs in one backup to tape job which (Unlike the 1:1 backup-to-tape jobs for Virtuals, When a drive is Free'd up with Virtual backups it does not start backing up another source backup job group, for Physical Agent backups for some reason it does allow the tapes to be freed up for another source job which is what I'm taking advantage of here). The only problem here is that again if I enable Incrementals, the tape job will begin writing Incrementals to tape even though there are still Fulls needing to be copied to tape. My goal is to have all Fulls offsite with the Vaulting company on Monday Morning, then T-FRI have incrementals picked up.

I believe if I had storage that had faster read speeds this would almost certainly not be as big as problem as I have had, but I am still stuck with HPE StoreOnce as backup storage and am required to clone to tape until we can get some better storage.

I am wondering if anyone else has these same requirements, and strategy of getting fulls complete first and offsite before incrementals. Or if there is different scheduling options I should try for backup-to-tape jobs.

[Dima P.]

Hello Andy.

I have a problem with the way Fulls are cloned to tape when Incrementals are also enabled on the same job to a separate media pool. Veeam seems to allow incrementals to write to tape even though there are Fulls still needing to complete.

Generally, that's not correct - incrementals should be processed only after full backup. May I ask you to submit a support case an let our team investigate your setup and application logs? Please share the case ID in this thread once you have one.

My guess is that it is trying to enumerate all the files causing more I/O on the StoreOnce. So wondering if the way backup-to-taps jobs are handling the Full/Inc chains could be improved in any way -- Only Focus on Fulls , then get the Incrementals.

What is the backup mode for these source backup jobs? Any chance you they are set to run in forever incremental backup mode? Thanks!

[andyman3000]

Dima,

When the initial "Friday (active) Fulls" complete only those newly created Fulls are enumerated and begin cloning to tape, but lets say only 80% of the fulls finish to tape as the next incremental runs and stop the backup-to-tape job. Once those subsequent incrementals finish (Sat/Sunday), the tape job(s) resume and usually begin copying the new incremental files of the 80% of the servers that already had fulls complete, but do not prioritize on completing the final 20% that still have yet to have fulls complete.

This is the backup mode of both VMWare and the Veeam Agent backup jobs. Friday Active Fulls, forward incrementals.
Please note that
1.) VMWare backups we back up to HPE StoreOnce Catalyst Shares, which requires Periodic Active Fulls and do not support forever incrementals. (Backing up to Catalyst Source Jobs will always interrupt secondary jobs)


2.)Veeam Agent does not Support Catalyst and we back up to CIFS, but we still do Active Friday Fulls with forward incrementals (Source backup jobs do not interrupt secondary jobs)

[andyman3000]

Case #03306653 was created.

[Dima P.]

Hello Andy,

Thank you for the update and case details. Let support team investigate the application logs and share the result of their finding. Cheers!

[Sloan]

Did you ever get a resolution to that case or get another solution?

[veremin]

Sloan, if you want to have the issue resolved, kindly, open ticket with our support team. Thanks!

[Sloan]

Nope, I just wondered if HE got a resolution. I never said that I had the issue.