Veeam configuration backup & restore and backup to tape jobs

[erth111]

Hi, I have a question regarding restoring veeam configuration:
I'm deploying single physical veeam server with a tape library. I'm trying to prepare second, standby server which has exact same configuration. I have some backup to tape jobs defined with "as new backups appear" type schedules. After I switched off the first server and recovered the configuration to the standby server all these backup to tape jobs started running immediately. I disabled all of these jobs. I noticed that backups on tapes weren't in the inventory until I performed catalog of the tape library. But even after that, a chosen backup to tape job started running just when I enabled it, in spite of the fact, that the same backup files that were being moved to tape were already there and inventoried by veeam. Looks like veeam recognizes backups discovered on repository as new backups.

Is there any solution to this behaviour?

[veremin]

Just to clarify situation - you switched from one backup server to the other, using backup configuration functionality and copying existing backups, re-connected the tape library, cataloged it to populate the backup data located on tape mediums, enabled the tape jobs and they started immediately copying backups already present in the backup catalog, right? Thanks.

[erth111]

Just to clarify situation - you switched from one backup server to the other, using backup configuration functionality and copying existing backups, re-connected the tape library, cataloged it to populate the backup data located on tape mediums, enabled the tape jobs and they started immediately copying backups already present in the backup catalog, right? Thanks.

The backups were in fact not copied, I have a SAN network so the lun has been mapped to the second server. It appears with the same drive letter as on the first server. When I recovered the configruation and opened the B&R console, the tape jobs were already activated and they started running. I did not have an opportunity to perform tape library catalog before the jobs started and thats why I stopped the tape jobs, disabled them, performed tape library catalog (actually of one tape, because cataloging whole library would be a long process) and enabled the tape jobs again (actually one job that contains backup corresponding to the catalogged tape). After this, the tape job started running again which I expected not to happen.

[veremin]

And the cataloged medium had all the backup files of the given job that were present in the repository? I mean there weren't any new or previously uncopied backup files that the said tape job might have decided to copy? Thanks.

[erth111]

And the cataloged medium had all the backup files of the given job that were present in the repository? I mean there weren't any new or previously uncopied backup files that the said tape job might have decided to copy? Thanks.

I'm not 100% sure about this. I will have to make one more test to confirm. Anyway, how to prevent the tape jobs from running before the tape library gets cataloged?

[veremin]

I believe you can disable given jobs prior to taking configuration backup. This way, once configuration is restored, these jobs will preserve "disabled" state. Thanks.

[erth111]

But configuration backup is taken automaticaly on a daily basis according to schedule. Is there any way to automate this?

[veremin]

There is "Backup Now", using which configuration backup is created immediately. So, before moving to the new server, you can try to disable tape jobs, backup configuration, restore it on new server and see whether the disabled jobs preserve their state. Or you're after disabling job, taking configuration backup in automatic fashion?

Thanks.

[erth111]

This is not an automated solution. As I mentioned earlier, the second server is meant as a backup in case of a failure of the first one, so I'm not able to predict when this happens. The only satisfying solution would be to automaticaly disable tape jobs before the scheduled configuration backup and enable them after the backup.

I think that all tape jobs should be automaticaly disabled when restoring configuration backup. Then, the user would enable them after cataloging the tape library.

[veremin]

What schedule does the configuration backup have? You can schedule the following script (via Windows Scheduler) to run just before the configuration backup takes place. This script should disable tape jobs, and enable them after 5 minute interval.

Code: Select all

Get-VBRTapeJob | Disable-VBRJob
Start-Sleep -Seconds 300
Get-VBRTapeJob | Enable-VBRJob

Otherwise, if you want to deal with configuration backup schedule, you can add Export-VBRConfiguration command that instructs backup server to export its current configuration and run this script whenever you want:

Code: Select all

Get-VBRTapeJob | Disable-VBRJob
Export-VBRConfiguration
Get-VBRTapeJob | Enable-VBRJob

Thanks.

[erth111]

I'm not 100% sure about this.

I made one more test and I can now tell that your sentence is true. What I did was:
1. Disabled tape library in Device Manager on the standby server to make backup to tape jobs fail if they "decide" to run.
2. Restored veeam configuration
3. Opened the B&R console. As I expected the backup to tape jobs started running because there was no information about the content of the tapes.
4. Disabled the tape jobs (my veeam configuration backup had the jobs enabled)
4. Enabled tape library and performed catalog of the WHOLE library
5. Enabled one of the tape jobs. It started running automatically.

[veremin]

In other words, even though the whole library had been cataloged, the tape jobs started transferring the backup data that was already present in the cataloged library, right? Thanks.

[erth111]

In other words, even though the whole library had been cataloged, the tape jobs started transferring the backup data that was already present in the cataloged library, right? Thanks.

That is correct.

[veremin]

I've asked QA team to reproduce this issue. If it shows up in our environment, we will address in one of the next product versions.

Thank you for drawing our attention to this problem; highly appreciated.