File System Archiving in Enterprise Vault v9: Placeholder Migration
Over the coming weeks I'm going to be writing a series of blogs detailing the enhancements to Enterprise Vault File System Archiving in v9. While these may not be big headline grabbing features, I think our existing customers will find them extremely valuable and beneficial. After all, the enhancements that we have delivered for FSA in v9 have all been directly driven by customer requests and feedback.
I'm going to start off by talking about placeholder migration. Once you have deployed FSA, the ability to easily manage the archived content and to be able to move placeholders around (without recall) for things like hardware refreshes or share re-organisations is key. Now some of you may be thinking that doesn't FSAUtility already have the ability to move placeholders? The answer is yes it does, but it has specific use cases associated with it, which are not appropriate for some of the more common migration tasks.
Let me explain more. The exiting FSAUtility -m option will move placeholders from one volume to another, from one server to another server or even across disparate platforms (e.g. Windows to NetApp) but it assumes that the source and target destinations are both being managed by different Enterprise Vault servers. What this means is that along with moving the placeholders, we also move the underlying archived files in the backend. So all archived files are exported from the source archive and imported in to a new archive on the destination.
What this means is that the speed of the migration is determined by the size of the archived files within Enterprise Vault, not by the number of placeholders on the file system. You need to use this when your destination file server is being managed by a different Enterprise Vault server to that of the source file server. But what if the source and destination file servers are both being managed by the same Enterprise Vault server?
FSAUtility -m can still be used in this scenario, but your migration times are going to be long. You asked the question to us about why do you have to move the backend data if it does not have to move across Enterprise Vault servers? It's a very good question and now with the FSAUtility -pm option you no longer have to move the backend data.
So, providing source and destination file servers (and they can be disparate devices) are being managed by the same Enterprise Vault server you can use -pm for the migration. Here the time to complete will be determined by the number of placeholders on the volume not by the size of the archived files they point to. This will mean you have a highly performant placeholder migration tool. Often you have to do server migrations, volume re-organisations etc. in small maintenance time-windows. You now have the tools from us to help you succeed in those migrations.
FSAUtility will still only move the placeholders whether you use the old -m or the new -pm option. We recommend using something like robocopy for the non-archived files. Robocopy is a great tool for this as it has the /XA:O option which allows it to skip files with the offline attribute set i.e. our placeholders.
FSAUtility -pm will move whole archive points (archives) from one volume to another, including all placeholders below the archive point. If you want to move part of an archive point you will need to use -m as you are effectively splitting an archive.
In our labs we have seen a very encouraging number of placeholders be migrated per hour. I would be interested in hearing your experiences with the new -pm option and the type of migration throughputs you are getting in your environments.
For more information on how to use FSAUtility, check out the 'Utilities' guide in the documentation folder of the v9 kit.
Over the coming weeks I will be giving more details on the following enhancements for FSA in v9:
- FSAUtility: bulk recall
- FSAUndelete tool
- FSA Reporting performance and scaleability improvements
- FSA Checkpointing improvements
So keep coming back for those or subscribe to the RSS feed. I would also be interested in hearing what other topics around FSA you would like us to blog about.