Question

Restore archived files as stub not working

  • 4 February 2021
  • 6 replies
  • 69 views

Badge +1

Hi everyone,

 

At the moment I have 2 seperate CommCells where file servers exist that are heavily archived (10+ TB). The customers want to migrate to new file servers so they want to restore all stubs on the new servers. This is however not working.

We cannot get the files to restore as stubs on either a different destination server or on the same server even though they are stubbed on the current file servers.

We used the following documentation: Migrating Stubs

We have not used Robocopy or the GXHSM tool as they are not recommended according to documentation. Our experience with the GXHSM tool is also that it is not always stable.

We tested this on our test environment and were able to restore the files as stubs. What was noticeable is that all files in a browse screen show as stub while in the customer environments the files are shown as file. This could explain why we get these results but I don’t know why data shows up like it is.

Test environment is at 11.20.32

Customer environments are at 11.20.22 and 11.20.17

Not yet updated customer environment because of long change processes and no indication in MR release notes about any fixes for this issue.

 

Has anyone seen this issue or recommend another way of migrating the stubs without causing recall issues?


6 replies

Userlevel 4
Badge +11

Thanks for the question, @PaulG!  To confirm, when the migration occurs in the customer environment, are the files restoring as full files, or are the stubs simply not showing in any form?

Is there any error or feedback on the job?

Also, can you confirm you UNchecked Restore as Data?

Userlevel 3
Badge +5

Hi PaulG

Please let us know if restore as data was unchecked.

We are keen to take a closer look at this one to assist, so assuming restore as data was unchecked as expected, the next step would be to raise a support case where we can check the Commserve database and indexes with you in more detail.

Thanks,

Stuart

Badge +1

Thanks for the question, @PaulG!  To confirm, when the migration occurs in the customer environment, are the files restoring as full files, or are the stubs simply not showing in any form?

Is there any error or feedback on the job?

Also, can you confirm you UNchecked Restore as Data?

Files are restored as full files. No errors are shown on the restore job.

I did uncheck the option Restore as data instead of stub.

 

Hi PaulG

Please let us know if restore as data was unchecked.

We are keen to take a closer look at this one to assist, so assuming restore as data was unchecked as expected, the next step would be to raise a support case where we can check the Commserve database and indexes with you in more detail.

Thanks,

Stuart

I was already thinking about escalating to CV Support but I wanted to try out the new forum. As the option was indeed unchecked I think it is my only option for now. I will share the solution once resolved.

 

Thank you both for thinking about this issue and taking your time posting a comment.

Userlevel 4
Badge +11

Hey @PaulG , hoping all is well!

Wanted to follow up and see if you were able to resolve this (and share back what did the trick)!

Userlevel 3
Badge +6

Thanks for the question, @PaulG!  To confirm, when the migration occurs in the customer environment, are the files restoring as full files, or are the stubs simply not showing in any form?

Is there any error or feedback on the job?

Also, can you confirm you UNchecked Restore as Data?

Files are restored as full files. No errors are shown on the restore job.

I did uncheck the option Restore as data instead of stub.

 

Hi PaulG

Please let us know if restore as data was unchecked.

We are keen to take a closer look at this one to assist, so assuming restore as data was unchecked as expected, the next step would be to raise a support case where we can check the Commserve database and indexes with you in more detail.

Thanks,

Stuart

I was already thinking about escalating to CV Support but I wanted to try out the new forum. As the option was indeed unchecked I think it is my only option for now. I will share the solution once resolved.

 

Thank you both for thinking about this issue and taking your time posting a comment.

 

If you are wanting to migrate stubs and not trigger a recall, you can use the ContinuousDataReplicator https://documentation.commvault.com/commvault/v11/article?p=37192.htm

Badge +1

Hey @PaulG , hoping all is well

Wanted to follow up and see if you were able to resolve this (and share back what did the trick)!


Still waiting for the case to complete. The customer is not always available slowing this down.

They were able to restore the stubs by using a backup through the backup set that backed up the stubs. This could work as a workaround but I am not sure if this has any implications compared to the official stub migration documentation.

 

 

If you are wanting to migrate stubs and not trigger a recall, you can use the ContinuousDataReplicator https://documentation.commvault.com/commvault/v11/article?p=37192.htm

This is still a workaround compared to the stated documentation. We do have a test environment where we have the steps documented work so I want to solve this rather than supplying a workaround as 10+ servers will get the same treatment.

I do agree with you that using the replication feature would smooth out transition from one location to another.

Reply