Skip to main content
commvault.com commvault.com
Solved

Restore archived files as stub not working

  • February 4, 2021
  • 9 replies
  • 1530 views
P
Byte
Forum|alt.badge.img+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?

Best answer by PaulG

Hi Mike,

 

In the end we were not able to resolve the issue so restores could be performed according to the documentation. Instead we solved this by using a workaround.

We now take a full File System backup so all stubs are backed up in the default backup set. From this we can restore the stubs to another server. This was verified by the engineer as a valid solution to the issue.

View original
Did this answer your question?

9 replies

Mike Struening
Vaulter
Forum|alt.badge.img+23

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?

https://www.linkedin.com/in/michael-struening
S
Vaulter
Forum|alt.badge.img+15

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

Customer Support
P
Byte
Forum|alt.badge.img+1
  • PaulG
  • Author
  • Byte
  • 3 replies
  • February 5, 2021
Mike Struening wrote:

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.

 

Stuart Painter wrote:

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.

S
1 person likes this
  • S
    Stuart Painter
Mike Struening
Vaulter
Forum|alt.badge.img+23

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)!

https://www.linkedin.com/in/michael-struening
Anthony.Hodges
Commvault Certified Expert
Forum|alt.badge.img+10
  • Anthony.HodgesCommvault Certified Expert
  • Commvault Certified Expert
  • 87 replies
  • February 19, 2021
PaulG wrote:
Mike Struening wrote:

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.

 

Stuart Painter wrote:

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

P
Byte
Forum|alt.badge.img+1
  • PaulG
  • Author
  • Byte
  • 3 replies
  • February 19, 2021
Mike Struening wrote:

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.

 

Anthony.Hodges wrote:

 

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.

Mike Struening
Vaulter
Forum|alt.badge.img+23

@PaulG , can you send me the case number via a private message?  I’ll follow up on it as well.

https://www.linkedin.com/in/michael-struening
Mike Struening
Vaulter
Forum|alt.badge.img+23

@PaulG , were you able to get this working yet?  If you have an incident (I couldn’t find one), send me the case number via Private Message and I can follow up.

https://www.linkedin.com/in/michael-struening
P
Byte
Forum|alt.badge.img+1
  • PaulG
  • Author
  • Byte
  • 3 replies
  • Answer
  • March 9, 2021

Hi Mike,

 

In the end we were not able to resolve the issue so restores could be performed according to the documentation. Instead we solved this by using a workaround.

We now take a full File System backup so all stubs are backed up in the default backup set. From this we can restore the stubs to another server. This was verified by the engineer as a valid solution to the issue.

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings