|
|
Volumes that belong to a clone pool are also tracked through volume entries in the
media database. The fact that all save sets share the same media database save set
entry has implications for the following actions, which are executed on a "per save
set basis" and not on a "per volume" basis:
*Changing the mode of a cloned volume (of save sets)
*Purging a volume (of save sets) from the client file index
*Deleting a volume (of save set locations) from the media database
Caution - If you manually change the mode of a cloned volume to recycwith the
intent of reusing a particular clone volume, be aware that the mode of a volume only
changes to recyclable when all the save sets on that volume are recyclable. Therefore,
when the mode of the volume changes to recyc, you effectively change the status of all
save sets on the clone volume to recyc. Because the save sets share the same entry in
the media database, there is no distinction between "original" and "clone" save sets.
The end result is that all the save sets that reside on the now recyclable volume or on any
other volumebecome candidates for immediate recycling.
To prevent inadvertent loss of data, if you want to reuse a particular clone volume
and still protect the instances of a save set that exist on other volumes, first change
the mode of the volumes to be protected to man_recyc. This means that Backup
cannot automatically recycle the volume. Then, you can safely change the volume
that you intend for reuse to mode recyc.
Similarly, if you purge a clone volume, you effectively remove from the client file
index all file entries associated with all save sets that reside (in whole or in part) on
the particular clone volume.
If you delete a clone volume, the nsrimindex management program locates the
entry in the media database for each save set that resides on the clone volume. From
the entry, the nsrimprogram marks for deletion the information about the location
of one of the save set clones from the entry. This action is performed for each save
set entry. In addition, nsrimmarks the entry for the particular clone volume
(identified by its volume ID number) for deletion from the database.
|
|
|
|
|
In general, a volume write that occurs as part of a backup operation and a volume
write that occurs as part of a cloning operation proceed at the same speed. However,
if a clone operation is automatically requested as part of a scheduled backup, you
may experience a performance degradation in other scheduled backups that follow.
Backup generally attempts to complete one group's scheduled backup before a
scheduled backup is initiated for another group. However, Backup considers that a
group backup is finished when the backup operations are complete, not when any
automatic cloning is complete. Therefore, if another group starts its backup while
|
|
|
|
