Pre run tape check tool?

[aich365]

Hello
We have a number of jobs configured to run over the weekend.
Recently we have changed these from file and folders backups to VM backups.
None of the jobs ran over the weekend , because one job was incorrectly configured.
It would be helpful to have a Veeam tool that checks the setup of eaach job to ensure the correct tapes are loaded i nthe device, the tapes are in the correct media pool and the tape has free or expired space.
At them moment there are too many places to check so items can get missed.


thanks

[nielsengelen]

Could you tell a little bit more on the error why it didn't run? This way we can use the information and improve where needed.

Was it due to a tape issue or was there an issue with how our job should pick up the thing you wanted to achieve?

Thanks!

[aich365]

GFS jobs require the jobs to run in sequence.
If there is a failure (or the job is missed) then the job will use the next scheduled slot to run and everything is "one-slot" behind.
Unless you are expecting this behaviour it comes as a surprise to see a job for 21st October being run on 28th October, pushing the monthly job back. This meant the tape missed the "off-Site" collection truck as it had to be re-run.
Veeam must contain the logic in its setup to know what will run and at what time.
A simple check tool to advise whether there are enough tapes installed, the correct media pools have the correct tapes and whether any outstanding jobs are due to run would be extremely helpful.
It would also be helpful to be able to skip a missed job (rather than disable the job before it is next due to run and then re-enabling it after)
We can manage without a missed daily backup (and the occasional weekly) but it is imperative the monthly jobs run as these are stored off-site.
The staff changing tapes on site do not always fully understand what tapes are required despite many attempts to simplify the information.
A pre-flight check would be useful tool.
Similarly if a job is missed it would be helpful to know when it is due to run.
Thanks

Case 03230656

[Dima P.]

Hello Clive,

Thanks for the feedback!

Unless you are expecting this behaviour it comes as a surprise to see a job for 21st October being run on 28th October, pushing the monthly job back. This meant the tape missed the "off-Site" collection truck as it had to be re-run.

Are you saying that you basically don't care about the backup to tape if the day was missed? Then how to achieve the planned GFS schema? The entire engine is built around idea that we must guarantee that selected retention will be achieved: if you missed the tape out day, no worries - we can write backup file for the given day later.

A simple check tool to advise whether there are enough tapes installed, the correct media pools have the correct tapes and whether any outstanding jobs are due to run would be extremely helpful.

Good idea, thanks!

The staff changing tapes on site do not always fully understand what tapes are required despite many attempts to simplify the information.

May I ask whats the most common issues here?

A pre-flight check would be useful tool.

Please elaborate what type of pre-flight check are you looking for? Cheers!

[aich365]

Hi Dimitry
The GFS job does not seem to be able to run daily, weekly, monthly, quarterly and yearly jobs as a single sequence.

The GFS jobs we run supplement a Daily job.The daily job runs Monday to Saturday. The GFS job runs on a Sunday.
If we miss a Sunday weekly backup it doesn't matter too much because we have the Saturday Daily tape (or at a push the Monday Tape).
The weekly tapes are on a 3 week rotation so they get overwritten in 4 weeks anyway. (week 4 is a monthly tape)
the monthly tapes are on a year's retention so these are important and we cannot afford to miss them.
When looking to restore data more than 4 weeks old we only have monthly tapes (or quarterly)

A pre-flight check that enabled us to view tape jobs due to run in the next 7 days would be useful. (this could be configurable for 1-7 days?)
This would show missed jobs that will have precedence over scheduled jobs (we could then run these manually to maintain the sequence), it would advise on what media was in the Autoloader, what media was required and if the media was correctly assigned to the media pool. This would remove the need to trawl through the job logs to try and make sense of where Veeam is with tape backups.
It would also remove the need to "wait and see" if all works at the weekend when there are no staff available.

Many Thanks

Clive

[aich365]

We had a job fail this weekend with a "tape CRC checksum" error
This could have been highlighted by a pre-flight check tool or even by having the option to "short erase" the tape prior to running the job as a config option

thanks

[aich365]

We had an issue with a CRC error on Tape. This held up 4 jobs.
After the Tape was erased and the job started it stalled building file tree (a known issue)
It seems that clicking Start - starts an Incremental backup even though this is not scheduled in the tape job
I discovered today that to run a Full Backup "Active Full" should be selected.
This does not follow the logic of disk based backups where a failed job can be "retried" and Start just starts the next backup.
If Start only triggers an Incremental backup it should be clearly marked as Incremental Start
A pre-flight check could have revealed that an Active Full was required.
A time out setting would also be useful so if a job has stalled for its usual run time (or a configurable time) then it can be "skipped" allowing other jobs to run.
This is particularly important over extended Bank Holidays where the Autoloader may be full and the first job fails leaving 7 jobs queued and nothing gets backed up - particularly problematic for GFS jobs where the sequence needs to be maintained.

One thing that would have helped is when clicking "Start" a prompt appears advising Incremental job is not configured - Full Job should be run: Continue/cancel

Regards

[Dima P.]

Hi Clive,

We had a job fail this weekend with a "tape CRC checksum" error

Thanks for the detailed response. I believe 'pre-flight' would not detect the CRC error as it's occasional problem caused by either source file corruption or tape media corruption. Have you reported the CRC issue to the original case?

This does not follow the logic of disk based backups where a failed job can be "retried" and Start just starts the next backup.

True, there is no retry functionality in the way VM backup does. That's sounds like a different feature request to retry (and reuse already written blocks on tape) if the job fails, but consider your vote being added to this feature request. Thanks!