[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference decwet::networker

Title:NetWorker
Notice:kits - 12-14, problem reporting - 41.*, basics 1-100
Moderator:DECWET::RANDALL.com::lenox
Created:Thu Oct 10 1996
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:750
Total number of notes:3361

695.0. "Incremental Backups unreasonably large on DU Client" by KNEIPE::NOFFKE () Wed May 21 1997 01:28

Hello,

I use NSR Client V4.2A on my ALPHA workstation with Digital Unix V4.0B. The NSR
server is an ALPHA server with Digital Unix V4.0 and NSR Server V4.2A. My
problem: The incremental backup performed every night creates unreasonably large
savesets (typically 300 to 400 MB)! The client setup for my workstation is the
same as for other workstations in the same savegroup but mine is the only one
with Digital Unix V4.0B. 

Any comments on this?


Regards

Uwe Noffke
T.RTitleUserPersonal
Name
DateLines
695.1I-nodes & hw linksNNTPD::"[email protected] "Michael R. BalomiriWed May 21 1997 04:205
do you have:

1) Clones as SS
2) HW Links 
[Posted by WWW Notes gateway]
695.2KNEIPE::NOFFKEWed May 21 1997 05:253
1) no clones as SS

2) what is the point with the HW links?
695.3you sure NSR is doing a incr??DECWET::EVANSNSR EngineeringWed May 21 1997 12:395
it could be doing a full... post 

 	savegroup -pnv -c client-name group-name-containing-client

verbatim so we can see too.
695.4Output of "savegroup -pnv -c hessen.frs.dec.com systeme"KNEIPE::NOFFKEWed May 21 1997 23:2237
hessen.frs.dec.com:/                      level=7
hessen.frs.dec.com:/usr                   level=7
hessen.frs.dec.com:/var                   level=7
 5/22/97  7:13:28 savegroup: Run up to 4 clients in parallel
 5/22/97  7:13:28 savegroup: hessen.frs.dec.com:probe                   started
savefs -s tbla2.frs.dec.com -g systeme -p -n -l full -R -v -F / /usr /var 
 5/22/97  7:13:34 savegroup: hessen.frs.dec.com:probe succeeded.
rcmd hessen.frs.dec.com, user root: `savefs -s tbla2.frs.dec.com -g systeme -p
-n -l full -R -v -F / /usr /var'
asavegrp: authtype nsrexec
type: NSR client description;
pools supported: Yes;
arch: decaxp;
CPU type: alpha;
CPUs: 1;
hosts: 1;
IP address: 16.185.224.20;
kernel arch: OSF1;
License units: 1050;
NAS Client: No;
OS: OSF1 V4.0;
version: V4.2A;
save set: path=/, arg=/, level=full, diskno=2, max_sessions=1, stype=save,\
path=/usr, arg=/usr, level=full, diskno=1, max_sessions=1, stype=save,\
path=/var, arg=/var, level=full, diskno=0, max_sessions=1, stype=save ;
parallelism: 8
--- Probe Summary ---

hessen.frs.dec.com:/                  level=7, dn=2, mx=1, vers=pools, p=8
hessen.frs.dec.com:/      level=7, save as of Mon Mar 17 22:12:08 GMT+0100 1997
hessen.frs.dec.com:/usr               level=7, dn=1, mx=1, vers=pools, p=8
hessen.frs.dec.com:/usr   level=7, save as of Mon Mar 17 22:06:16 GMT+0100 1997
hessen.frs.dec.com:/var               level=7, dn=0, mx=1, vers=pools, p=8
hessen.frs.dec.com:/var   level=7, save as of Mon Mar 17 22:10:54 GMT+0100 1997
hessen.frs.dec.com:index             level=7, dn=-1, mx=0, vers=pools, p=8
hessen.frs.dec.com:index  level=7, save as of Thu May  1 22:47:57 GMT+0200 1997
695.5Index instances for the /usr filesystemKNEIPE::NOFFKEWed May 21 1997 23:2728
11860           22053  637 MB  3/17/97  full
11897           19234  314 MB  3/18/97    incr
11943           19136  313 MB  3/19/97    incr
11983           19198  313 MB  3/20/97    incr
12137           19621  316 MB  3/24/97    incr
12180           19336  318 MB  3/25/97    incr
12219           19341  314 MB  3/26/97    incr
12371           19578  329 MB  4/11/97    incr
12511           19400  317 MB  4/14/97    incr
12560           19995  352 MB  4/15/97    7
12604           19511  317 MB  4/16/97      incr
12648           19957  370 MB  4/17/97      incr
12819           20062  322 MB  4/22/97      incr
12862           20247  410 MB  4/22/97    7
12909           19681  320 MB  4/23/97      incr
12952           19249  314 MB  4/24/97      incr
13038           19229  315 MB  4/28/97      incr
13070           19202  314 MB  4/28/97      incr
13113           19908  411 MB  4/29/97    7
13361           19631  374 MB  5/05/97      incr
13401           19086  307 MB  5/06/97      incr
13446           19485  309 MB  5/07/97      incr
13490           20537  471 MB  5/08/97    7
13537           19204  307 MB  5/13/97      incr
13582           19256  308 MB  5/14/97      incr
13627           20493  473 MB  5/15/97    7
13841           19342  313 MB  5/20/97      incr
13882           19509  308 MB  5/21/97      incr
695.6See what's being backed upDECWET::GRAHAMThu May 22 1997 10:0022
You need to see what is being backed up in an incremental
on this client. Maybe you have a large file which is touched
daily.

There's a NetWorker command called nsrinfo which allows you
to see what is in a client's online index for a particular
save, among other things. Here's how to do it (from the nsrinfo
man page example, tried on my workstation):

root@cochiti[20]> mminfo -r nsavetime -v -N / -c cochiti -ot |tail -1   
  864314936
root@cochiti[21]> nsrinfo -t 864314936 cochiti.zso.dec.com 

Result is a list of all files backed up for that save. My example 
looks at the last save; you will want to make sure you specify one 
of the large incremetals you're interested in, as well as the 
appropriate filesystem in the mminfo command.

When I tried it, the fully qualified client name was required
by nsrinfo.

Debbie
695.7NNTPD::"[email protected]"Uwe NoffkeTue May 27 1997 01:1517
Debby,

today I did two incremental backups on my workstation by manually starting
them
from nwadmin's "customize/Groups..." dialogbox. The first incremental totalled
to 18178 files and 267MB, the second had 17473 files and 266MB. Then I
generated
a list of the saveset contents using the commands you proposed. 
Result: the 17473 files from the second saveset had been backed up twice
within
half an hour.
How does Networker determine what files to include into an incremental
backup??

Uwe
 
[Posted by WWW Notes gateway]
695.8man save has detailsDECWET::EVANSNSR EngineeringTue May 27 1997 10:1312
save -l incr saves all files changed (mtime) since last save. if mtime gets
 changed for *any* reason, files are saved by NSR.

save -l <number> saves files that have mtime changed since last level "x"
 save.

schedule determines the level for a savegroup - check your schedule.

regardless of what level is specified, if NetWorker determines there are no
 entries in the index, it does a full backup. This can occur anytime should
 the name of the index not match *precisely* the name of the client being
 saved (for one example).
695.9Any directives in force for the filesDECWET::GRAHAMTue May 27 1997 15:039
Uwe,

   If the files did not have their mtime values changed between the 
two incrementals you ran, maybe you have a directive in effect for
them. The "always" directive causes a file or directory to be backed
up regardless of its last change time. Look at the nsr_directive and
uasm man pages for more information.

Debbie
695.10No directivesNNTPD::&quot;[email protected]&quot;Uwe NoffkeWed May 28 1997 05:1029
Debbie,

I didn't find any nsr directives in effect. Also, when I looked for modified
files using

	find /usr -mtime -2

I found about 1000 files that had been changed since Monday. Doing a

	savegrp -n -C Quarterly Test
or
	savegrp -n -l inc Test

showed the following output:

  hessen.frs.dec.com:/ 685 records 127 KB header 13 MB data
  hessen.frs.dec.com:/ 13 MB estimated
  hessen.frs.dec.com:/var 323 records 62 KB header 5.0 MB data
  hessen.frs.dec.com:/var 5.1 MB estimated
  hessen.frs.dec.com:/usr 17693 records 3.5 MB header 279 MB data
  hessen.frs.dec.com:/usr 282 MB estimated
  tbla2.frs.dec.com:/var/nsr/index/hessen.frs.dec.com 2 records 1 KB header
6.5 MB data
  tbla2.frs.dec.com:/var/nsr/index/hessen.frs.dec.com 6.5 MB estimated

I really don't know what to do now. Do you have any other ideas?

Uwe
[Posted by WWW Notes gateway]
695.11DECWET::GRAHAMThu May 29 1997 10:057
Uwe,

  Do the 17693 files have anything in common? Maybe there is something 
about the data that can help solve the mystery. Other than that, I
don't know what else to suggest.

Debbie
695.12once upon a time...DECWET::EVANSNSR EngineeringMon Jun 02 1997 09:516
a customer called in an IPMT to NetWorker Engineering swearing NetWorker
was broken. After 3 months of arduously researching this, it came down
 to a cron entry that touched (altered the m-time) of every file in the
 system, thus making NetWorker do a full (apparently) backup.

moral: watch your cron jobs.
695.13Solution....NNTPD::&quot;[email protected]&quot;Uwe NoffkeWed Jun 04 1997 01:2028
I finally found the reason for Networker's strange backup behaviour!

When I installed DU 4.0B on my workstation the system date had been set to
Jun 02 1997. I didn't realise that at first and it did no harm to my daily
work.
Then I installed the Networker client and experienced the large incremental
backups. Looking for reasons I found several files and directories dated
Jun 02 97. So I touched each of them to reset the modification date and time
to the current values. However, this didn't change Networker's backup
behaviour.

Not knowing what else to do I entered the note here to ask for help.

Today (Jun 04 1997) I looked again across the saveset indexes of my
workstation
and found that the size of the last incremental backup had shrinked down to
about 3 to 4 MB!

So I guess that touching the files in question was not sufficient. I think I
should have done another full backup after touching the ill-dated files to
"reset" Networker as well.

Sorry for causing any headaches and many thanks for all your answers!!

Kind regards

Uwe.
[Posted by WWW Notes gateway]