This section discusses the following topics:
Create a pool snapshot when you want to capture a point-in-time view of a active data pool Both the original pool and the stored-on pool must be active when you make the snapshot. For instructions on creating a pool snapshot, see Creating a New Pool Snapshot.
You name a pool snapshot at the time you order the snap. Specify a unique name for each snapshot. Because the name also serves as the snapshot’s pool name when active, the name you give it should be unique among snapshots and among pools. The combination of snapshot name and time stamp when the snapshot was taken can help you identify the version of a data pool you want to access when a pool snapshot is active.
We recommend that you apply a naming convention for snaps. This is particularly important if you plan to create a series of snapshots for multiple pools. The snapshot name is generally a modified version of the original pool’s name to support easy identification of all snapshots for any given pool.
IMPORTANT:The snapshot name can be 2 to 16 characters.
For example, by default, NSS adds a letter and number designator to the original pool name, such as “_S n”. The “S” indicates that it is a snap. The “ n” represents an incremental number of snapshots taken for this pool. In this scenario, snapshot names might be PoolA_S1, PoolA_S2, and so on for snapshots of PoolA. If you delete older snapshots and reuse the lower sequence numbers, a simple sort by snapshot name can be confusing. Be sure to verify the time stamp on the pool when you work with pools that conform to this naming convention.
For some scenarios, it might be desirable to adopt more meaningful and sortable naming conventions. Currently, you can sort by snapshot name only, not by time stamp. If you create multiple snapshots of a pool each day, consider using a logical naming convention that identifies both the pool name and a combination of the date and an approximate 24-hour-clock time of the snap. For example, use a modified version of the pool name and add “_S ddtttt”. Snapshot names for PoolA might be PoolA_S300600, PoolA_S301800, PA_S310600, PA_S311800, and so on. Of course, the time stamp shows the exact time that the snapshot was taken, because there is a slight delay between ordering a snapshot and the instant of the snapshot itself.
It is also important to consider the names of existing pool snapshots and your snap-naming conventions when you name new data pools. If an active data pool and a deactive pool snapshot share the same name, a conflict occurs when you try to activate a pool snapshot or another regular pool with the same name. To resolve the conflict, the Media Manager dynamically modifies the snapshot name with an _ n (sequential number). This makes the snapshot name unique with respect to the active pool list during the time that the pool snapshot is active and functioning as a pool.
The stored-on pool is the active data pool where you want to store the pool snapshot. All pool snapshots for any given original pool must reside on the same stored-on 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 snap.
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 source pool you are snapshotting. The exception to this is clustering, where the destination pool for the snapshot data must be the same as the source pool you are snapshotting.
If the destination pool that stores the snapshot data runs out of space, it causes write errors to happen on the pool(s) being snapshot. Please 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 source 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. Each pool snapshot must be able to dynamically expand its storage footprint in the stored-on pool, because its metadata grows in response to changes in the original pool. Dynamic allocation is not possible when its stored-on pool is deactive. For brief outages, it is possible that any given pool snapshot residing in that stored-on pool has sufficient space available to accept new metadata, depending on the frequency of writes to its corresponding original pool. However, if you deactivate a stored-on pool, it increases the likelihood that one of the pool snapshots it hosts will run out of space. This causes 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.
You activate a pool snapshot whenever you want to access the data on it, such as for data retrieval, data modification, and data backup. After the pool snapshot is active, it appears by its user-assigned snapshot name in the pool list. Treat it as you would any pool to manage the pool and to activate and mount its volumes.
The names of volumes on the pool snapshot are a modified version of the volumes on the original pool. Generally, an “ _SV” (snapshot volume) is added to the volumes’ names. When you deactivate the pool snapshot, any snapshot volumes on it are automatically deactivated, and its snapshot name is no longer listed in the pool list.
You delete a pool snapshot when you no longer need it, or if you want to make room to add other snapshots to its stored-on pool. If you create a pool snapshot and specify its stored-on pool as the same pool where its original data resides, and more than one pool snapshot exists when you are ready to delete a snapshot, delete its oldest snapshot in a first created, first deleted sequence.
IMPORTANT:Delete pool-level snapshots in a first-created, first deleted manner, deleting the oldest snapshot of the pool first.
Users can access the snapshot for reads and writes when the snapshot is activated as a pool, just as they would any pool. Because any given pool snapshot can rotate into an archived status or be deleted, you need to be aware if the snapshot is in use before you delete it.
In NetWare 6.5 SP3 and later, when a snapshot is deleted, Media Manager automatically zeroes out all the blocks that it used. It no longer turns on shredding for the internal volume when creating a snapshot. You can apply the system shredding feature to a snapshot pool by entering
mm snap shred snapname = on
Replace snapname with the unique name of the pool snapshot. Shredding occurs only in the internal volume of the pool where you are storing the snapshot.
If you turn on snapshot shredding for a snapshot, you can have only one snapshot at a time for its original pool. When you delete the snapshot, do not create another snapshot until the system has had enough time to complete the shredding process. Depending on the size of the snap, allow more time for larger amounts of data to shred. The typical delay time is a few minutes.
If any pool snapshot was created on this pool prior to the NetWare 6.5 SP3 release, shredding is already turned on. You can turn shredding off by entering
mm snap shred snapname = off
Replace snapname with the unique name of the pool snapshot. Shredding is turned off only in the internal volume of the pool where you are storing the snapshot. It does not affect other snapshots.
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 shredding, with the limitations as noted above.
If shredding is turned on, 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.