I need to know the total size (for example in GB) of the weekly backup,...

It's easy. With mminfo you can set query which goes for period you want and list savesets and their size. After cloning you can simply verify if this has been cloned fine by looking at clflags and number of copies. If you really want you can compare size too, but I prefer to check that by verifying clflags and number of copies. Obviously you need to be familiar with mminfo command and some basic scripting.

Use the mminfo field totalsize. Assuming your weekly backup is a full one you might try something like:

mminfo -q "savetime>7 days ago,level=full" -r "client,name,savetime,ssflags,clflags,totalsize" -o cnt

Your clones should show up in the same report, the parameter -o cnt will order the output by client,name(saveset) and time so original and clones should be together.

As Hrvoje says the copies field is useful, if you have failed to clone something the value would be 1. You could check for uncloned savesets from the last week:

mminfo -q "savetime>7 days ago,copies=1"

Hi David,

Are you saying this is fixed now? As in 7.2.x I know failed clone would still increase the counter and you had to rely on clflags to make sure copy is correct.

I'm not saying that but I was never aware of any issue with it and I've never seen any falsely reported clone jobs that have caused problems but I will do some testing and see if the problem does happen - it would have some implications for me as we expire the original copy before the clone; my script checks for the clone copy after cloning (location=physical library,copies>1) then checks for a corresponding VTL saveset/clone and amends the clone retention time ) - I can amend this to also check the clflags too...

You can easily check that; just kill your nsrclone for ssid in the middle and check copies counter afterwards.

That's what I plan to do

It's an easy way;you can use mminfo with some parameters in order to retrieve totalsize in GB for weekly backup..for example

mminfo -avot -r client,ssid,ssflags,totalsize(2),sumsize(2) -q "savetime >= 7 days ago"

totalsize will give you totalsize for any saveset "ssid" in GB while you determine the format with (2 digits)
sumsize with calculate totalsize of all savesets on each volume (if more than one volume has used)

It's an easy way;you can use mminfo with some parameters in order to retrieve totalsize in GB for weekly backup..for example

mminfo -avot -r client,ssid,ssflags,totalsize(2),sumsize(2) -q "savetime >= 7 days ago"

totalsize will give you totalsize for any saveset "ssid" in GB while you determine the format with (2 digits)
sumsize with calculate totalsize of all savesets on each volume (if more than one volume has used)

I tired this command:
mminfo -avot -r "client,ssid,ssflags,totalsize(2),sumsize(2)" -q "savetime >= 7 days ago"

It shows a long list with size, while I just need to total size in just one line

You have all ingredients, it's up to you how to cook it. If you don't know simply ask your UNIX or Windows admin to parse sumsize column and sum it up using awk. I would suggest to use totalsize instead of sumsize(2) as sumsize will round the values to GB, KB, PT or whatever based on size... so sum it up on that value level add some complexity where not needed... instead use totalsize which will give you value in bytes and then simply play with that divind it with 1024 or 1000 (or mix) until you get GB value you look for.

My only warning there would be to be aware the totalsize reported would be reported more than once for spanned savesets. If you are really unsure output your data to a text file and import this into Excel.

oh that's easy... you simply egrep for cb, hb and I guess cr if it is index or boorstrap. But usually you do not car about those and if they have dedicated pool you just exclude it from query.

Looking at how I do it I just report ssid and totalsize then do a sort -u to ensure each saveset is included only once...

That will do too.. but I go against flags in mdb as in past I had problems when NW would try to clone broken savesets... I would expect not to do that, but there few known issues across several releases which didn't work as expected. Since then I use same approach.