I have been using amanda for years now on many different machines and
machine types. I regard amanda as the standard in backup systems and
highly recommend it for all computer users.
My systems now are either debian i386/amd64 servers or ubuntu i386/amd64
desktops. The amanda server is a debian/lenny at v2.5.2p1-4 and
works great. Recently, I upgraded my ubuntu desktop to v9.04 (jaunty)
which caused a minor upgrade of amanda from v2.5.2p1-3 to v2.5.2p1-4.
Shortly after this upgrade, I noticed that some of my desktop
filesystems were getting backed up to the server, but most were not.
The error messages look like this:
FAILURE AND STRANGE DUMP SUMMARY:
fea sdf3 lev 1 FAILED [data timeout]
fea sda2 lev 2 FAILED [data timeout]
fea sdf3 lev 1 FAILED [cannot read header: got
0 instead of 32768]
fea sdf3 lev 1 FAILED [too many dumper retry:
"[request failed: timeout waiting for REP]"]
fea sda2 lev 2 FAILED [cannot read header: got
0 instead of 32768]
fea sda2 lev 2 FAILED [too many dumper retry:
"[request failed: timeout waiting for REP]"]
fea sda7 lev 1 FAILED [data timeout]
fea sda7 lev 1 FAILED [cannot read header: got
0 instead of 32768]
fea sda7 lev 1 FAILED [too many dumper retry:
"[request failed: timeout waiting for REP]"]
fea sda7 lev 1 FAILED [cannot read header: got
0 instead of 32768]
fea sda6 lev 1 FAILED [cannot read header: got
0 instead of 32768]
fea sda6 lev 1 FAILED [data timeout]
fea sda6 lev 1 FAILED [too many dumper retry:
"[request failed: timeout waiting for REP]"]
fea sda6 lev 1 FAILED [cannot read header: got
0 instead of 32768]
etc., etc.
Researching the classic cause for this problem reveals several likely
cures. The easiest to implement is to increase the valuve for dtimeout
from the default of 1800 sec to some larger value that will allow for
the data to be sent without error to the server.
I got into debugging mode and discovered why this was happening.
Apparently this upgrade, or a recent change in AMANDA, now forces (or by
error) the data to be compressed with gzip before going from the client
to the server. Even if I specify "compress none" (which I always have)
or "compress client none" and "compress server none", the gzip is still
going on.
I have never seen this before, and the gzip process is taking forever
for my large filesystems. I can't seem to get it to stop.
Is this a bug or something I can correct by the right configuration ?
As a workaround, I increased the dtimeout to a large value of 10 hours.
However, what I would rather do is enforce gzip off, which would
eliminate the problem.
Inserted below is my amanda.conf (sorry that the e-mail wraps the
lines):
#
# changed ethernet speed to 100 kbps and disk speed to 500 kbps, jdf
1/27/99
#
org "rrd" # your organization name for reports
mailto "fea AT ornl DOT gov"
#space separated list of operators at your site
dumpuser "backup" # the user to run dumps under
inparallel 5 # maximum dumpers that will run in parallel
netusage 100 Mbps # maximum net bandwidth for Amanda, in Mbps
dumpcycle 18 days # the number of days in the normal dump cycle
tapecycle 36 tapes # the number of tapes in rotation
bumpsize 200 Mb # minimum savings (threshold) to bump level 1 -> 2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * (level-1)**bumpmult
etimeout 300 # seconds per filesystem for estimates
dtimeout 36000 # seconds per client for dumps
maxdumps 8 # maximum number of parallel clients
reserve 30 # reserve 30% of holding disk for degraded mode
(level 0 fix)
usetimestamps yes # allows tracking of more than one backup per day
# Specify tape parameters.
runtapes 1 # number of tapes to be used in a single run of
amdump
tapedev "/dev/nst0" # the no-rewind tape device to be used
#tapedev "null:" # for debugging only
tapetype vxa3_x23 # what kind of tape it is (see tapetypes below)
labelstr "^rrd[0-9][0-9]*$" # label constraint regex: all tapes must
match
tpchanger "chg-zd-mtx" # the tape-changer glue script, see
TAPE.CHANGERS
changerfile "/etc/amanda/rrd/changer.conf"
changerdev "/dev/sg4"
# Specify holding disks.
holdingdisk hd1 {
comment "main holding disk"
directory "/holding_disk" # where the holding disk is
use 215 Gb # how much space can we use on it
}
# Amanda needs a few Mb of diskspace for the log and debug files,
# as well as a database.
infofile "/home/backup/rrd/curinfo" # database filename
logdir "/home/backup/rrd" # log directory
indexdir "/home/backup/rrd/index" # index directory
# tapetype
#define tapetype vxa2_x23 {
# comment "VXA3/X23"
# length 65000 mbytes
# filemark 0 bytes
# speed 6009 kps
#}
#define tapetype vxa2_x23 {
# comment "by amtapetype vxa-3/x23 (hardware comp off)"
# length 75774 mbytes
# filemark 0 kbytes
# speed 6101 kps
# blocksize 64 Kbytes
#}
define tapetype vxa3_x23 {
comment "by actual experience (hardware comp on)"
length 200000 mbytes
filemark 0 kbytes
speed 98304 kps
blocksize 64 Kbytes
}
#
# note: 93502912k recorded on 09/12/2007 with length set to 100000
mbytes
# changed length to 120000 mbytes
#
define dumptype root-tar {
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
compress client none
compress server none
holdingdisk yes
index
priority low
exclude list "/var/backups/exclude.gtar"
}
define dumptype user-tar {
root-tar
comment "user partitions dumped with tar"
priority medium
exclude list "/var/backups/exclude.gtar"
}
define dumptype skip-it {
comment "dummy dumptype to skip a file system (for debugging)"
ignore yes
}
# network interfaces
define interface local {
comment "a local disk"
use 1000 kbps
}
define interface le0 { comment "1 Gbps ethernet" use 100 Mbps }
--
James D. Freels, Ph.D.
Oak Ridge National Laboratory
freelsjd AT ornl DOT gov
|
