Determining saveset dependancies

That query responds with 'no matches found for the query'.
Is that going to be matching dependant savesets, or only listing the browse time of the savesets actually on the tape?
Because I know they've all expired, but nsrim still thinks I have '18 GB used,    62 save sets, full, 2 browsable save sets, 60 recyclable save sets'

I'm just having a hard time tracking down which two that is, and am wondering if I'll be ending up doing 60odd sets of client/name queries, to determine if there's any unexpired incrementals following the ones on this tape. 

I forgot to add that you need to specify your tape in the mminfo command but I am sure you can work that out.

The savesets in question should be listed when you run:

mminfo -q "ssbrowse>today"

A very usefull list of backup cycles, also showing dependencies, you will get by command

     nsrim -nv -c

or without specifying a client for all clients configured.

You'll get the backup time, ssid and the save set status (browsable, recoverable, recyclable) and you see the chronological order.

I would suggest first to check on the volume which clients and save set names to focus on using mminfo command and then checking with nsrim report.

So, I've knocked together a spot of perl to test this - for every saveset on the tape, I did an 'mminfo' looking for the client/saveset name, and looking for possible culprits.

I can post the script if anyone's interested, but it's basically:

mminfo -ot -xc, -r "ssid,client,name,pool,volume" -q "volume=DS3320"

And for each saveset listed, do an

mminfo -avot -xc, -q "client=$client,name=$name" -r "pool,ssid,ssflags,savetime,ssbrowse,ssretent,level,client,name,volume"

And look for any savesets between 'my' saveset, and the next 'full' in the list, that are not full, and not expired.

Would I be right in thinking that this _should_ show up any savesets that are preventing my tape from being recycled? Because all I'm getting out of this, is a whole list that are 'expired'. (This is similar-ish in output to nsrim, but it tells me the volume and pool, which is much more useful for my purposes).

Turns out it's a bug:

http://solutions.emc.com/EMCSolutionView.asp?id=esg109376&usertype=C

I've got 400 tapes tied up, and have knocked together a script to validate which ones are probably safe to recycle manually, but the longer term fix is to roll out an update.

Hi Edward,

Could you post the perl script aswell please - I'd be interested to have a look at that.

thanks,

Bobby

I've put the script in a document. I _think_ it should be:

https://community.emc.com/docs/DOC-8120

It's a bit rough and ready at the moment, so please treat with all the caution that a script from 'some guy off the internet' deserves.
Pretty sure it won't do you any harm, as it's only running mminfos though .
A sample of the results it's given me, checking by hand _looks_ like it's doing what it's supposed to.

Specifically:

Cycle through all the tapes in 'mminfo -m' with an expiration of 'undef'.

Check each of the tapes in question to ensure they have no savesets that are not 'expired'.
Do an mminfo on client and name, of each of those savesets, and try and identify if there are any unexpired incrementals afterwards that are not expired.

It generates a logfile in the current directory - 'ssdeps.log' - that's likely to get a little large, but should help validate the output on standard out, which I've tried to keep easily readable.

Thanks a million Edward - looks great.

Just to update - the ssdeps log seems to get a bit excessive, so I've amended the script - 300Mb of log, for 400 tapes seems a little extreme .