1.3.1 Existing Volume as Primary with an Empty Volume as Secondary

In this scenario, all data currently exists on an NSS volume that you want to make the primary volume. You create a new volume to use as the secondary storage, then define a shadow volume for the two NSS volumes.

The volume contains information that is seldom used and rarely changes, and you want to move the seldom-used data to a location where it can be accessed but backed up less frequently. This decreases the time it takes to back up or restore the data you use the most.

Then, you can configure a policy that governs what data moves to the secondary storage area. Data is returned to the primary area based on a policy of usage or file type. For example, if the user simply views the data in a file, then the data does not move. If the user modifies the file, then the file is moved back to the primary volume. Users are not aware of where the data are physically stored because they see a merged view of both volumes.

1.3.2 Empty Volume as Primary with an Existing Volume as Secondary

You have an existing volume on older storage and want to move the data to new storage arrays. You create a new volume on a storage device in a Fibre Channel SAN solution. You define a shadow volume that uses the empty device as the primary area, and the existing volume as the secondary area.

You can configure a policy so that the data moves to the primary volume based upon usage. Data gradually flows to the primary volume as it is used. In this way, there is a natural background migration of data from the existing volume to the new volume. The new volume gradually grows, and the relationship between the primary and shadow volume is as if the primary had been populated first.

For example, suppose you have an existing pool that spans multiple LUNs, and contains multiple volumes. The current best practice is to use a separate LUN for each pool, and a single volume per pool. You create a new pool on a new larger LUN (or fewer larger LUNs), then create a single NSS volume in the pool. You might need to rename the old and new NSS volumes if users need to access the data via known paths, because after the shadow volume is created, users access data via the new volume. Repeat this process so that you have one new empty volume for each of the old volumes on the pool. As the new and old volumes are ready, you create a DST shadow volume with the new volume as the primary storage area and an existing volume from the old pool as the secondary storage area.

To begin de-migrating the data, configure the global policies to shift data from the secondary storage area to the primary storage area whenever they are accessed or modified. You can also configure individual shadow volume policies or use inventory reports to shift data on schedule or on-demand based on age, file names, file types, or file size. De-migration occurs with the storage online and accessible to end users; they are not aware of where the data is actually stored.When you have moved all the data from the old NSS volume to the new one, you can remove the shadow volume, then delete the empty old NSS volume from the old pool. When the old pool has had all its volumes deleted, you can delete the old pool, which frees that storage for use in other volumes. Users are not aware that the volumes are on a new pool. They see only the volume by its name.