Mat,

The file system is a disk full of images from medical testing equipment.  I was 
performing a
full backup of this disk.  Due to a rearrangement of servers, it was the first 
full backup of
this disk.

mminfo shows this:

# mminfo -q 
'name=G:\MED15AcupunctureLab\GROUPS\AcupunctureLab\Neurology3,level=full,pool=comis
onsite' -r 'volume,sumsize,totalsize'
 volume           size      total
010064L4        268 GB 2258810702832
010065L4        219 GB 2258810702832
010467L4        324 GB 2258810702832
010478L4        269 GB 2258810702832
010483L4       7292 MB 2258810702832
010485L4        292 GB 2258810702832
010581L4        285 GB 2258810702832
010592L4        353 GB 2258810702832
100038L4        184 GB 2258810702832

Which in all cases adds up to just over 2 TB.

So, I'll report to EMC that their savegrp report is wrong.

Thanks for sticking with me on this.

-Frank

On 9/24/12 5:33 PM, Mathew Harvest wrote:
> Hey Frank
>
> Could you tell us the nature of the file system that you are backing up, is 
> it a smallish number of medium to large files, or millions of smaller files 
> .... if it's the latter and you are performing an incremental/differential 
> backup then it could take a substantial amount of time to walk the file 
> system and not actually backup much data ...
>
> Also just wondering if you could run an mminfo query and have a look at the 
> stats for the particular saveset, and see whether the media database is 
> reporting the same size as reported in the save completion report, probably 
> if you reported on totalsize and sumsize it might be useful 
>
> Thanks 
>
> Mat 
>
>
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] 
> On Behalf Of Frank Swasey
> Sent: Tuesday, 25 September 2012 4:04 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] discrepancy in sizes reported
>
> On 9/24/12 1:53 PM, bingo wrote:
>> Frank,
>>
>> at least it was not my intention to pick on procedures. So far i just have 
>> not seen somebody using nsradmin to get status information about active save 
>> streams. 
>> Since nsrwatch is also available for windows, I would most likely prefer 
>> this utility. But if one is used to something he will probably use it 
>> forever.
> I use nsradmin because I can run it from cron at intervals on my Linux server 
> and have it mail me what is actively going on in the NetWorker environment.  
> I don't know of a way to take a snapshot from cron of what is actively being 
> done with either nsrwatch (which up until 7.6 was horrendous in my 
> environment because of the number of devices involved, ever tried to set up a 
> terminal window that had 300 lines and still read it on a display that was 
> 1440x900?) or mminfo.
>
>> I do not see any reason why NW (uasm) would change the size of a files - it 
>> takes what the OS delivers. 
>> So i still think it is worth to compare the report utilities, i.e. your 
>> nsradmin method and the nsrwatch output. This might already point to the 
>> issue.
>> However, the reason  could be as easy as a programmer's typo. Also, do not 
>> forget that the number 2040 is pretty close to one of these 'magic' numbers 
>> (2000 or 2048) where a lot of programs 'usually' had limitations.
>>
> Thank you.  I've certainly got more digging to do.
>

-- 
Frank Swasey                    | http://www.uvm.edu/~fcs
Sr Systems Administrator        | Always remember: You are UNIQUE,
University of Vermont           |    just like everyone else.
  "I am not young enough to know everything." - Oscar Wilde (1854-1900)