🚀 go-pugleaf

In article <1992May19.025054.17688@decuac.dec.com>,
mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
writes:
|> romig@brachiosaur.cis.ohio-state.edu (Steve Romig) writes:
|> >I'm curious - how much space does the online index take up?  I'd
|> >imagine that it would be proportional to the number of files
|> backed
|> >up, which might be hard to estimate...
|> 
|> 	18 months of NSR index for 9 machines took 80 megs with just
|> incrementals and no index cleaning. I purged tapes #1 and #2 a few
|> months ago and it gave me back 20 megs. (I guess #1 and #2 had a
|> lot of directory entries on them). I'm not sure how the index size
|> relates to the number of times a file is backed up. I *assume*
|> that
|> a dated tuple:
|> { inode, tape, date }
|> 	gets stored each time a file's directory entry is re-saved.
|> Possibly my approach of doing incremental-only is a big win here.
|> I'm interested to know what other people see...?
|> 
|> >I'd swear that I've heard people throw around figures like "10% of
|> the
|> >amount that's backed up", which seems absurd.  In our case, since
|> we
|> >have about 160 Gb on tape at the moment, we're talking about an
|> online
|> >index of 16 Gb using that ratio...yow!
|> 
|> 	I'm handling a measly 10gig or so. Of course, since I only
|> do incrementals, I only wind up saving about 10Mb to tape per
|> night,
|> so figure the indexes grow very very slowly. Possibly more so
|> because
|> most of the stuff that changes is syslog files, mail queue and
|> whatnot.
|> 
|> 	I DO NOT BACK UP NEWS.
|> 
|> 	This helps, I suspect.
|> 
|> mjr.

 Ok, I'll answer both articles.

 The method mentioned by Marcus is not a real option in my center
where
I have several "production" machines. I need to store data off-site
and I also
need to have a local copy of the file for easy recovery.

 For production machines I do a full backup on Tuesdays and Fridays, I
can
recycle the Tuesday dumps regularly but the Friday dumps are long
term. The
rest of the week is incr. This server is only for production machines,
it's tapes
are stored off-site and only root can recover files from it. 

For the non-production server  I do a full dump of clients on the
first of the 
month and incr. throughout the month. I also do a weekly full dump of
some
of the production machines to this server to ensure quick recovery of
files when
required. I backup approx 120 clients to  3 8500 (5 gig devices)
drives. I also don't 
backup the News partition. The clients incr. dumps can be recycled
after the first
of the month but I haven't started that yet since I want to see what
sizes my indices 
will grow to.

 I have approx. 3 months worth of backups on tape and in the indices
right now and
the /nsr partition is at 2.8 Gig, the first month was on the 8200
drives (2 gig).  The
total nightly backups are approx. 3 Gig during the incrementals and
close to 100 Gig
on the first of the month so 2 Gig of indices for 3 months seems fair
to me.

 I heard a Legato marketeer mention 800 meg of indices for 40 Gig of
backups but 
that would really depend on your ageing scheme and whether or not you
could
do incrementals for most of the time.

 I agree that backup schemes need to be re-addressed now that the
tools are more
robust and the amount of data being dumped is increasing but I
disagree that full
dumps are less critical now. That may be my bias because of the
requirements for a
production facility but also I distrust placing that much faith in
anything that will
create a single point of failure. If for some reason the single full
backup tape was
hosed/corrupted you now have no way to restore your incrementals. I
would say
even in a non critical environment full backups once a month would be
a minimum.
IMHO of course.

-- 
 -----
 Ken Trant <trant@sgi.com>     / Second Star to the right
 Senior Systems Administrator / And straight on till
 Information Services,       / Morning
 Silicon Graphics, Inc      / Peter Pan