Moonwalk is a Data Management System that can automatically move data from primary storage locations to lower cost file systems, including cloud storage services. When these files are required again by users or applications, they are automatically moved back to primary storage. If a recalled file was not updated, there is a 'Quick-Remigrate' facility to mark these files as migrated again, without requiring any data transfer.
Moonwalk can also copy and move files, and provides Disaster Recovery functionality.
Moonwalk uses a central AdminCenter which contains the migration policies, and is also used for scheduling and reporting. There is no central catalog for migrated data. Once data is copied off to secondary storage, the original file is shrunk down to a zero size stub file. This stub file remains on central storage and appears as a normal file on directory listings. The stub file contains the information required to find the original migrated data, should it be needed again.
Moonwalk Agents are installed on the managed servers, and they perform the migrate operations as dictated by the rules contained in the AdminCenter Policies. The Agents also perform the file retrieve operations from secondary storage if a migrated file is required again.
Agents can also be installed in a Gateway configuration, either on a stand-alone server, or on the AdminCenter server. Gateway agents are used to extend Moonwalk capabilities to third-party protocols and special devices.
Other, specialied Moonwalk components are the FPolicy Server which provides migration support for NetApp filers, and the Moonwalk DrTool, an application that assists in Disaster Recovery scenarios.
The first task is to install the Moonwalk Admin Tools package, which consists of the AdminCenter and the DrTool application. Admin Tools must be installed first, and the process is simply to run Moonwalk Admin Tools.exe, then follow the dialog.
Next, install Moonwalk Agents on all the fileservers on which data will be managed directly. Different server types have different instrunctions, so check the Moonwalk documentation for the exact process. These agents fulfill the 'Fileserver Agent for migration' role, where the agent assists the operating system to migrate and demigrate files. This role is selected at installation time, and these agents must be installed on all machines from which files will be migrated.
You can also defile 'Gateway Agents', where the role is to provide access to external devices and storage services. These agents do not provide local migration source support.
Now you use the AdminCenter to define the rules and polices that drive migration. A brief outline of the process goes like this:
Moonwalk recommends that you do not use bare IP addresses to identify sources and targets, but rather use Fully Qualified Domain Names (FQDNs). Migrated data can have a long lifespan and must be able to cope with changes to servers and server consolidation. For this reason, you might even want to create DNS aliases for each departments data, even where these share a server, as a department might be relocated at a later date.
Moonwalk provides a number of Policies, or maintenance tasks to assist with ongoing operations. Some of these are:
A file system analysis tool that analyses storage by data profile, and recommends areas where HSM could be effective. Some of the areas that are identified include: old files, infrequently used files and large files. The tool will also identify suspect or prohibited files that could be candidates for deletion.
A Scrub Destination Operation that is used to clean up migrate files that are nolonger required. You need to run this policy frequently to reclaim backend space. This policy needs to cater for any restore of backend data, so data is not lost, see below.
There are two kinds of scrub, agressive and non-aggressive. An agressive scrub will remove data that will never be used, and also data that is not accessible but could be reused during a quick-remigrate. A non-aggressive scrub only removes data that will definitely never be used.
A Post-Restore Revalidate Operation that is used after a restore has been run on the primary data. It scans all the stubs files and revalidates the relationship between them and the corresponding files on secondary storage. You must ensure that your backup and restore product can backup stub files and also restore them.
When you run Scrub policies, set a Scrub grace period that ensures backend files are not deleted in between the time frame between a backup and a restore, including the time needed for the Post-Restore Revalidation.
For example, suppose you run a nightly backup, and would never recover an entire server or directory beyond the latest backup. Your grace period would need to be 24 hours plus, and 48 hours would not be unreasonable to ensure that stub files can be validated correctly.
A Demigrate policy can be used if you need to do bulk restores, say to recall hundreds of migrated files for a month end operation.