Im in the process of moving shared drive data from VOLUME A to VOLUME B. Once data is moved, my plan is to swap drive letters so VOLUME B will become the new VOLUME A.
Once this step is complete I will need to restore placeholder files to their current and most up to date location. From previous forums I have found that EV will restore files to their 'original' location, but I need to be sure that files that have been archived (placeholders) will restore to their current location, meaning no difference to the end user.
Would I use the FSAutility below to achieve this?...
FSAUtility -c -s \\server\VOLUMEA -l 0 -r
Any advice greatly appreciated.
Depending on how you are moving the data, it may not be required to recreate the shortcuts as they may still work. By the way, if it is a Windows File server, you can simply clone the volume by adding a mirror using the built-in Logical Disk Manager. This should maintain the placeholders intact.
However, if the placeholders are not working, then you can follow the procedure documented in this article to recreate them: https://www.veritas.com/support/en_US/article.100020420
Thanks for your response.
The volume needs to change partition type from MBR to GPT, so I am using robocopy to copy live files only, ignoring placeholders, to the new VOLUME B, from VOLUME A. The server is not changing, just the volume where the data is stored.
I dont believe this option would work https://www.veritas.com/support/en_US/article.100020420
The only way to retain the PH files in the current location is to restore the data from backup as that would retain existing location. If you move the non-PH files with robocopy and then backup/restore the remainder of the data that should get you the result you need.
FSAUtility will only restore to the original location so it cannot be used to restore the existing location of the PH files. The FSAUtility -m requires a source and target archive so it would not work in this scenario.
No need for EV to be in backup mode as the files are on the file server. Backup software should not cause download of the item since it should backup and restore as is with all the attributes and reparse information(used to recall the file from EV).
Ok thanks. I have tried 2 different industry standard backup solutions but they have been unable to backup placeholder files, any ideas as to why this may be? There are no exceptions in place.
Is their a method of copying placeholder files (not moving or recreating) keeping all attributes and reparse information?
Are they ignoring offline files? That would be the only reason I could think that it would not back them up. If so, there should be a setting for that within the application.
A copy of the file will cause a recall of the data in order to copy so it would not get the result you are looking for.
Hi, the method I found to work best was to stop the EV File Placeholder Service on the file server (something I never knew existed on the FS and found by chance), which then allowed a robocopy of the PH files without recalling archived files.
This has worked for me and I am able to recall the file from the new location.