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)
********************************* DISCLAIMER *********************************
The information contained in the above e-mail message or messages (which
includes any attachments) is confidential and may be legally privileged. It is
intended only for the use of the person or entity to which it is addressed. If
you are not the addressee any form of disclosure, copying, modification,
distribution or any action taken or omitted in reliance on the information is
unauthorised. Opinions contained in the message(s) do not necessarily reflect
the opinions of the Queensland Government and its authorities. If you received
this communication in error, please notify the sender immediately and delete it
from your computer system network.
|