cancel
Showing results for 
Search instead for 
Did you mean: 

Moving placeholders

Hello,

So in looking at some of the other posts most info on this seems to be from a while ago so I wanted to confirm some info about moving placeholders. We have several servers that will be refreshed so realistically only for a short time will the new server be listed as a different server on the domain then once the data is back it will be renamed to match the original server. So moving placeholders would not be a good option as it would create a new archive for the temporary server name, right? We had another server that was refreshed due to hardware issues and what we wound up doing was restoring from NSI doubletake to the new location then we had to restore the archive points which was no problem. I was just wondering what others do for instances such as this, moving does not seem to be the best option but not sure what is the best way to go? Also for clarification is the move placeholder Utility still limited to subfolders of the share, so if you have 100 sub folders of a home dir you would have to run it for each? Next, does the move placeholder aspect of FSAUtility move everything archived like doing a restore of the placeholders? If so I find this to be an issue since a user can delete 500 items from the file server and if they are still in the archive they all come back. Lastly what would happen if you turned off the placeholder service and moved the placeholders, I would guess that at most you would lose the archive point info from the hidden file on the volume and would have to restore the archive points?

Sorry to ramble on but any suggestions on the server refresh would be greatly appreciated!

Travis
1 Solution

Accepted Solutions
Accepted Solution!

Ok so what we found is

Ok so what we found is although using robo-copy is about third in line as far as recommended ways to move placeholder data from one server to another, the first being a restore and second the FSA UTIL. We have environmental limitations for the restore since it is remote and a slow pipe, for restore over the wire. And the move via FSA Utility has what I think is a huge flaw, you cannot move from the root only sub-folders. Not a problem if you have 5 sub-folders, but we have thousands on each server. So you can move placeholders using robocopy with the switches listed above. The plaeholders all open without issue, the only issue we saw was trying to archive new items. So I ran FSAUtility to recreate archive points it said it was complete and when I ran archivepoints find \\server\share it said they were there, but when I ran the archive task it said no archive points are associated with the volume. What we needed to do was delete the archive points archivepoints delete \\server\share then run recreate them FSAUTILITY -a -s \\server\share. After doing this everything was fine. It looks like somewhere in the background, probably SQL the old archive point info is stuck so even though it looks like it is there it is not valid for the new server.
Hope this explanation helps and thanks Paul for your assistance on a possible fix.


Travis

View solution in original post

6 Replies

add on

Ok let me add one more thing just to fill in any blanks. We first used robo copy to copy the data to the new server which did not work well with the placeholders.Also we have some servers (remote) using NSI and some using net backup.

Thanks
Travis

Travis Did you come up with a

Travis

Did you come up with a solution here?

Cheers

cloudficient - EV Migration, creators of EVComplete.

hmmm

Ok so what we did was:
1. Install FSA utility on new server
2. Run robocopy  with backup mode switch--    robocopy z:\home f:\home /e /copyall /r:1 /w:1 /sec /b /eta /v /log:c:\temp\robojob.txt

So the data looks good, I can open items without issue, but the archive points are not playing nice. I recreated the archive points using FSAUtility and I still get "There are no archive points associated with this volume". When I run archivepoints find \\server\share   it comes back with the archive point info. But I cannot run the task against the target for new items as it does not see the archive points. I restarted the task and restarted the FSA placeholder svc on the file server. What am I missing here??
Thanks,
Travis

Also for clarification is the

Also for clarification is the move placeholder Utility still limited to subfolders of the share, so if you have 100 sub folders of a home dir you would have to run it for each?
Correct

does the move placeholder aspect of FSAUtility move everything archived like doing a restore of the placeholders?
It is a copy/delete operation. So if you have the following:-

Archive Point is at the share level so you would have an archive called share1

\\server1\share1\folder1    - 10 items archived in this folder

\\server1\share1\folder2 - 10 items archived in this folder

So currently you would have 20 items in archive named share1

If you then had with an archive point at share2:-

\\server2\share2\folder1

You would then run fsautility -m -s \\server1\share1\folder1 -d \\server2\share2\folder1

If you were to copy the items for example with explorer to your other server this would generate a recall of the files on the source server and then you would have the original file on your destination server and they would be archived again on the next run in the new archive.

What this will do is copy/delete (move)10 items

So now you would have 10 items in the archive named share1 and 10 items in archive named share2

Lastly what would happen if you turned off the placeholder service and moved the placeholders?
If you mean when using FSAUTILITY then the operaion would not work as the placeholder service is used.

Using Robocopy like you have done does copy the files directly and they will open fine but when you come to archive them again it will try and archive them where they now are again in the new archive which is your case it cannot find as you must have not set it up.

Hope all of that makes sense
Accepted Solution!

Ok so what we found is

Ok so what we found is although using robo-copy is about third in line as far as recommended ways to move placeholder data from one server to another, the first being a restore and second the FSA UTIL. We have environmental limitations for the restore since it is remote and a slow pipe, for restore over the wire. And the move via FSA Utility has what I think is a huge flaw, you cannot move from the root only sub-folders. Not a problem if you have 5 sub-folders, but we have thousands on each server. So you can move placeholders using robocopy with the switches listed above. The plaeholders all open without issue, the only issue we saw was trying to archive new items. So I ran FSAUtility to recreate archive points it said it was complete and when I ran archivepoints find \\server\share it said they were there, but when I ran the archive task it said no archive points are associated with the volume. What we needed to do was delete the archive points archivepoints delete \\server\share then run recreate them FSAUTILITY -a -s \\server\share. After doing this everything was fine. It looks like somewhere in the background, probably SQL the old archive point info is stuck so even though it looks like it is there it is not valid for the new server.
Hope this explanation helps and thanks Paul for your assistance on a possible fix.


Travis

View solution in original post

Paul this does make sense, as

Paul this does make sense, as mentioned the big problem is having to run the fsautility to MOVE the placeholders. We have thousands of sub-folders and this is all over a slow network pipe, so running this a few thousand times just is not an option. In this case we have a server that has a hardware issue and a new server sitting right next to it, so copying the data to the new sever locally is just our only option. Even the backups are over the wire so hopeuflly we will be in good shape, but in testing the only gotcha was the need to delete the archive point and recreate it.
Thanks again for the info, and I would say that if you did not have the env limitations that we do your option is definitly a viable fix.

Thanks

Travis