cancel
Showing results for 
Search instead for 
Did you mean: 

Orphaned placeholders after using FSAutility to restore archive back to drives

BJSmith
Not applicable
Hello all,

I have been called into a customer site to remove EV 8 SP3 file system archive from their servers. For various resons the relationship was not working and they wanted the 550GB of data moved back onto the source volumes. They were archiving PDF, DOC and XLS files over 6 months old. The EV server is virtualized and there are two vertitas redundant cluster machines connected to the SAN luns containing the source volumes.

Initially I used a FSAutility -t -s "volume path" -l 0 -f to force is all back to where it came from. Insufficient permissions for the EV user caused havoc here as it could not write the data back to the source in many instances. Being user and group folders in a secure environment a universal take ownership was not an option. The customer wanted the data restored to another location so they could then copy the data back over the top of the source in stages and deal with the permission problems as they arise. A number of issues are now present:

1. Orphaned and stubborn placeholders everywhere on the source. Trying to reconcile the restored data with the original source data is showing huge differences. There are many placeholders on the source which do not correspond to data restored to the new location. Even where the vault has released the originals there are issues copying over the top. All of the placeholders have the Attribute 1024=true 'Offline' set, and most can be deleted or copied over, but I have a host that cannot be renamed, deleted, copied over or moved. I have found a utility that can reset the 'offline' attribute on most, but the few stubborn ones will not change. I have run the FSAutility -o -s option to try to delete the orphaned placeholders but the results XML has no actions recorded and the placeholders are not removed from the source.

2. I'm finding placeholders which appear to have valid data stored in the vault. I can see file system archive records which appear to relate to the source placeholders, but when I restore that path back out to either the source or a new location the process completes without failure but the results XML doesn't contain the expected documents to be restored and the data of course is not there.

3. An odd mismatch of data volumes. The EV FSA summary report says the vault contains 546GB of data, after everything has been restored to a new location I have 620GB of data on disk, and then I'm finding data missing in the new restore location that I expect to be there based upon placeholders remaining at the source location.

Has anyone been through this process before and might be able to offer some clues or tips on how to get all the data out the vault and reconcile the numbers..? Also a good strategy to find and destroy the wayward placeholders on the source volume would be much appreciated. There are no native windows tools to allow you to search on or change the attribute of 'offline' files. A VBscript can identify those files okay, but cannot seem to reset them programatically.

Thanks, BJSmith
1 ACCEPTED SOLUTION

Accepted Solutions

gibolin
Level 3
Partner Accredited
Indeed on a Windows file server, when you overwrite a placeholder with a regular file, the offline attribute is kept.
I didn't try it myself yet, but perhaps the repairOffline.mdb from Paul van der Elst could help : https://www-secure.symantec.com/connect/downloads/fsa-repair-incorrect-offline-flagged-files-repairo...

View solution in original post

1 REPLY 1

gibolin
Level 3
Partner Accredited
Indeed on a Windows file server, when you overwrite a placeholder with a regular file, the offline attribute is kept.
I didn't try it myself yet, but perhaps the repairOffline.mdb from Paul van der Elst could help : https://www-secure.symantec.com/connect/downloads/fsa-repair-incorrect-offline-flagged-files-repairo...