Script for cloning volumes

Out of interest will your script try to run multiple clone jobs at a time? I've always been thinking of trying to write such a script as the automatic cloning seems to get it self into a multiple when multiple clones are occurring.

In terms of deleting the original savesets on the VTL, we just have a command that deletes any saveset/cloneid combination from the media db on the VTL that is older than 14 days (we like to keep a period of backups local for quick restores) and that have 2 'copies'. I don't think you can recycle a saveset on the VTL as this would also recycle the saveset on the real tape (they have the same ssid).

My interpretation of this is that you wish to make a clone of your data which will be kept on tape for a length of time, and that you wish to keep the original backup on your VTL but for a shorter time than on tape and so want to know what you should do about them.

We are doing something similar here - from necessity rather than design as data growth has meant we cannot keep the original as long as the tape clone - and our strategy has been to adjust the clone retention time for the VTL copy after a successful clone of that saveset. The advantage of this is that your VTL tapes may be expired but can still be recovered from until they are reused.

You have two approaches here - have a loop that checks the amount of nsrclone/nsrstage processes running and ensures this number does not exceed the number of drives you have, or have a loop which parses the nsrjb output to ascertain whether you have any drives not being used - I am currently amending the script we use to go the second way, checking what shared drives are available and to then select a storage node by parsing the nsrjb output again and picking the storage node with least drives in use (you can then use the -J switch with nsrclone/nsrstage to force a particular storage node to be used).

To correct your last point you can set a different clone retention or recycle flag on a clone instance if you specify both the ssid and cloneid with the nsrmm command. There is some enhancement to this in Networker 7.5 so worth looking at upgrading to if you are going to be setting different retention periods etc on your clones.

Hi

Just wanted to make sure you were aware that cloning enhancements was one of the major new features in NetWorker V7.5. Check them out in the Release Notes, if you weren't already aware of these.

Hope this helps.
tl

You are right, i can use the nsrmm but what i whant to do is to change the retention for the original Saveset but how can i do that when the SSID are the same in the original Saveset and in the cloned Saveset?


Thanks all for your replies.

When I mark a volume I use the command:

nsrmm -o recyclable -s -y

or you can try:

nsrjb -o recyclable -s -Y

When dealing with savesets with the same SSID, you have to also specify the clone ID.

nsrmm -S SSID/CloneID ...

Hope that helps.

thanks very usefull Victor.

There's a typo in there - it should say "it checks for savesets that have been cloned"

That is what I do - after each clone process is started the script checks from the list of clone volumes until reaching the current one; it checks for volumes that have been cloned (copies=2) and not had clretent value amended; it then checks that the saveset exists in the physical library and runs the nsrmm command which amends the clretent value for that saveset in the virtual library:

until [[ $check_volume = $volume ]]
do
read check_volume
/usr/sbin/mminfo -q "volume=$check_volume,copies=2,clretent>3 weeks,savetime>1 week ago,ssretent<5 weeks" -r ssid,cloneid -xc" "|while read -r ssidinfo
do
set -- $ssidinfo # split the variable so we can query with the ssid in the next part
ssid=$1
cloneid=$2
ssidcloneid=$1/$2
if [ `/usr/sbin/mminfo -q location=$nsr_jukebox,ssid=$ssid,incomplete=false` ]
then
nsrmm -e "3 weeks" -S $ssidcloneid
fi
done
done < $volume_mono_list

We do make an assumption here that we are cloning last night's backup otherwise we will need to add some code to determine when the backup was made and what date your new clretent will be.