Understanding disaster recovery and data migration

Similarities between disaster recovery and data migration

Although the reasons for preparing a disaster-recovery vfiler are quite different from the reasons for moving or migrating a vfiler, many of the tasks involved are similar. In both cases you need to take inventory of the source vfiler and make sure the destination filer has the storage capacity and characteristics, and the network connectivity, to host what will be as nearly as possible an exact copy of the original vfiler. Then in both cases you use a small set of vfiler commands to actually create the new vfiler, populate it with the original vfiler's data, and prepare its connections to the network.

What the procedures do and do not cover

In both cases, the procedures that follow help you not only to move or copy the data (via SnapMirror), but also to configure all of the networking needed to serve the data. But they do not cover adjustments on the client side (for example, mounts onto a Solaris or Windows host). You will need to work closely with the administrators of those systems and with your network administrator to make those adjustments.

Note
A SnapMirror license is required on both the source and destination filers.

Differences between disaster-recovery and data migration

After the new vfiler has been created, the states of the source and destination vfilers depend on how you will use the new vfiler.

If you are preparing a disaster-recovery vfiler:
- The original (source) vfiler remains intact and continues to serve data to its clients.
- The new (destination) vfiler is inactive, and its IP addresses remain unconfigured, until you activate it in the case of a disaster that destroys or incapacitates the original vfiler.
If you are moving (migrating) a vfiler:
- The original (source) vfiler is destroyed after the migration is complete.
- The new (destination) vfiler becomes active and begins serving data as soon as the migration is complete.