per vm backups to tape

[fgw]

having the tape devices support user guide for v9.5 from jan 2019 in front of me and on page 116 it says:

If the source job creates per-VM backups, the tape job gets priority for each per-VM restore point separately.
In this case, the source job will be able to lock other per-VM restore points and perform the needed
operations.

trying to set this up, but however i tr yto configure the tape job it always starts as expected but changes to pending status with the message

No backup files found
Some backup files are locked by running jobs, retry is required

cant change much on the backup job itself besides selecting per vm backup. this definitely works as i get backup files for every vm individually as expected.

but i would have expected the tape jobs starts up and as soon as the first vms are processed and their backup files are created and begins to copy them to tape. instead the tape job seems to wait until the backup job is finished before starting to write files to tape?

tried to setup the tape job having the backup job as source and also having the repository as source! also tried using scheduling the tape job at a fixed time 5 minutes after backup jobs starts and also tried to schedule the tape job as new backup files appear.

no change, always same behaviour: tape job just waits ...

what am i doing wrong here? or do i missunderstand per vm backup to tape functionality?

looks like the backup job is locking ALL backup files also already finished vms backup files instead of locking just backup files of currently written vm backups?

[HannesK]

Hello,
I see a small misunderstanding of the tape job (I reference to the same page.)

If a source job is still writing data to the source repository, the backup to tape job will wait for the specified time interval.

This is also true for per-VM backups.


About your per-VM quote:

The note is about the operations in the section before

Merge of backup files
Reverse incremental backup transformation
Compact of full backup file
Retention Policy maintenance

That means that in case of a per-VM backup job, a tape job will not be interrupted when the backup job performs operations as merge / transforms / etc. with chains that are currently not processed by the tape job.

Best regards,
Hannes

[fgw]

if i understand u correctly, the expected behaviour should be (assuming reversal incremental and per vm backup):

• backup job starts

• backup to tape (source is repository, but i assume using backup job as source would behave the same) starts and waits

• all vm's get backed up

• compaction of all vm's backup files

• health check on all vm's backup files

while compaction and also health check are running, already compacted and health checked vm backup files are unlocked and get processed by backup to tape job

unfortunately this is not the case: the backup to tape job continues to wait until compaction and also health check completes for ALL vm's before starting to copy vm backup files to tape!

preferred behaviour would be to

• not backup all vm's and start compaction and health check after all vm's finished backups

but instead

• as soon as each individual vm is backed up, immediately compact the corresponding vm backup file, do the health check on it and unlock the backup file again! so backup to tape job could immediately start to copy each single vm backup file after this particular vm has finished processing (backup, compact, healthcheck) instead of waiting until ALL vm's are processed and also until compaction and health check is finished for all vm's backup files

that way backup job and backup to tape job interleave each other and total backup processing time will save a lot of time. in my case it would be somewhere between one or two hours for about 150 vm's and 15TB data in total that total backup time could be shortened.

[HannesK]

Hello,
there is still a misunderstanding. The merge, compact etc. I mentioned earlier is for situations where the tape job is still running.

Sometimes, the source job may start when the tape job is still running [...]

Health check is not in that list and if you are using it, I would suggest to run health checks on different days.

I understand your idea / wish, but this is not how it works today. I note that improvement as a feature request.

Best regards,
Hannes

[rboynton]

"that way backup job and backup to tape job interleave each other and total backup processing time will save a lot of time. in my case it would be somewhere between one or two hours for about 150 vm's and 15TB data in total that total backup time could be shortened."

In our case, looks like Veeam will back up some jobs, then go back and see new ViB files and back those up too. This makes the backup window take a really long time an eat a lot of tape space. When selecting full backup with incrementals (full chain), isn't there a way to run a job at a certain time and only have Veeam back up files that are created at or before that start time and nothing newer?

[HannesK]

Hello,
Veeam will always backup everything that was not backed up before. You can set "only latest chain" (or similar), but I'm afraid that also does not help in that case.

What I have seen at most customers is that they don't do incremental backups to tape to simplify restore.

Just a small question: is your tape backup running at maximum speed the tape drive allows? Usually it is a good idea to finish backup jobs first and start tape after backup job finishes to get full speed of the tape drives. Because in many cases the repository is getting too slow (with spinning disks) when doing backup and tape jobs at the same time.

Best regards,
Hannes

[rboynton]

We are getting around 280 out of a possible 300, so not too bad. What we are experimenting with now is to not do any new backups over the weekend, and run the tape backups then. That way nothing is messing with the .vbk or .vib files while the tape is running. This is less than optimal, but if it gives us a good backup set, then may be worth it.