Forum Discussion

Retro_Kid's avatar
Retro_Kid
Level 3
7 years ago

Migrating A EV Enabled File Service - Would this work?

Hello everyone,

I have a Server 2003 File Server with EV FSA enabled, which i need to migrate off our network asap - like this weekend. It has become problematic, freezes during the day - not to mention of course being out of support.

We are currently using EV 11.0.1 - with v10 FSA Agent on the file server.

Researching in the past leads me to the following two step process:

1. Migrate the placeholders with fsautility -pm
2. Migrate the rest of the files with Robocopy

My concern here is the length of time to migrate over 561,498 files in one error free swoop.

Stumbling across Veritas Tech Note "TECH144810 - How to rename a file server that is archived by Enterprise Vault File System Archiving" gave me an idea.

I setup a test file server - called oldfileserver, copied some files, then added to EV and archived them so Placeholders were present. Then i setup another server, called newfileserver and followed the steps below to emulate a file server migration - and everything seemed to work correctly post move.

As i don't know the full intricate details of how exactly EV works especially with the SQL side, i was wondering if one of the experts could cast their eye over the following and advise if this would work before i apply it to a production environment.

I use VMWare and Veeam - which is why i was able to do it this way.

1. Backup the data drive (vmdk) of oldfileserver VM using Veeam
2. Restore the data drive (vmdk) of oldfileserver VM back into the folder containing newfileserver VM using Veeam
3. Add oldfileserver data drive (vmdk) as a disk to newfileserver using VMWare
4. Ensure this disk is now available in newfileserver by opening My Computer on newfileserver
5. Check number of files / folders / size on oldfileserver then check is idential on restored version on newfileserver.
6. Recreate shares on newfileserver to the approriate permissions & folders as per oldfileserver.
7. Shutdown oldfileserver

--- At this point migration complete - but EV still thinks files are on oldfileserver.

8. On EV Server Stop All Services
9. On SQL Server backup, backup the EnterpriseVaultDirectory Database

10. On SQL Server - Execute this query (as per Veritas Technote 144810):

USE EnterpriseVaultDirectory
UPDATE FileServerEntry
SET DnsName = 'newfileserver.fqdn.'
WHERE DnsName = 'oldfileserver.fqdn'

11. On SQL Server - Execute this query (as per Veritas Technote 144810):

USE EnterpriseVaultDirectory
UPDATE FileServerEntry
SET UncName = '\\newservernetbiosname'
WHERE UncName = '\\oldservernetbiosname'

12. On SQL Server - Execute this query (as per Veritas Technote 144810):

USE EnterpriseVaultDirectory
UPDATE ArchiveFolder
SET FolderPath = replace(cast (FolderPath as nvarchar (1000)),
'\\oldfileserver.fqdn\', '\\newfileserver.fqdn\')
WHERE FolderPath like '\\oldfileservernetbiosname%'

13. On SQL Server - Execute this query (as per Veritas Technote 144810):

USE EnterpriseVaultDirectory
UPDATE FSAArchivePointFolderPathChecksum
SET FolderPathChecksum = CHECKSUM(CAST(ArchiveFolder.FolderPath AS NVARCHAR(MAX)))
FROM FSAArchivePointFolderPathChecksum
INNER JOIN ArchiveFolder ON ArchiveFolder.RootIdentity = FSAArchivePointFolderPathChecksum.RootIdentity

14. Start All EV Services
15. Add newfileserver to EV.
16. Open EV Admin Console -> Site -> EV Servers -> Tasks > File System Archiving Task For newfileserver -> Properties - Synchroniation -> Synchronize (As per Technote 144810)

17. Change mapping of network drive letter from oldfileserver to newfileserver
18. Test

Migration complete.

To test this, i then opened Placeholders on multiple folders within newfileserver - all opened fine and then from EV server force restored all placeholders in test folders using the command fsautility -t -s \\newfileserver\path\to\folder -f

All placeholders replaced by the actual files - so i can restore from the file server and a machine connected via file share - and i can restore via EV server.

In my eyes - all looks well and good to go. Is there something obvious missing i have forgot which would perhaps come back and bite me once migration is complete and oldfileserver decomissioned?

Thanks in Advance
Colin.

 

 

 

  • Hi Colin,

    The preferred method would be to use FSAUtility, but understand this can take some time to process depending on the amount of data and such.  Your method will work and is typically something we have to do if the migration was not done properly.  For instance, building a new server and moving the LUN to the new server for the drive.  This would not update the DB, however recalls should work if the FSA agent is installed and configured properly.  The issue comes when trying to use FSAUtility or EVS as the DB still points to the old server. 

    The paths should remain the same if the target volume was a drive letter...E$ for instance.  If it was a share then it should not matter as the path will be \\server\share, but this should align so that only the server name needs to change using the article you mentioned.  

    I would suggest getting to the latest FSA agent 12.1.3 as there are some enhancements/fixes.  http://www.veritas.com/docs/000126189

    The agent can be found in the Veritas Enterprise Vault\Server\Release Update Files\%VAULT%\evpush\Agent  folder of the download.  

    There is also a fix coming for SMB issues in 12.2.1 due out later this year.  https://www.veritas.com/support/en_US/article.000125834

    In addition we hope to have a command that can perform this process, in the DB only, so it would not require manual SQL updates.  This is in the works and no ETA as yet.  

    Hope this helps. 

    Regards,

    Patrick 

2 Replies

  • Hi Colin,

    The preferred method would be to use FSAUtility, but understand this can take some time to process depending on the amount of data and such.  Your method will work and is typically something we have to do if the migration was not done properly.  For instance, building a new server and moving the LUN to the new server for the drive.  This would not update the DB, however recalls should work if the FSA agent is installed and configured properly.  The issue comes when trying to use FSAUtility or EVS as the DB still points to the old server. 

    The paths should remain the same if the target volume was a drive letter...E$ for instance.  If it was a share then it should not matter as the path will be \\server\share, but this should align so that only the server name needs to change using the article you mentioned.  

    I would suggest getting to the latest FSA agent 12.1.3 as there are some enhancements/fixes.  http://www.veritas.com/docs/000126189

    The agent can be found in the Veritas Enterprise Vault\Server\Release Update Files\%VAULT%\evpush\Agent  folder of the download.  

    There is also a fix coming for SMB issues in 12.2.1 due out later this year.  https://www.veritas.com/support/en_US/article.000125834

    In addition we hope to have a command that can perform this process, in the DB only, so it would not require manual SQL updates.  This is in the works and no ETA as yet.  

    Hope this helps. 

    Regards,

    Patrick 

    • Retro_Kid's avatar
      Retro_Kid
      Level 3

      Patrick - Many thanks for the confirmation.

      Most appreciated. Feel a bit more happier now attempting production server on Sunday.

      Fingers crossed :-)

      Colin.