Use the guidelines in this section when planning your snapshot solution:
For NSS on Linux, snapshot volumes are not automatically mounted on reboot as they are in NetWare. The snapshots are active and performing their snapshot functions, but they are not mounted. If a snapshot was mounted when the server went down and you want the snapshot mounted after reboot, you must mount it manually. Mounting a snapshot is necessary only if users require access to the point-in-time version of the data.
In NSSMU, devices that contain NSS pool snapshots cannot be re-initialized. To initialize the device, you must first delete all NSS pool snapshots on the device. For information about deleting snapshots, see Section 18.11, Deleting a Pool Snapshot using NSSMU or iManager.
Table 18-1 identifies the differences for using snapshots for NSS pools on Linux and NetWare:
Table 18-1 Comparison of NSS Pool Snapshots on Linux and NetWare
|
Capability |
NetWare |
Linux |
|---|---|---|
|
Rename a snapshot |
Supported |
Not supported. If you attempt to rename a snapshot, you get an eDirectory error because eDirectory objects are not automatically created for pool snapshots. |
|
Snapshot stored-on location |
An NSS pool is designated as the stored-on partition for a given original pool. |
An NLVM-managed Linux partition is designated as the stored-on partition for a given original pool. |
|
Snapshots of cluster-enabled pools |
Supported The stored-on partition must be the same as the original pool. |
Not supported |
|
eDirectory object for the snapshot |
eDirectory objects are automatically created for the snapshot pools and volumes. |
No eDirectory objects are created. In order to allow users to access data on an NSS pool snapshot, you must first activate and mount the snapshot as an NSS pool, then use the Update eDirectory option on the Storage > Pools page to create an eDirectory object for the snapshot pool or volume. |
|
Taking new snapshots |
The stored-on partition must be activated and mounted. |
The stored-on Linux partition must be mounted. |
|
Deleting snapshots |
Delete pool snapshots in a first-created, first-deleted order. |
Snapshots can be deleted in any sequence. |
|
Shredding deleted snapshots |
Supported |
Not supported |
Create a pool snapshot when you want to capture a point-in-time view of a active data pool. The original pool must be active when you create the snapshot. For instructions on creating a pool snapshot, see Creating a New Pool Snapshot using NSSMU or iManager.
Pool snapshots are not supported for clustered NSS pools on Linux.
You name a pool snapshot at the time you order the snapshot. Specify a unique name for each snapshot. Because the name also serves as the snapshot’s poolname when active, the name you give it should be unique among snapshots and among pools. The combination of the snapshot’s name and time stamp when the snapshot was taken can help you identify the snapshot version you want to manage.
When you create a snapshot in iManager, the snapshot name is by default a modified version of the original pool’s name, which allows a simple identification of all snapshots for any given pool. NSS adds a letter and number designator (_Sn) to the original pool name. The S indicates that it is a snapshot. The n represents an incremental number (1 to 500) of snapshots taken for this pool.
IMPORTANT:When you create a snapshot in NSSMU, no default name is suggested. You can optionally adopt the default naming scheme when you provide a name for the pool snapshot.
For example, pool snapshot names for POOLA might be POOLA_S1, POOLA_S2, and so on.
If you delete snapshots out of sequence, it is possible that the numbers could be reused. A simple sort by snapshot name could be confusing. Make sure to verify the create stamp on the pool when you work with pool snapshots that use the default naming scheme.
The snapshot name can be 2 to 16 characters in length and must adhere to the same character conventions as for poolnames. If the poolname is too long to allow the snapshot identifier to be appended, the poolname is truncated so that the length of the pool snapshot name is 16 characters. For example, if the poolname is POOL_EUR_MANUF (14 characters), its name would be truncated then the snapshot identifier appended. The number of characters to be truncated would depend upon the pool snapshot number, such as POOL_EUR_MANU_S1, POOL_EUR_MAN_S12, or POOL_EUR_MA_S102
If you bring a pool snapshot online, its volume names are automatically renamed to indicate that they are snapshot volumes. By default, _SV is added to volume names to indicate the storage object is a volume in a pool snapshot.
For example, if your original pool is named users, its default pool snapshot name is users_s1. If its volumes are named users_aj and users_ kz, the volumes in the snapshot pool are users_aj_sv, users_aj_sv001 and users_kz_sv, users_kz_sv001 and so on.
You can optionally adopt your own naming convention for pools. If you create multiple snapshots of a pool each day, consider using a logical naming convention that identifies the poolname and numbers that allow sequential listing based on the order the snaps were taken. Of course, the time stamp shows the exact time that the snapshot was taken, and you can always refer to it to be sure you have the right snapshot.
It is also important to consider the names of existing pools and pool snapshots and your naming conventions when you name new data pools and volumes. You should get errors if you attempt to create pools with names that are in use by pool snapshots, and vice versa.
If a volume with the same name as a snapshot volume exists on the server when you mount a snapshot pool, NSS automatically appends the snapshot volume name with an additional sequential number (such as VOL1_SV001) or characters (such as VOL1_SV_SV) as it onlines the volume. This makes the snapshot name unique with respect to the active volumes while the pool snapshot is online.
If name conflicts occur, you might need to rename a pool or pool snapshot to a unique name in order to bring the pool snapshot online.
Each snapshot that you create for a pool needs its own stored-on partition. Specify an NLVM-managed device where you want to create the snapshot partition. Each snapshot partition must have the same shared state as the original pool being snapshot.
IMPORTANT:Creating snapshots of clustered NSS pools is not supported.
Snapshots are not supported on RAID1 devices.
When you create a pool’s snapshot, you select the device and specify the size to use. You cannot increase the size of the partition later, so make sure you allow sufficient space.
Each snapshot grows as more blocks are changed on the original pool. Theoretically, if all of the original blocks changed, each snapshot's stored-on partition would need to be as big as the original pool. Typically, the disk space needed for each pool snapshot is 10 to 20 percent of the original pool size. The amount of space required depends on the snapshot retention policy and the turnover rate for data in the original pool. A snapshot should never be allowed to completely fill its stored-on partition. If a snapshot's stored-on partition runs out of space, the copy-on-write blocks cannot be written to it, and write errors occur on the original pool. Allow ample space for the snapshot to grow over time when you specify a size for the snapshot’s stored-on partition.
The status of any given pool snapshot partition is closely tied to the operational status of the original pool. You can deactivate the original pool, as needed, without adversely impacting the pool snapshot or the status of the stored-on partition. If the original pool is deactive, there are no active transactions for the pool snapshot function to process. For Linux, the stored-on partition hosts only a single snapshot, so it can be safely deactivated after you deactivate its original pool. Make sure that you re-activate the stored-on partition first when bringing the original pool back into service.
In contrast, deactivating the stored-on partition first can cause the ungraceful deactivation of the corresponding original pool.
IMPORTANT:The stored-on partition should remain active as long as it hosts any pool snapshots. You can deactivate it safely after its original pool is deactivated, and for the duration of the pool’s deactivation. Activate the stored-on partition before re-activating the original pool.
For pool snapshots, Online and Offline are conditions related to the visibility of the pool snapshot to users. The pool snapshot is offline by default. The snapshot functions are working in the background to capture any changes being made to the original pool whether the pool is offline or online.
You activate a pool snapshot as a pool by bringing it online whenever you want to access the data on it, such as for data retrieval and data backup. After the pool snapshot is online, it appears by its snapshot name in the pool list. Treat it as you would any pool to activate and mount its volumes. Because you are working with a snapshot and not the original pool and its volumes, other management tasks are limited.
The names of volumes on the pool snapshot are a modified version of the volumes on the original pool. By default, the characters _SV (snapshot volume) are appended to the volumes’ names. When you deactivate the pool snapshot, the corresponding snapshot volumes are automatically deactivated, and the pool snapshot is no longer listed in the pool list.
The Pool object and Volume object for a snapshot are not automatically created in NetIQ eDirectory when you bring an NSS volume snapshot online. These objects are needed only if you want to verify the NSS metadata information on a snapshot volume. For this case, you must create the objects manually by using the Update eDirectory option to create the storage objects for the online snapshot NSS pool and each of its volumes. For information, see Section 16.7, Updating eDirectory Pool Objects with NSSMU and iManager and Section 19.4.3, Updating eDirectory Volume Objects using iManager.
If you reboot the server while a pool snapshot is online, the snapshot might be online or offline after the restart, depending on the platform. If the pool snapshot is online when the server goes down, the pool snapshot is automatically set in the Offline state after a reboot.
For instructions, see Section 18.8, Onlining or Offlining a Pool Snapshot using NSSMU or iManager.
Delete pool snapshots as follows:
Delete all pool snapshots before you move devices that contain the original pool from NetWare to Linux. Different technologies are used for pool snapshots on Linux and NetWare, so existing pool snapshots cannot be used on a different platform.
WARNING:Without first deleting the pool’s snapshots, you might not be able to access or manage the original pool after you move the pool’s device cross-platform.
Delete a pool snapshot when you no longer need it.
Delete a pool snapshot when you need free space on the device where the stored-on partition exists.
Make sure that the pool snapshot is not mounted as an online pool before you delete it.
Snapshots can be deleted in any sequence.
For instructions, see Section 18.11, Deleting a Pool Snapshot using NSSMU or iManager.