Views |
||||||||||||||
What changes have been made at version 6 relating to retention and browse policies?
The exception to this was when the expiry date was set using the "-e" parameter to the save command. The effect of this was to write a value into a field for the save set in the media database. This value was fixed and the save set would not become recyclable until the expiry time arrived. Additionally in this case, the browse time would be the same as the expiry time, not always a good thing because file indices may have to be kept for a long time, taking up disk space unnecessarily. The "-e" parameter also applied to the savegrp command, but of course it was the save command doing the work, savegrp merely passed the intruction on to the save command. Not using a "-e" parameter (default) caused the expiry field to be undefined. From version 6.0 onwards, there have been many changes in this area. Change (1): The expiry field in the media database is set by all backups. Change (2): There is an additional field in the media database for browse time, which is also always set. Change (3): If the expiry and browse times are not overridden they will take a value based on the policies specified in the client resource. Change (4): The save command can now take a "-w" parameter to set the browse time for a save set. Change (5): The expiry and browse time fields are no longer cast in stone at backup time, instead they can be changed using the nsrmm command, e.g. nsrmm -S 12345 -e "8 weeks" -w "4 weeks" or nsrmm -S 12345 -e "20 October" -w "20 September" Change (6): It _is_ possible to change a save set back from recoverable to browsable by merging an old file index back into the current file index for a client. This is due to index changes so I won't cover it here. "If only" (1): Unfortunately, the new "-w" parameter for save has not been included in the savegrp command. This makes it very difficult to ever set this parameter, the only way being to use a backup script on each client. This is a poor solution because centralised control is lost. Perhaps Legato will add this obvious enhancement soon? "If only" (2): ...the browse and retention policies could have been defined for a group as well as for a client. This is the case for schedules, and a schedule set for a group will override any value set for a client. It would be _really_ smart if the same functionality could be implemented for browse and retention policies. Are you reading this Legato Product Management? Related change: Another new field has been introduced into the media database for each save set, called "group". This records what group was running to backup each save set. This is useful for mminfo queries, especially if you wish to retrospectively change the browse and retention values of all save sets from a particular save group. If this was done just after the group completed, a simple script to do this could look something like this: mminfo -q "group=weekly1,client=bigbox,savetime>yesterday" -r ssid \
while read SSID
do
nsrmm -S $SSID -e "12 weeks" -w "4 weeks"
done
|
||||||||||||||
| This page was last modified 06:01, 3 December 2006. | ||||||||||||||