Amanda-Users

add new clients, lost order scheduleing, tape isn't streaming

2003-05-30 03:20:14
Subject: add new clients, lost order scheduleing, tape isn't streaming
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: amanda-users AT amanda DOT org
Date: Fri, 30 May 2003 03:15:54 -0400
Hi everybody;

I've been rsync'ing those pieces of the firewall I consider precious 
for the last 2 years, and backing up this rsync'd "mirror".

Tonight, I figured it was time I actually learned a bit about 
client-server relationships, so I redid the disklist, and installed 
the 20030529 snapshot on the firewall itself, using this 
configuration script:

#!/bin/sh
# since I'm always forgetting to su amanda...
if [ `whoami` != 'amanda' ]; then
        echo
        echo "!!!!!!!!!!!! Warning !!!!!!!!!!!!"
        echo "Amanda needs to be configured and built by the user amanda,"
        echo "but must be installed by user root."
        echo
        exit 1
fi
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
        --with-group=disk \
        --with-owner=amanda \
        --without-server \
#       --with-tape-device=/dev/nst0 \
#       --with-changer-device=/dev/sg1 \
        --with-gnu-ld --prefix=/usr/local \
        --with-debugging=/tmp/amanda-dbg/ \
        --with-tape-server=coyote.coyote.den \
        --with-amandahosts \
#       --with-configdir=/usr/local/etc/amanda

make
---------------------
The --without-server line is new, and the stuff a client shouldn't 
care about is commented out. Did I miss anything?

Now the client is a bit slow, a 500mhz K6-III, so I expected the level 
0's this would cause would take a while.  This also brought my 
disklist entries up to 44.  The string that controls the dumporder in 
amanda.conf:
dumporder "SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS"
*should* cause the largest first, then descending order, and there are 
enough S's to cover all DLE's such that once the first dump is ready, 
the drive streams till its done.

However it seems to have bypassed that as it has now, a bit over 2:10 
into the dump, taped 33 of the smaller dumps, and is just now 
starting on the largest one which was the /usr/src dir on the 
firewall machine.  The tape has sat idle a good bit of time, enough 
that an amplot when its done is going to be interesting.  Its 
probably also doing a bit of shoeshining of the tape although thats 
hard to hear on a dat when there is enough fans running to feed a 
blacksmiths forge in here.  But thats not confirmed by a run of 
amplot on the unfinished run, which says it ran once for about 20 
minutes, then stopped for about 40 minutes, and is now dumping the 
roughly 1gig of dump from the client.  It just got started on that in 
the last 5 minutes.

I have plenty of holding disk, but its all on this machine.  Would it 
help to define some space on the client?

And how would I go about that so that it had local buffer for its gzip 
operations?

Or is this a factor when the network is 100mbit?

I did give those entries for the client a different spindle number, 3, 
as all DLE's of interest on the client are on one drive.

Or could I have old configs on the firewall that are fooling with me?
Humm, I'll go look.  Yes there were, and I just mv'd the whole 
/usr/local/etc/amanda dir on that machine.  But I expect if its being 
used, its too late for *this* backup.

It has a 30% reserve setting for the holding disk, and presently is 
showing that about 1.5 gigs of the 25 available is in use, and its 
taped only 650 megs prior to starting this instants file.

Does anybody else have ideas as to why the dumporder is being ignored?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.


<Prev in Thread] Current Thread [Next in Thread>