can not back up client
I am able to successfully back up Solaris and Red Hat clients. I can not back up the Debian client. The server is running on Red Hat. This is the error message in the log: STRANGE dumper 0 [sec 3057.777 kb 9339610 kps 3054.4 orig-kb 9749540] sendbackup: start [ level 0] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/tar -f... - sendbackup: info end ??free(): invalid pointer 0x8063fd8!| Total bytes written: 9983528960 (9.3GB, 3.1MB/s) sendbackup: size 9749540 sendbackup: end Any help would be greatly appreciated. Rodney
question about chg-scsi config
What exactlty means the "sleep" configuration parameter in the changer.conf file? I notice some lag in the tape commands (it seems the tape is doing nothing, and the amtape is just sleeping...), so maybe the default value of 90 is too conservative for my system. How can I safely tune it? And BTW, are the cleanmax, cleancart, and cleanfile actually used for automatic tape cleaning? (is such cleaning visible in the amanda reports?) Cheers, Rodrigo -- *** Rodrigo Martins de Matos Ventura <[EMAIL PROTECTED]> *** Web page: http://www.isr.ist.utl.pt/~yoda *** Teaching Assistant and PhD Student at ISR: ***Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, PORTUGAL *** PGP fingerprint = 0119 AD13 9EEE 264A 3F10 31D3 89B3 C6C4 60C6 4585
accidentally deleted amanda.conf
Can someone help me out on how to restore amanda.conf from tape? I can't see any way to do it.
Re: accidentally deleted amanda.conf
[EMAIL PROTECTED] wrote: Can someone help me out on how to restore amanda.conf from tape? I can't see any way to do it. Basically: on the amanda server $ cd /tmp $ mkdir restore-tmp; cd restore-tmp # we restore in a safe place so that we don't overwrite # anyting useful $ su# we need to be root to restore # now insert the correct tape (you do have tapelabel?) # with a recent level 0 (or some incremental if you # know it is there) # if not look through the mail reports to find # a recent level 0 of the "server /disk/entry" # You may also zgrep the index-files manually. # mt -t /dev/st0 rewind # each time you make a mistake in # next (two) commands:-) # eventually do "mt fsf ..." to speed up the restore # amrestore -p /dev/nst0 servername '/disk/list/entry$' | gtar -xpvf - ./path/to/amanda.conf # Note that the disklistentry is a pattern, not a string # use "restore" instead of gtar if you make backups with dump -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: accidentally deleted amanda.conf
On Tue, Nov 15, 2005 at 08:52:24AM -0700, [EMAIL PROTECTED] wrote: > Can someone help me out on how to restore > amanda.conf from tape? I can't see any way to do it. > Sure it is possible, that is a reason I use amanda. You can recover without having amanda. Do you have printed reports showing what DLEs are on what tapes and which tape files correspond to which DLEs? I.e. a Table Of Contents? If not, do you still have log files from which the command amtoc can generate a TOC? I don't think amtoc needs any configuration info, just the log files. If neither, you may have to manually look to find which tape, and tape file, contains the dump you need. This would be done by starting from the beginning of the tape and alternating something like: mt -f fsf 1 dd if= bs=32k count=1 The information in the first 32k of each tape file (the file header) should show what DLE, level, date, ... It will also show a basic command line needed to extract the data in the tape file. Don't take it literally. But it will show whether you need dump or tar, gzip or not, ... I'd recommend extracting into an empty directory. Confirm you extracted what you need and copy it to the correct location. If you try to extract directly into your config directory you risk overwriting something you did not intend. The man page for your dump or tar will show the syntax for extracting individual files or directories if you don't want to extract the entire DLE. When constructing this expression don't forget amanda backups start from ".". So if you want /usr/local/etc/amanda/amanda.conf and your DLE is a dump of /usr/local, you want to extract "./etc/amanda/amanda.conf". -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: question about chg-scsi config
On Tue, Nov 15, 2005 at 02:50:17PM +, Rodrigo Ventura wrote: > > What exactlty means the "sleep" configuration parameter in the > changer.conf file? I notice some lag in the tape commands (it seems > the tape is doing nothing, and the amtape is just sleeping...), so > maybe the default value of 90 is too conservative for my system. How > can I safely tune it? Honestly, the only way is reduce it and see if it causes problems. If I were to try and "measure" what might be needed, I'd position a tape about 'half unwound' (fun to try and figure that out on serpentine tape formats :) Then I'd type in a rewind with mt, and while it was rewinding, but before you get a shell prompt, enter another tape command, say a dd for a gigabyte to /dev/null. But don't hit the enter key on the dd command until you see the prompt return from the mt command. Probably when the prompt appears, the tape will actually still be rewinding. However, immediately upon seeing the prompt hit the return key and notice how long it takes the tape to begin moving forward. Some drivers would give an error to status requests during this period between the apparent command completion and the actual "drive ready" condition. This is the delay for which chg-scsi is trying to accomodate. If dd receives an error, keep repeating the dd command until it does work. As a fudge factor, I'd double your measured delay. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: can not back up client
On Tue, Nov 15, 2005 at 09:41:04AM -0500, Rodney Johnson wrote: > I am able to successfully back up Solaris and Red Hat clients. I can not > back up the Debian client. The server is running on Red Hat. > > This is the error message in the log: > > STRANGE dumper 0 [sec 3057.777 kb 9339610 kps 3054.4 orig-kb > 9749540] > sendbackup: start [ level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/tar -f... - > sendbackup: info end > ??free(): invalid pointer 0x8063fd8!| Total bytes written: 9983528960 > (9.3GB, 3.1MB/s) > sendbackup: size 9749540 > sendbackup: end > > Any help would be greatly appreciated. > My first guess is that is a message from tar. The tar is running on the Debian client. What version has Debian supplied? If you manually do the "RECOVER_CMD" on the client do you get an error? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: question about chg-scsi config
When we got our first changer I actually did some timing tests to get a rough idea on how long "longest case" rewind-eject-load-calibrate (I'm using DLT) took. Then I starting shaving the time down until I saw problems and then bumped the time back up. Jon LaBadie wrote: On Tue, Nov 15, 2005 at 02:50:17PM +, Rodrigo Ventura wrote: What exactlty means the "sleep" configuration parameter in the changer.conf file? I notice some lag in the tape commands (it seems the tape is doing nothing, and the amtape is just sleeping...), so maybe the default value of 90 is too conservative for my system. How can I safely tune it? Honestly, the only way is reduce it and see if it causes problems. If I were to try and "measure" what might be needed, I'd position a tape about 'half unwound' (fun to try and figure that out on serpentine tape formats :) Then I'd type in a rewind with mt, and while it was rewinding, but before you get a shell prompt, enter another tape command, say a dd for a gigabyte to /dev/null. But don't hit the enter key on the dd command until you see the prompt return from the mt command. Probably when the prompt appears, the tape will actually still be rewinding. However, immediately upon seeing the prompt hit the return key and notice how long it takes the tape to begin moving forward. Some drivers would give an error to status requests during this period between the apparent command completion and the actual "drive ready" condition. This is the delay for which chg-scsi is trying to accomodate. If dd receives an error, keep repeating the dd command until it does work. As a fudge factor, I'd double your measured delay. -- George Kelbley System Support Group Computer Science Department University of New Mexico 505-277-6502Fax: 505-277-6927
Re: Is automatic wakeonlan possible?
Thanks for the suggestion. A wrapper (or part of the cron job) only handles part of the problem. If the machine has a timeout, say 1 hour, then either solution will allow the estimate to be performed, but the backup itself may fail if it is more than 1 hour between the estimate and the backup. Matt Hyclak <[EMAIL PROTECTED]> writes: > On Thu, Nov 10, 2005 at 06:00:59PM -0800, Kevin Dalley enlightened us: >> Some machines which I back up are occasionally put to sleep. I have a >> few options: >> >> I could try hard to keep the machines from going to sleep, but any >> user can put some of the machines to sleep. >> >> I could ignore the problem, and skip backing up machines which are >> asleep. >> >> I could use wakeonlan to wake up all of the machines which are subject >> to narcolepsy. My cron job could easily run wakeonlan for all of the >> machines before amdump starts. This will usually make the estimates >> run correctly. The dump itself may fail if the machines automatically >> sleep. Both dump and estimate are subject to failure if people put the >> machine to sleep, but this is probably less of a worry. >> >> Does amanda have a method of automatically running wakeonlan, or the >> equivalent? What do other people do? > > Most people would either make it part of their cron job, or use a wrapper: > > http://www.amanda.org/docs/howto-wrapper.html > > Matt > > -- > Matt Hyclak > Department of Mathematics > Department of Social Work > Ohio University > (740) 593-1263 > -- Kevin Dalley [EMAIL PROTECTED]
Re: Is automatic wakeonlan possible?
Oops. I misread the position of the wrapper. Since the wrapper described on http://www.amanda.org/docs/howto-wrapper.html runs on the client, the wrapper won't work if the client is asleep. Kevin Dalley <[EMAIL PROTECTED]> writes: > Thanks for the suggestion. > > A wrapper (or part of the cron job) only handles part of the problem. > > If the machine has a timeout, say 1 hour, then either solution will > allow the estimate to be performed, but the backup itself may fail if > it is more than 1 hour between the estimate and the backup. > > Matt Hyclak <[EMAIL PROTECTED]> writes: > >> On Thu, Nov 10, 2005 at 06:00:59PM -0800, Kevin Dalley enlightened us: >>> Some machines which I back up are occasionally put to sleep. I have a >>> few options: >>> >>> I could try hard to keep the machines from going to sleep, but any >>> user can put some of the machines to sleep. >>> >>> I could ignore the problem, and skip backing up machines which are >>> asleep. >>> >>> I could use wakeonlan to wake up all of the machines which are subject >>> to narcolepsy. My cron job could easily run wakeonlan for all of the >>> machines before amdump starts. This will usually make the estimates >>> run correctly. The dump itself may fail if the machines automatically >>> sleep. Both dump and estimate are subject to failure if people put the >>> machine to sleep, but this is probably less of a worry. >>> >>> Does amanda have a method of automatically running wakeonlan, or the >>> equivalent? What do other people do? >> >> Most people would either make it part of their cron job, or use a wrapper: >> >> http://www.amanda.org/docs/howto-wrapper.html >> >> Matt >> >> -- >> Matt Hyclak >> Department of Mathematics >> Department of Social Work >> Ohio University >> (740) 593-1263 >> > > -- > Kevin Dalley > [EMAIL PROTECTED] > -- Kevin Dalley [EMAIL PROTECTED]
Re: Problems backing root partition with dump on CentOS
Jon LaBadie wrote: > > On Thu, Oct 27, 2005 at 10:25:43AM -0700, Chris Marble wrote: > > Jon LaBadie wrote: > > > > > > On Wed, Oct 26, 2005 at 11:53:16AM -0700, Chris Marble wrote: > > > > > > > > > > the /dev/sdb2 is mounted on / partition > > > > > but instead of using /dev/sdb2 it uses /dev/root for backup > > > > > here is the right of the two devices > > > > > > > > > > brw--- 1 root root 8, 18 avr 1 16:48 /dev/root > > > > > brw-rw 1 root disk 8, 18 avr 1 16:48 /dev/sdb2 > > > > > > > > Did you ever get a solution to this problem? I've done a chgrp disk > > > > and chmod g+r on /dev/root but that only helps until the next reboot. > > > > The other partitions are fine. > > > > Client is 2.4.5 and server is 2.4.4p1 > > > > Client OS is CentOS 4.2 > > > > > > On my FC3 /dev/root is a symbolic link to the root partition. > > > Might that be persistant across reboot? > > > > > My /dev/root isn't a sym link but a normal device file. No LVM in use > > either. I'm trying to figure out why amanda's backing up /dev/root instead > > of simply /. Here's the lines from disklist: > > Sakai / comp-root 1 > > Sakai /boot comp-root 1 > > Sakai /usr/local comp-root 2 > > Sakai /varcomp-root 2 > > > > Lastly lines from sendsize and sendbackup showing successes and failures: > > sendsize.2005102602.debug:sendsize[3765]: time 0.003: calculating for > > device '/dev/root' with 'ext3' > > sendsize.2005102602.debug:sendsize[3765]: time 0.003: running > > "/sbin/dump 0Ssf 1048576 - /dev/root" > > sendsize.2005102602.debug:sendsize[3765]: time 0.028: DUMP: Cannot > > open /dev/root > > sendsize.2005102702.debug:sendsize[3634]: time 0.007: calculating for > > device '/dev/root' with 'ext3' > > sendsize.2005102702.debug:sendsize[3634]: time 0.007: running > > "/sbin/dump 0Ssf 1048576 - /dev/root" > > sendbackup.20051027001751.debug:sendbackup: time 0.098: dumping device > > '/dev/root' with 'ext3' > > sendbackup.20051027001751.debug:sendbackup: argument list: dump 0usf > > 1048576 - /dev/root > > sendbackup.20051027001751.debug:sendbackup: time 0.104: 93: normal(|): > > DUMP: Dumping /dev/root (an unlisted file system) to standard output > > > > You see that amanda is asking for information on /dev/root rather than > > simply / > > Just as a workaround you might try the device name in > your disklist rather than the starting directory. Amanda > will still have to do some mapping, but it will be > device->directory rather than the current directory->device. > Shouldn't be needed, but might work better in this situation. Thanks for the suggestion. That's become my solution. Backing up /dev/sda2 (or whatever) instead of /. The line is /etc/fstab is: LABEL=/ / ext3defaults1 1 This reminds me of a similar problem many years ago with amanda where people had to install the advfs patch to handle that syntax in /etc/fstab. This happens to me with both CentOS and RedHat EL 4 installations. -- [EMAIL PROTECTED] - HMC UNIX Systems Manager My opinions are my own and probably don't represent anything anyway.
Re: is excluding /usr/local/var/amanda a bad idea ?
Stefan G. Weichinger wrote: The metadata on my testmachine is about 1.2 MB in size ok, other installations will exceed this but I think it should not be much of a problem. Correction on this: I took the data of a small test-config, the metadata of my productive configuration sums up to about 50 MB in tgz-format. Stefan.
Re: is excluding /usr/local/var/amanda a bad idea ?
Gene Heskett wrote: My method simply waits till amdump is done and has returned to the script that launched it, at which point the script then launches a second script that tars up all this stuff and appends it to the tape. It could be all in one script I guess, but I tend to scratch individual itches with seperate scripts. :) To me, this is the best option. And anyone who wants to weed the trash stuff out of my scripts is welcome to do so as eventually I'd like to see this added to the amanda distribution, a super-wrapper for amdump if you will. As already mentioned I think it would be preferable to get that into amdump itself. amanda-hackers-topic, I assume. Whats missing in the overall function is a method of communicating back to amdump, how much of a space cushion is needed in order to have room on an otherwise full tape for these tarballs. If amdump does that job, it might talk to itself ;-) What they do now is autoconfigure how it runs according to what it was called at invocation time, all the names are links to one (or more) scripts depending on what it needs to do, dump or flush. Beyond that, everything else is hard coded, but could be put into cli arguments or a .config file to make it a bit more universal. But once I had it working, I have this tendency to let something thats working alone so I don't break it again. :) I also have some scripts that make the automatic generation of a vtape setup quite easily done if anyone is interested in those. They aren't "pretty" either, but they worked for me. :) *sigh* I read this ashamed, as I already had started cleaning up those scripts back then. One more todo to do. Greets, Stefan.
ammkvtapes.sh
As I mentioned in another thread some minutes ago, I have done some
generalization-work on a script by Gene Heskett, which he sent to me
back in 2004.
This script is intended to help generating the necessary structures for
a vtape-setup, creating the various virtual tapes and slots etc.
I dug up my latest version and post it here without further testing,
please only use it after you have read the code.
Create the config-dir for your new vtape-config and set the parameters
in amanda.conf accordingly.
After that you run
ammkvtapes.sh
and the script should read the necessary parameters out of your amanda.conf.
As always, patches welcome.
Thanks again to Gene for the first script,
Stefan.
#!/bin/sh
#
## ammkvtapes.sh
## tool which creates the necessary directory-structure for the usage
## of the chg-disk tapechanger with AMANDA
##
## ammkvtapes reads various parameters out of amanda.conf and uses them
## to create the correct number of vtapes in the given vtape_dir
##
## First version by Gene Heskett
## Generalization and further improvements by Stefan G. Weichinger
## 2004
#
# Check for parameter, echo Usage-text
if [ -z $1 ]
then
echo "Usage: ammkvtapes.sh [-f] "
exit
fi
# Check, if force-flag is set, set config-string accordingly
case $1 in
-f)
FORCE_DEL=1
CONFIG=$2
;;
*)
FORCE_DEL=0
CONFIG=$1
;;
esac
# get path to amgetconf
AMGETCONF=`which amgetconf`
# get path to amlabel
AMLABEL=`which amlabel`
# check if chg-disk is used in this config
TPCHANGER=$($AMGETCONF $CONFIG tpchanger)
echo "TPCHANGER : " $TPCHANGER
if [ $TPCHANGER ]; then
if [ $TPCHANGER = "chg-disk" ]; then
echo "Configuration uses $TPCHANGER - OK"
else
echo "Parameter tpchanger set to $TPCHANGER, has to be chg-disk
- EXIT"
exit
fi
else
echo "Parameter tpchanger not set for configuration $CONFIG - EXIT"
exit
fi
# get dir where configs are located
# e.g. /usr/local/etc/amanda
CONF_DIR=$($AMGETCONF $CONFIG build.config_dir)
# build dir-string for current config
# e.g. /usr/local/etc/amanda/daily
CUR_CONF_DIR="$CONF_DIR$CONFIG"
# get the path of the vtape-directory
# e.g. /amandatapes
VTAPE_DIR=$($AMGETCONF $CONFIG tapedev)
# strip away the file
VTAPE_DIR=${VTAPE_DIR#file\:}
# get number of tapes
NUM_TAPES=$($AMGETCONF $CONFIG tapecycle)
# get Label-string
LABEL_STR=$($AMGETCONF $CONFIG labelstr)
# get the dumpuser
DUMPUSER=$($AMGETCONF $CONFIG dumpuser)
## DEBUG-echos
echo "FORCE : " $FORCE_DEL
echo $AMGETCONF
echo "CONFIG : " $CONFIG
echo "CONF_DIR : " $CONF_DIR
echo "CUR_CONF_DIR : " $CUR_CONF_DIR
echo "VTAPE-DIR : " $VTAPE_DIR
echo "NUM_TAPES : " $NUM_TAPES
echo "LABEL_STR : " $LABEL_STR
if [ -d $VTAPE_DIR ]; then
echo "found existing tape-dir at " $VTAPE_DIR
if [ $FORCE_DEL = "1" ]; then
echo "ATTENTION - force-flag set !!!"
# rm -fR $VTAPE_DIR
else
echo "leaving stuff unchanged - no force-flag set"
fi
fi
TAPELIST="$CUR_CONF_DIR/tapelist"
if [ -d $TAPELIST ]; then
echo "found existing tapelist: " $TAPELIST
echo "Please remove this file manually if you are sure this is
what you want."
exit
fi
touch $TAPELIST
for n in 1 to $NUM_TAPES
do
mkdir -p $VTAPE_DIR/slot${n}
chmod -v 750 $VTAPE_DIR/slot${n}
rm -f $VTAPE_DIR/data
ln -s $VTAPE_DIR/slot${n} $VTAPE_DIR/data
$AMLABEL $CONF daily${n} slot ${n}
done
## Give the Vtapes to the dumpuser
chown -R $DUMPUSER $VTAPE_DIR
## rm the link amlabel leaves
rm $VTAPE_DIR/data
## reset it for slot 1
amtape $CONFIG slot 1
echo
echo "created $NUM_TAPES slot-dirs successfully."
echo
## show it to the user (me)
ls -l $VTAPE_DIR
## show all the vtapes by using amtape
amtape $CONFIG show
echo "OK"
---
Re: trouble with AMANDA server (taper) on amd64 using Debian/AMD64/Sarge
On Mon, 2005-11-14 at 15:36 -0500, James D. Freels wrote: Hello folks ! I have been using AMANDA now for several years and find it to be a superb backup tool. I just converted one of my AMANDA backup servers (fea5) from an Alpha 64-bit machine running Debian/Sarge to a new AMD64 64-bit machine also running Debian/Sarge. When writing to the tape using the /usr/lib/amanda/taper component of the amanda-server package in 64-bit mode, the machine fails, and eventually hangs to the point of being unusable. However, if I issue the same commands in the chroot 32-bit mode environment, it works fine. Write now, I basically have to run the server in 32-bit mode and the client in 64-bit mode. I would much prefer running the entire system cleanly in 64-bit mode. I am including the taper error messages here for reference. Has anyone else experienced this problem ? If so how can it be corrected ? I have already issued a bug report to the Debian developers, but I have not obtained a solution and log files removed hoping my entry will actually make it to the mailing list -- James D. Freels, Ph.D. Oak Ridge National Laboratory [EMAIL PROTECTED]
Re: can not back up client
The version of tar that is installed on the debian client is 1.13.25 When I manually create and extract the tar I do not get any errors. From: Jon LaBadie <[EMAIL PROTECTED]> Reply-To: amanda-users@amanda.org To: amanda-users@amanda.org Subject: Re: can not back up client Date: Tue, 15 Nov 2005 12:03:05 -0500 On Tue, Nov 15, 2005 at 09:41:04AM -0500, Rodney Johnson wrote: > I am able to successfully back up Solaris and Red Hat clients. I can not > back up the Debian client. The server is running on Red Hat. > > This is the error message in the log: > > STRANGE dumper 0 [sec 3057.777 kb 9339610 kps 3054.4 orig-kb > 9749540] > sendbackup: start [ level 0] > sendbackup: info BACKUP=/bin/tar > sendbackup: info RECOVER_CMD=/bin/tar -f... - > sendbackup: info end > ??free(): invalid pointer 0x8063fd8!| Total bytes written: 9983528960 > (9.3GB, 3.1MB/s) > sendbackup: size 9749540 > sendbackup: end > > Any help would be greatly appreciated. > My first guess is that is a message from tar. The tar is running on the Debian client. What version has Debian supplied? If you manually do the "RECOVER_CMD" on the client do you get an error? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
