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
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.