Gene,

> I would hope that the backups are being done as an unprivileged user, 
> bin has quite high rights on most systems.  OTOH, the mailto: here is 
> root.

As a matter of site policy all new installations are being configured
to run as "amanda".

> Thats why most of us have added a user 'amanda' and made amanda a 
> member of the group disk or bin, whichever works for your distro.

> Unless you have an exclude list file in comp-root that 
> specifies ./maildb, ./maildb2 and ./home (on separete lines) you are 
> doing the whole of the last 3 filesystems twice each, once for / and 
> once per subdir listing.  The last entry will also make you require a 
> seperate disklist entry for /home that doesn't specify the exclude 
> file.
> 
> Thats of course unless the last 3 are in fact different disks 
> entirely, in which case you should append a 1, a 2, a 3, or a 4 in 
> order to define to amanda that they are separate physical disks and 
> can therefore be done concurrently.  One should not attempt to backup 
> 2 different partitions on the same disk concurrently as that will 
> thrash the seeks, slowing things down a bit, or potentially 
> overheating the seek drivers and damaging the drive, but that would 
> be a very extreme result and something I've not seen in at least 5 
> years.

Yes, these are different disks. Mirrored too (should provide some
read performance benifits as well as HW redundancy). Its a Lotus
Notes server, many large files.

BTW we are using native dump, not tar (not gnutar nor other).

# df -kl
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/md/dsk/d10      7789512 2510143 5201474    33%    /
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
mnttab                     0       0       0     0%    /etc/mnttab
swap                 7670968      16 7670952     1%    /var/run
swap                 8588192  917240 7670952    11%    /tmp
/dev/md/dsk/d40      52421967 36894141 15003607    72%    /maildb
/dev/md/dsk/d60      70555171 27397902 42451718    40%    /maildb2
/dev/md/dsk/d30      17408538 7022817 10211636    41%    /export/home
/dev/dsk/c1t4d0s0    70554178       9 69848628     1%    /amanda/work

> I have the situation in my /usr dir that there are a couple of the 
> subdirs that are more than a tapefull, so my /usr is broken down into 
> a /usr/subdir per disklist entry.  The is no entry for / in my 
> disklist.
> 
> There are also good reasons to use a non-compressing dumptype for some 
> dirs as they will grow rather than compress if they contain mostly 
> executable binaries.  Likewise for dirs that contain already 
> compressed archives & rpms.  Its a waste of gzips time to try and 
> compress them further.  A good argument for a bit of reason in the 
> directory layouts :)

Compression on these disks is pretty successful. Using SW rather than
HW compression.

> You can see which ones you are wasting compression efforts (and cpu 
> horsepower) on by looking at the reported compression achieved, in 
> the email from amanda, and switching those entrys that only get 5 or 
> 10% to a non-compressing dumptype, there by saveing a lot of useless 
> wheel-spinning by gzip.

> It doesn't seem to be at all sensitive to whitespace here.  I use tabs 
> liberally for formatting in mine, but an equal amount of spaces is 
> also just fine.

That at least is good news. Too bad there isn't really a syntax
checker for amanda.conf - would potentially have saved me from
making myself crazy over the typo I had in the columnspec param
last month.

> The use of spindle numbers in the dle perhaps.

Nope, default (blank) doesn't do any blocking.

                                                Thanks Gene,

                                                Brian