Enterprise Vault File Server Archiving is sometime a long-forgotten beast in the archiving world. There is a lot of information which is written about Exchange mailbox archiving, and journaling, and not nearly as much about FSA. There are many aspects of FSA though, that are worthy of mention, and in this article I'll explain some of the ways that you can do FSA migrations easily.
Migration horror stories
Most Enterprise Vault consultants whisper about horrific stories involving FSA migrations over the last few years, but let me tell you those years are long gone. FSA is a good, solid product, which is deployed by many Enterprise Vault customers. Some of those customers have email archiving too, some of them don't. Either way I think that FSA archiving involves a slightly different mind-set than the average 'Exchange archiving' administrator. It requires a slightly different thought process. To stat with you are usually talking very large individual files, as well as very large overall quantities of data to archive.
The horror stories of old usually involve migrations which have maybe gone wrong, or have taken 10 times the length of time that was predicted because of some unforeseen problem. The truth is that there are probably as many horror stories involving Exchange mailbox archiving, and it boils down to being prepared, and having a good knowledge of each of the tools which are available.
Lots of choices
So if you're ever called in to help a customer migrate some terabytes of data from one file server to another, there is no need to cringe, and start praying. It's actually not that difficult, and there is a variety of tools available which can help with typical migrations. I know that some people would argue that no migration is a 'typical migration', they're all unique, but really, there are many aspects of migrations which can be simplified and summarised.
One of the crucial things to decide on in the migration is where the source of the migration will be. Will it be the Enterprise Vault archive which houses the archived copy of data, or will it be a set of source file servers? If it's the latter of these then there are three tools which come to mind which will help with a migration. These tools will all have pro's and con's and will help in varying degrees in accomplishing a migration in a reasonable time frame.
The two usual tools which will spring to mind are FSAUtility, and Robocopy. Both of these are any FSA consultant or administrators long-time friends.
Using FSAUtility in my opinion hasn't ever really be a truly great experience. Being command line based does have some advantages in that you can script it if you need to, but it doesn't provide a very good level of feedback. It is though, the de-facto method for doing most things relating to migrations of archived items, and has several other features like being able to recreate shortcuts/placeholders, which is sometimes necessary.
Robocopy has been around the IT world forever, or so it seems. It fundamentally does a great job of copying data from A to B, via a command line interface. It has some great filtering capabilities including the option to copy offline files if needed (or exclude them, if that's needed)
Both of these though have some serious disadvantages in my opinion. The two mains ones are that they are hard to schedule, and it's hard to see the progress of the migration. This is where our tool, FSA Migrator, came in to existence, and it can help with several migration scenarios.
Using FSA Migrator
FSA Migrator is a graphical tool which can help with some types of migration. It uses the source file server as the source of it's information, so if you want to use the source archive as the source, then FSA Migrator can't currently assist you with that. This is really the reason behind thinking about, discussing, and deciding which will be the 'master' source of the file migration - archive or file server.
FSA Migrator builds up a picture of the source file server during a background scan, and then the migration of offline, and online files can take place on differing schedules, and with different amounts of load placed on the source file servers. It's even possible to re-ingest the data as it is migrated. This can be back in to the same Enterprise Vault environment or a new one.
All of this is wrapped up in a nice, easy-to-understand, user interface. It can be seen at a glance where the migration currently stands, and allows you to see how much of the online (non-archived) and offline (archived) data has already been migrated. Take a look at the screenshot below:
We've also done several rounds of testing and seen that FSA Migrator can be considerably faster than the 'bare' tools of FSA Utility and Robocopy.
Conclusion
It is no longer necessary to be worried when it comes to the prospect of migrating Enterprise Vault FSA data. There are several critical tools that you can add to your arsenal such as:
- Robocopy
- FSA Utility
- FSA Migrator
These can be used sometimes on their own, and sometimes in conjunction with each other, to perform almost any type of FSA migration. Provided the source of your migration is the source file server, it's possible to get a fantastic graphical user interface allowing simple and in-depth reporting to be performed when using the FSA Migrator from QUADROtech, and, it is also very fast in doing the migration.
How have you done FSA Migrations in the past? Which tools have proved invaluable to accomplish the migration? Let me know in the comments below.
