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!
-
- Veeam Legend
- Posts: 143
- Liked: 41 times
- Joined: Sep 26, 2013 8:40 am
- Full Name: Alessandro T.
- Location: Bologna, Italy
- Contact:
Slow DB Migration/log time spent in Tape server scanning [Case #07348646]
Alessandro aka Tinto | VMCE 2024 | Veeam Legend | VCP-DCV 2023 | vExpert 2025
blog.tinivelli.com
blog.tinivelli.com
-
- Veeam Software
- Posts: 2838
- Liked: 650 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Slow DB Migration/log time spent in Tape server scanning [Case #07348646]
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.
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.
David Domask | Product Management: Principal Analyst
-
- Veeam Legend
- Posts: 143
- Liked: 41 times
- Joined: Sep 26, 2013 8:40 am
- Full Name: Alessandro T.
- Location: Bologna, Italy
- Contact:
Re: Slow DB Migration/log time spent in Tape server scanning [Case #07348646]
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
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
Alessandro aka Tinto | VMCE 2024 | Veeam Legend | VCP-DCV 2023 | vExpert 2025
blog.tinivelli.com
blog.tinivelli.com
-
- Veeam Software
- Posts: 2838
- Liked: 650 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Slow DB Migration/log time spent in Tape server scanning [Case #07348646]
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.

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.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Bing [Bot] and 19 guests