To understand Dynamic Storage Technology, we recommend starting with the following white paper:
Dynamic Storage Technology (DST) requires a primary and secondary volume. Typically, these volumes are set up as NSS volumes, but they can also be set up on another volume type (like Reiser) depending on your needs.The example below demonstrates creating both primary and secondary volumes as NSS volumes; however, it is more likely that you already have an NSS volume that can be used for either the primary or secondary volume. If this is newer storage that you are using to create the new volume, then you probably want to use it as your primary volume. If it is older storage then you may want to set it up as the secondary. It is really up to you.
The volumes will be created with iManager 2.7 which is installed with the OES 2 server. If iManager 2.7 was installed into an existing tree, then you may need a replica as well as a LUM-enabled admin (or admin equivalent) user in order to log in.
EXCLUDE_VOLUME <nss volume name>
If you will be using a backup utility with DST, you may need to add an NSS attribute that allows eDirectory trustee assignments to be backed up and restored. OES 2 has a switch that enables this capability. If the application in question does a listxattr to get all the extended attributes, then they will get the NSS netware.metadata attribute when you have the /ListXattrNWMetadata flag set. The linux cp command implements this as well as other tools. Test any third-party applications to be sure.
In this example, the Tivoli 5.4 Linux client is used in conjunction with the /ListXattrNWMetadata attribute to backup and restore trustee assignments. Without this attribute being set, the trustee assignments are not backed up by Tivoli and, therefore, are not restored.
To set the attribute, complete the following:
The only default policy with DST is to move files from the secondary file system to the primary file system when files are modified. This assumes an existing data store with both active and inactive data. The goal is to make the existing data store the shadow of the newly created data store. This way, the data is migrated as users access their files. Active files are moved instantly to the new data store (primary) and inactive files are left on the old data store (secondary). This also allows data migration to take place without taking a large initial hit on bandwidth. However, this method also takes more time because the data is only migrated as the user modifies files.
If you want to schedule a time for moving the data all at once, you can set up a policy or use the scan feature on the inventory page. The policy feature schedules the move for a given time; the scan feature moves data immediately.Both are explained briefly below.
Using the Inventory Scan Feature
Since the example we gave was to create two new volumes, we used the Novell Client to copy over the initial data. The Novell Client uses the virtual view so it sees files from both the DATA (primary) and ARCHIVE (secondary) volumes at the same time. Whenever anything is copied or saved using the Novell Client, it is always saved to the Primary volume. This gives us the opportunity to show how the Inventory Scan Feature can move files from one location to another.
For example, we can see that if we had a policy to move every file accessed in the last six months, we could reduce the backup interval tremendously because we would be backing up much less data. This means we could migrate everything less than six months old to the Primary partition and then create a policy to run this same migration at a given interval. Since our test data is on the primary, we want to migrate anything that is older than six months to the secondary volume (ARCHIVE). You can do this by migrating individual data sets by clicking on the file links in the chart, or by using the Inventory Scan Feature at the bottom of the Inventory page.
The previous section demonstrates the ability to move data using the Inventory Scan feature. In order to maintain that data migration, we need to create a policy. Or, if we couldn't use the Inventory Scan Feature due to the need to schedule down time, we could just set up the policy and let it take care of the migration.
You can create multiple policies and have them apply to a specific volume or all shadow volumes.
Introducing DST helps simplify the backup process. Rather than backing up all of the data all of the time, you can concentrate on backing up important data frequently and other data less often. But how do you restore that data when it is being backed up from multiple locations? Below are some possible suggestions for working with primary/secondary copies of with a virtual view, but you must first ask yourself some questions: