Dell NetWorker 19.9 Administration Guide

Modifying the browse and retention policy on a save set

Starting from NetWorker 9.x the browse period is equal to retention period for save set life cycle management within Index database and Media database respectively. This change restricts the index to be purged from client file indexes until save set retention period is over and save set is eligible for recycle. If the Index database grows, this might add an additional overhead on NetWorker server. This is seen in data sets such as, high dense file system or NDMP backup. To eliminate this issue, NetWorker removes this restriction partially by providing a CLI capability to separate the browse period from the retention period.

Use the nsrmm command to modify the browse and retention policy of a save set after the backup has occurred.

When the retention value of a save set is changed, nsrmm only updates the media database record and not the save set metadata on the media. When a volume is scanned to re-create save set records in media database using scanner, the retention values of save sets on that volume is different from the updated retention time using nsrmm. The new retention time is based on the retention information in the save set metadata on the media. For information about the new retention time for scanned save sets, see the NetWorker Command Reference Guide or UNIX man pages.

Use nsrmm command with the following options:

• -e retention_time- Updates retention time
• -w browse_time- Updates browse time

Use the -e and -w options with the nsrmm option -S to specify a save set ID.

Both the browse and the retention policies must be entered in date and time formats, accepted by the nsr_getdate program. The UNIX man page and the NetWorker Command Reference Guide provides detailed information about the nsrmm and nsr_getdate commands.

This CLI capability brings the feature at par with NetWorker 8.x. However, the feature is only implemented using the CLI in NetWorker 19.3 and later. If any clone or stage operation is being run with higher retention than primary copy, then retention and browse period would be recalculated as per the current behavior of NetWorker 19.3 or later, which can then be modified using nsrmm (post clone or stage operation). NetWorker also recalculates the save set retention and browse period based on highest clone retention copy. That is, if any cloned save set created or updated with different clone retention period greater than the original backup copy, then the overall retention is recalculated and is reverted to browse equal to retention period. This recalculation of retention and browse period is done by nsrmmdbd daemon. In such cases, use the nsrmm CLI option to revert the browse period to required value. The following are the examples of browse time being recalculated based on the clone retention period.

For example, a user has taken the backup and created a clone copy with some retention value (three years). Later the user might change clone copy retention higher than the backup copy (clone retention of five years), then browse and retention period would get recalculated based on the clone retention. In such cases, user can revert the browse period again back to three years using nsrmm CLI.