Slow DB Migration/log time spent in Tape server scanning [Case #07348646]

[tinto1970]

good day, I was helping a customer to migrate the DB to a more powerful and updated MsSQL instance. The server has a lot of Biiiiiig file to tape jobs, and a big Catalog.

Migration went fine but at the last step We experienced this behaviour

https://community.veeam.com/discussion- ... nning-5600

it was not "stucking" because we have seen cpu activity on the new database server. But after 2 hours, more or less, of this scanning, we had to abort and restore the previous configuration. The problem was also that no % of progress is available, so we could not forecast the ETA.

I opened a case to see if the support engineers can identify some mistakes/workaround. I would like to discuss of this step in the restore process

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

we checked the Backup and replica Catalog.: it seems this to be the cause of the looong "tape server scanning". Could please someone better explain "what if" I don't check this option?

Thank you!

[david.domask]

Hi Alessandro,

Thank you for the explanation and sorry to hear about the challenges. Regarding the checkbox you mentioned, unchecking that means that the tape catalog and backup catalog will not be written to the restored configuration database; while it won't break anything, it means that for tapes at least, Veeam won't know about the contents of the tape until you catalog the tapes, which can take awhile especially if you're heavily invested into File to Tape.

I'm not immediately aware of any issue like this with the configuration restore, so I think let's allow the Veeam Support team time to review the logs a bit more in-depth. It may help to isolate if you're willing to do a test restore to an empty database _without_ the catalog and see if it waits in a similar way at the same step -- I somewhat expect it will, but if not, it's valuable information. The database from the test restore can be used naturally, but you will need to prepare to catalog the tapes before restores are possible, which probably is not feasible if the tapes are being off-sited after tape-out is complete.

[tinto1970]

yes, sadly, we were quite in an hurry and when we aborted the process we quickly reverted the Vm to the previously taken snapshot. The support engineer gave me instructions to take the logs in case we have to abort again the process at next time.

Thanks for the explanation: my customer has a lot of tapes in big libraries so it would surely be better to restore those data.

thanks

[david.domask]

Glad I could share some useful advice Indeed, I would include the Backup and Replication catalog for installations that utilize File to Tape heavily unless there was a specific reason to not need the catalog anymore.

And no worries, reverting the snapshot makes sense and I forget to grab logs before reverting in my testing fairly often so I think it's normal. Let's see the results once we're able to get a reproduce and the logs, and I'm sure we'll find some leads.

[mdiver]

We just ran into the same issue in a larger customer environment (GxP-regulated environment with a defined maintenance window). In our case we're migrating from MS-SQL to PG17 on VBR13.

As there are 8 tape servers with a lot of tapes we've been waiting for >4h now. It would be very helpful to have a progress bar in this last step of the migration.

Also it would be good to know, if we can already use VBR as the services are running from the new DB already.
We have to run non-tape backup jobs as the maintenance window closes.

Thanks,
Mike