Can anyone verify that they have used Robocopy to move FSA placeholders?

[tluncefo]

In this discussion - https://www-secure.symantec.com/connect/forums/moving-placeholders - it was stated that by using (robocopy z:\home f:\home /e /copyall /r:1 /w:1 /sec /b /eta /v /log:c:\temp\robojob.txt) you could move placeholders.  I am wondering if anyone can verify that they have used robocopy to move the placeholders.

I understand that I would have to delete then recreate the archive points, but we have archived and unarchived data spread across hundreds of SAN drives that we want to move and combine to a smaller number of SAN drives.

I am curious if anyone has done this and what they saw afterwards.  Are there any ramifications to moving the data with Robcopy vs Fsautility?

[Vikes_2]

Hey,

That was my post your referenced and I have not messed with robocopy for this since, I am wondering if anyone has updated info on this. We were doing this for server refreshes and in the past they would copy over the data with robocopy but now were are just using netbackup to restore the data since we had issues with robocopy. Using FSA Util would be great if you could do it from the volume root but you cannot. Some of our moves are hundreds of users and doing them one at a time would not be fun. 

Good luck,

Travis

[Darren_Locke]

You cannot use robocopy for placeholders. You want robocopy to ignore placeholders and there is an exclude option for Offline files that you can use.

You should use FSAUtility for placeholder movement. If you are doing a big move then I would highly recommend getting to EV9 and using the new -pm option which will provide very efficient placeholder migration without moving any data in the backend. Please see my blog here for further information:

https://www-secure.symantec.com/connect/blogs/file-system-archiving-enterprise-vault-v9-placeholder-...

Darren

[Mohawk_Marvin]

I have used robocopy, but I prefer NTBackup. However as Darren Locke states, use FSAUtil and if its a mass operation, upgrade to 9 and use a decent version of FSAUtil as pre8 FSAUtil is a bit pants :)

[Gaffer]

I have successfully used Robocopy, but it has some caveats. The key is the /B switch. We use a NetApp appliance and we run the snapshot feature every couple hours during the day. The snapshot preserves the shortcuts/placeholders. However, the snapshot area is read-only so this presented a problem. Non-archived files can simply be dragged back to the production area but archived files return 'access denied' errors - except when Robocopy is run from the EV server itself, and possibly also because I log in as the EV service account. Don't know why that is. But I also experimented with Windows 2003 file server and found Robocopy to work on this too. Problem is that Robocopy is not aware of EV so if you are moving data the database tables (like FolderPath in the Archive Folder table) do not get updated. This is why FSAUtility is better for moves. In my scenario above, since I am only copying the data from the snapshot area back to the original location I have no need to adjust the DB entries. I suppose if one was to migrate to another file server with same server name and volume paths/folder structure then Robocopy could be used. You'd also have to take into account the archive points and the hidden evarchivepoint.xml (notepad :evarchivepoint.xml ) though if Robocopy doesn't preseve this (never tested it).

notepad :evarchivepoint.xml 

We also use NetApp SnapMirror technology to migrate data from one appliance to another or from one volume to another in the case of data re-orgs. SnapMirror preserves all archive points, shortcuts, etc. While SnapMirror is great for our NetApp guys, it causes issue with EV because of the lack of awareness of EV. Thus when they move archive folder structures from G$ to H$, for example, EV is not updated. So far the only issue I've seen is when I use Archive Explorer to restore files - they get restored to original location G$ (luckily it still exists). And luckily our users do not use Archive Explorer and are not aware that it exists. What I need to do is mass update the FolderPath table. Unfortunatlely EV used the NText type for this field so I have yet to find a simple way to do this as SQL REPLACE command does not work with NText type. Arrgh!

We are currently using EV7 but I'm told there have been some changes in EV8 where the folder path is stored in more locations that just the FolderPath table. Symantec Support tech also said its stored in the indexes in EV8.

Regards

[FreKac2]

As Darren says, use fsautility if you can.

Problem with just copies or moves are as already stated that the DB's will not be updated.

On top of that if the move/copy was made to a different volume or server, the archivepoints will not work anymore since the alternate stream already contain evfolderpoint.xml/evarchivepoint.xml.

In those streams there is also a "GUID/ID" value which I've never found out what it's based on, but it will be unique, so probably based on name, date, time etc.

So if you just copy/move to a new volume/server it will not be the same folder even if the structure is the same (meaning, updated date, time, etc.).

Which in turn will generate "duplicate archive point" events when trying to create a new archive point on that location. If you remove the archive point stream (the .xml) the archive will be seen as a new archive, not a re-link to the old since the GUID/ID is new due to the new folder properties.

So basicly, use fsautility for placeholders, robocopy for the rest :)

Cheers

Fredrik