Migrating Placeholders

[dpesposito]

Notes:
Migrating off a celerra to a netapp filer
36 mil placeholders on celerra, need to avoid recall
20tb of other customer data
identity swap between the source and the destination
need the smallest possible migration window
hoping fsautility can perform incremental/differential copy (for a small cutover window)


A customer is looking to migrate off of a celerra to a netapp filer. We are considering the fsautility for this, however, we are concerned about the items listed above. Can someone comment on how fsa would address any of these concerns and if there are guides & best practice notes available online? Thank you

Questions
-do we have the ability to perform a incremental/differential with fsautility?
-does the fsautility have to modify the placeholder and the ev database to migrate
-how do customers typically go about migrating these, is there mandatory (lengthy) outage window or are there tricks to doing it right?
-if the ev server is just pointing to the celerra storage via a drive letter, does this migration become much easier? Is it just a matter of replicating the placeholders to a new drive letter and upon cutover, assign the old drive letter to the new storage?

Thanks in advance if anyone can assist ;)

-daniel

[AndrewB]

I've looked into this for a customer of ours and from what I read it can't be done without recalling all the files. I think it would be a different story if the source and destination storage were similar devices.

[Rob_Brenner]

First advice, don't rush. Try to study the options available by reading the documentation about what is offered with FSAUtility. In EV 9.0.x you have a more performance eficient option to Migrate PH.

FSAUtility -m (Move) uses more complex and expensive SQL calculation methods which are very slow compared to the new feature.

FSAUtility -pm (Placeholder Migration) moves the placeholders and archive points without moving the items in the Archive. Basically the items remain in the Vault Store Partition and the PH are moved to the destination file system and retain their links to the archived files. this option therefore provides a much faster solution for moving PH than the move option.

I would also strongly recommend trying to avoid finding other clever solutions as due to the references to the original data location stored in the EV databases, by just trying to  mount the storage under a different drive letter etc, will only give you headache in the future as the references will be lost. if you want to manage this migration in a way that will prove less troublesome, then test FSAUtility in a small scale, i.e. test on a low level subfolder where you have a small number of items. This will aloow you to gauge approximate performance figures.

For more information, check the Utilities.pdf doc shipped with the product under the section Migrating Placeholders.

[Rob_Brenner]

To answer your questions:

Questions
-do we have the ability to perform a incremental/differential with fsautility?

=> No, FSAUtility has a checkpointing feature which is designed to allow the tool to resume the processing from the point it stopped. I wouldn't say that the idea of incremental/differential jobs would be applicable to FSAUtility as the tool only performs the processing once for each item. Incremental/differential would apply to backups where a file may have changed since the last backup. 

-does the fsautility have to modify the placeholder and the ev database to migrate

=> The FSAUtility -pm option performs minimal database changes to reflect the new path where the ArchivePoint has been moved to, whereas FSAUtility -m perform major changes within the EV databases for each and every item so it takes much longer

-how do customers typically go about migrating these, is there mandatory (lengthy) outage window or are there tricks to doing it right?
 

=> Many customers have tried their own imaginative way to migrate PH due to lack of knowledge on the options available with FSAUtility and most have experienced difficulties. In order to avoid issues, follow the instructions provided in the Utilities.pdf

-if the ev server is just pointing to the celerra storage via a drive letter, does this migration become much easier?

=> It doesn't matter how the target Celerra CIFS volume is added - whether an Admin ($) or regular share. The process will be the same.

Is it just a matter of replicating the placeholders to a new drive letter and upon cutover, assign the old drive letter to the new storage?

=> This sort of creative thinking is what you should try to avoid because of the dependency the items will have with the records in the database, so the migration should be done with the appropriate tool provided with the product.