Use the guidelines in this section when planning your snapshot solution:
Section 18.2.1, Differences Between Snapshots on Linux and NetWare
Section 18.2.3, Guidelines for Creating Pool Snapshots of Clustered Pools
Section 18.2.5, Guidelines for Choosing the Stored-On Location
Section 18.2.6, Guidelines for Maintaining the Stored-On Location
Section 18.2.9, Guidelines for Viewing a List of Snapshots that are Stored in a Pool (NetWare)
Section 18.2.10, Guidelines for Shredding Deleted Snapshots (NetWare)
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.
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
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. On NetWare, the stored-on pool must also be active when you make the snapshot. For instructions on creating a pool snapshot, see Creating a New Pool Snapshot.
Pool snapshots are supported for clustered NSS pools on NetWare.
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 poolname. 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.
The stored-on partition is the partition on an EVMS-managed device where you want to store a given pool snapshot for a given original pool.
IMPORTANT:On Linux, creating snapshots of clustered NSS pools is not supported.
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.
If the destination partition that stores the snapshot data runs out of space, it causes write errors to happen on the original pool. Allow ample space for snapshots to grow over time when sizing the snapshot’s destination pool. The amount of space required depends on the number of snapshots, the snapshot retention policy, and the turnover rate for data in the original pool.
The stored-on pool is the active data pool where you want to store the pool snapshots for a given original pool. As noted previously, a combination of up to 500 snapshots can exist on any given stored-on pool.
When you create a pool’s first snapshot, you select the stored-on pool for the first and any subsequent snapshots. Typically, you can select the pool itself or a different pool to be the stored-on pool, given that the pool you choose is active and has sufficient space available. There are two exceptions:
If the original pool is a shared pool, you must select the original pool as the stored-on pool, and this pool must be active and have sufficient space available.
If the original pool is a non-shared pool, you cannot select a shared pool as the stored-on pool.
In general, you can achieve better performance by selecting a data pool located on a different disk than the pool you want to snapshot.
When creating your first NSS pool-level snapshot for a pool, we highly recommend that the destination pool specified for the snapshot data is different than the original pool you are snapshotting. The exception to this is clustering, where the destination pool for the snapshot data must be the same as the original pool.
If the destination pool that stores the snapshot data runs out of space, it causes write errors to happen on the pools being snapshot. Allow ample space for snapshots to grow over time when sizing the snapshot’s destination pool. The amount of space required depends on the number of snapshots, the snapshot retention policy, and the turnover rate for data in the original pool.
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 the 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.
If the stored-on pool and the original pool are the same, the status of any given pool snapshot is closely tied to the operational status of the pool. However, if they are not the same, you need to consider how the status of each pool affects the other, and how they affect the status of the pool snapshot.
You can deactivate the original pool, as needed, without adversely impacting the pool snapshot or the status of the stored-on pool. If the original pool is deactive, there are no active transactions for the pool snapshot function to process. If the stored-on pool hosts only the snapshots made for that deactivated original pool, it can be safely deactivated for the duration. Re-activate the stored-on pool first when bringing the pools back into service.
IMPORTANT:If you need to deactivate a stored-on pool, you must first deactivate each of the original pools that correspond to the families of pool snapshots stored on it.
In contrast, deactivating the stored-on pool first can cause the ungraceful deactivation of the corresponding original pool.
IMPORTANT:The stored-on pool should remain active as long as it hosts any pool snapshots. You can deactivate it safely only after all original pools are deactivated, and for the duration of their deactivation. Activate the stored-on pool before re-activating any of the original pools.
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.
For NSS on NetWare, when you bring the pool snapshot online, the Pool object and Volume objects are automatically created. They are automatically deleted when you bring the pool snapshot offline again.
For NSS on Linux, the Pool object and Volume object for a snapshot are not automatically created in Novell 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 option to create the storage objects for the online snapshot NSS pool and each of its volumes. For information, see Section 16.13, Updating eDirectory Pool Objects and Section 19.5, Updating eDirectory Volume Objects.
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. On NetWare, if the pool snapshot is online when the server goes down, the pool snapshot is automatically set in the Online state on restart. On Linux, 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.
Delete pool snapshots as follows:
Delete all pool snapshots before you move devices that contain the original pool cross-platform. 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.
On NetWare, delete a pool snapshot when you need to free space in the stored-on pool.
On Linux, 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.
For NetWare, delete pool-level snapshots in a first-created, first-deleted order, deleting the oldest snapshot of the pool first. For Linux, snapshots can be deleted in any sequence.
For instructions, see Section 18.11, Deleting a Pool Snapshot.
If the original pool and the stored-on pool are the same pool, you can view a list of snapshots stored on the pool by viewing the pool's Pool page. However, a stored-on pool does not show snapshots that it contains from other pools. If you want to be able to know which snapshots are stored on a stored-on pool, we recommend the following best practices:
Specify the original pool as the stored-on pool. This is mandatory for clustered pools.
If you want to use a different pool to store snapshots, use a given pool as the stored-on pool for only a single original pool at a time. Don't mix snapshots from multiple original pools in a single stored-on pool.
When you create a stored-on pool to use for snapshots, name it similarly to the original pool so that you know the association by the naming convention.
In NetWare 6.5 SP3 and later, when a snapshot is deleted, Media Manager automatically zeroes out all the blocks that it used. If the system goes down during the delete, the zeroing process does not continue after the system restarts. Some nonzeroed data blocks might remain.
If it is important that all snapped data be removed from the system, you can turn on snapshot shredding. If shredding is enabled, the delete process zeroes out the data, and then starts shredding the blocks where data was stored. If the system goes down during the delete, the zeroing process does not continue after the system restarts, but the shredding automatically continues after the system restarts. For instructions, see Section 18.12, Shredding a Deleted Pool Snapshot (NetWare).
IMPORTANT:Data shredding is not supported for pool snapshots on Linux.