Backup Central

Hi,

We have a Linux client that is reporting large incrementals on /0 every
night for the last week. Nobody who uses this host can explain why
there's this much data that's getting backed up on there, but they don't
claim to be loading that much out there to explain the sizes of the
incrementals we're seeing as reported by the NetWorker saveset recover
window.

We're scheduled to run a full tonight, so things might resolve
themselves after that. The last full was on 02/24/05. We have a one
month browse policy. I'm not aware of anything that would be causing the
time stamps on any files to change other than users editing and/or
copying out new data, but they agree that these numbers seem much higher
than they would expect.

Is there a way I can get a listing of the files that NetWorker backed up
on a given date and the sizes of the files so I can see if in fact those
files actually have time stamps within the last 1-2 days? I tried
nsrinfo but have not found the output indecipherable, so I tried
something like this to get the nsavetime value for the /0 saveset from
last night:

1. nsrinfo -s server -q 'savetime>03/22/05' -r nsavetime -v -N /0 -c
client

Next, I ran this:

2. nsrinfo -t nsavetime_value client

This created a large amount of output featuring the pathnames of the
affected files. I could go through and run something like:

3. cat output | xargs -i /bin/sh -c 'ls -ld {}' | awk '{print $5}'

to get the bytes of each file and then add them up, BUT I notice that
when I run 'ls -ld pathname' against many of the pathnames returned
from command 2, I see that the file has an older date, e.g. March 7 or
something. Seems odd that NetWorker would be backing up files with old
time stamps, unless somehow someone untarred or rsynced a file with an
old time stamp?
Any ideas on how better to analyze this?

Thanks.

George

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

What version of NetWorker are you running? We have seen similar
situations with our Windows clients. We are running 7.2 on a SUN
server.

--mike

On Wed, 23 Mar 2005, George Sinclair wrote:

Hi,

We have a Linux client that is reporting large incrementals on /0 every
night for the last week. Nobody who uses this host can explain why
there's this much data that's getting backed up on there, but they don't
claim to be loading that much out there to explain the sizes of the
incrementals we're seeing as reported by the NetWorker saveset recover
window.

We're scheduled to run a full tonight, so things might resolve
themselves after that. The last full was on 02/24/05. We have a one
month browse policy. I'm not aware of anything that would be causing the
time stamps on any files to change other than users editing and/or
copying out new data, but they agree that these numbers seem much higher
than they would expect.

Is there a way I can get a listing of the files that NetWorker backed up
on a given date and the sizes of the files so I can see if in fact those
files actually have time stamps within the last 1-2 days? I tried
nsrinfo but have not found the output indecipherable, so I tried
something like this to get the nsavetime value for the /0 saveset from
last night:

1. nsrinfo -s server -q 'savetime>03/22/05' -r nsavetime -v -N /0 -c
client

Next, I ran this:

2. nsrinfo -t nsavetime_value client

This created a large amount of output featuring the pathnames of the
affected files. I could go through and run something like:

3. cat output | xargs -i /bin/sh -c 'ls -ld {}' | awk '{print $5}'

to get the bytes of each file and then add them up, BUT I notice that
when I run 'ls -ld pathname' against many of the pathnames returned
from command 2, I see that the file has an older date, e.g. March 7 or
something. Seems odd that NetWorker would be backing up files with old
time stamps, unless somehow someone untarred or rsynced a file with an
old time stamp?
Any ideas on how better to analyze this?

Thanks.

George

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

6.1.1 on Solaris 2.8. Client in question is a RedHat Linux box. We think
the problem may be due to the fact that something (unrelated to
NetWorker, e.g. cron script) is going through the files and chmoding
them. I believe NetWorker is sensitive to not only modification time
changes but also any file meta data changes that would affect the
changetime on the file like changing the permissions, owner, group, etc.
Obviously, you can't directly set the changetime, but you can change the
access time and the modification time, and the changetime can be
affected by changing things like the permissions, group, etc. When we
added up the total bytes for the modification time changes plus the
changetime changes it came out in the ball park of what NetWorker was
reporting for the incremental. Now, all we need to do is to determine
what is affecting the changetimes on these files. Probably some script
someone is running.

Can anyone confirm that NetWorker will back up a file if the changetime
has been modified as opposed to the modification time? In other words,
if I say, change the permissions then NetWorker will back it up?

Thanks.

George

Mike Borkowski wrote:

What version of NetWorker are you running? We have seen similar
situations with our Windows clients. We are running 7.2 on a SUN
server.

--mike

On Wed, 23 Mar 2005, George Sinclair wrote:

Hi,

We have a Linux client that is reporting large incrementals on /0 every
night for the last week. Nobody who uses this host can explain why
there's this much data that's getting backed up on there, but they don't
claim to be loading that much out there to explain the sizes of the
incrementals we're seeing as reported by the NetWorker saveset recover
window.

We're scheduled to run a full tonight, so things might resolve
themselves after that. The last full was on 02/24/05. We have a one
month browse policy. I'm not aware of anything that would be causing the
time stamps on any files to change other than users editing and/or
copying out new data, but they agree that these numbers seem much higher
than they would expect.

Is there a way I can get a listing of the files that NetWorker backed up
on a given date and the sizes of the files so I can see if in fact those
files actually have time stamps within the last 1-2 days? I tried
nsrinfo but have not found the output indecipherable, so I tried
something like this to get the nsavetime value for the /0 saveset from
last night:

1. nsrinfo -s server -q 'savetime>03/22/05' -r nsavetime -v -N /0 -c
client

Next, I ran this:

2. nsrinfo -t nsavetime_value client

This created a large amount of output featuring the pathnames of the
affected files. I could go through and run something like:

3. cat output | xargs -i /bin/sh -c 'ls -ld {}' | awk '{print $5}'

to get the bytes of each file and then add them up, BUT I notice that
when I run 'ls -ld pathname' against many of the pathnames returned
from command 2, I see that the file has an older date, e.g. March 7 or
something. Seems odd that NetWorker would be backing up files with old
time stamps, unless somehow someone untarred or rsynced a file with an
old time stamp?
Any ideas on how better to analyze this?

Thanks.

George

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu

Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu