Backup client (old)
See Getting Started with Amanda instead
Amanda client configuration file
Amanda uses optional Amanda client configuration file to perform recovery using secure API. . The client configuration file is called amanda-client.conf(5). This file syntax is similar to the server configuration file - amanda.conf(5).
This file is located in /etc/amanda directory. Amanda configuration specific client configuration files are located in /etc/amanda/<amanda configuration name> directory.
This file is read by various client programs and amrecover(8) command.
All amrecover(8) parameters such as amanda index server name, amanda tape server name, authentication method for communicating with the server, and SSH keys are stored in this file. Client specific parameters such as amandates - backup state file for GNUTAR backup program, gnulist_dir are also specified in the configuration file.
Following is the order of precedence is used by Amanda to determine a configuration parameter value on the Amanda client:
- Initialized by compile-time default values.
- Overidden by /etc/amanda/amanda-client.conf
- Overidden by /etc/amanda/<amanda configuration name>/amanda-client.conf
- Overidden by -o options (or command line options in case of amrecover command)
Backup programs
GNUTAR
Amanda supports backup made using GNU tar command. To use tar as the backup program, define a dumptype definition with program name set to "GNUTAR"
dumptype tar-client { .... program "GNUTAR" }
GNU tar does not maintain state information about the backups similar to dump command. Amanda maintains a file called amandates on the client. The location of the amandates file can be overridden by the value specified in the client configuration file. The structure of the file is similar to /etc/dumpdates and performs the same function. It contains filesystem/directory
name, dump level and dump date.
If the directory containing amandates is not writable by the backup user (such as amandabackup) on the client, administrator will have to create an empty file amandates file which must be writable by the backup user.
Amanda estimates the size of the dump performed by the tar command.
The tar command traverses the directory hierarchy and reads the files. In order to read the files, it must run as "super user" on the client. The amanda commands "calcsize" and "runtar" are installed as setuid "root" so that it can reads the files and directories.
Unlike dump command, GNU tar allows users to backup sub-directories. It also allows administrators to exclude and include files in the backup. Amanda uses --exclude and --exclude-from tar operations for this feature. Please see Excluding lists section for more information on excluding files from backup.
Amanda creates tar snapshot file when a dump level 0 is performed. The tar snapshot file is usually created in /var/lib/amanda/gnutar-lists/ directory on the client. It contains backup timestamp and list of files backed up. This file is used when incremental dumps are done in the future. Amanda uses --listed-incremental gnu tar option to create the file.
Use GNU tar 1.15 or later version on Amanda clients. Earlier versions of GNU tar (some versions of 1.13 and 1.14 are known to have problems. The backups taken using these versions cannot be restored.
DUMP
Amanda uses native filesystem dump program to do filesystem backups. Dumptype definition in amanda.conf should have program set to "DUMP":
dumptype dump-client { .... program "DUMP" }
Amanda automatically runs the native filesystem dump program. It will run xfsdump for XFS filesystems, vxdump for Veritas filesystems, vdump for AdvFS (Tru64), dump for other filesystems.
DUMP program only works for whole filesystem backups and it is not possible to exclude files.
Amanda uses /etc/dumpdates file (created by dump program) for tracking backups. Filesystem name, Date stamp and last dump level are kept in this file.
Which backup program for filesystems is better?
This is a common question. See FAQ:Which backup program for filesystems is better? for a detailed answer.
Windows client
Installation
Amanda is able to back up Microsoft Windows filesystems either by using Samba, a package that implements a SMB client and server for Unix or by using Zmanda Windows Client, native Win32 Amanda client.
Instructions for using Samba
After building and installing Samba, Amanda must be configured with support for smbclient. Amanda will automatically find smbclient if it is in your PATH when you run configure, or you may add the following argument:
--with-smbclient=/full/path/to/smbclient
Configuration
After Amanda client and Samba are installed, the only difference between a Unix client/disk and PC client/share is in how the backup disks are specified in the disklist. For each PC share, the entry lists the 'samba server' host (where the patched Samba software is installed) and the disk field is the share name. The remaining fields are like any other DLE.
A user must be created on the PC with full access rights (read/write) to the share. Amanda, via the Samba server, will connect to the PC via this user. If the user does not have full access, incremental backups will not work and the whole share will be backed up every time (the archive bits are never reset).
The file /etc/amandapass must be created by hand. It contains share name to user name, password and workgroup mapping. Each line consists of two or three fields, separated by whitespace:
- Share name followed by optional directory. You have to use forward slashes (/), not backslashes (\). This must match the disklist entry exactly (case sensitive). This may be asterisk (*) to match all remaining shares for this Samba server. The first match in the file is used, so specific entries must be listed first. The directory is appended to the share name as full MS network path. Like //thepc/c$/mydir. No blanks are allowed in directory!
- User name and password. Separated by a percent sign (%). See the description of the -U option in the manpage of smbclient. No whitespace is allowed in either the user name or password.
- Workgroup (optional).
This file must be owned by the Amanda backup user and disallow world access privileges. Blank lines are ignored. A "#" on a line at the start of a field (including start of line) causes the rest of the line to be ignored.
Example configuration
The Amanda client software and Samba are installed on host "Amandaclient"(unix client). A share to be backed up called "backupc" is on PC "thepc". The share will be accessed via PC user "bozo" and password "f00bar" and does not require a workgroup.
The entry in the file disklist is:
Amandacient //thepc/backupc nocomp-user-gnutar ^ samba installed unix host ^ pc host and share name ^ dumptype must include the tar option
In /etc/amandapass on the machine 'Amandaclient':
//thepc/backupc bozo%f00bar
If smbclient requires a workgroup specification (-W), you may add it as a third argument in the line in the file /etc/amandapass :
//thepc/backupc bozo%f00bar NTGROUP
This will cause smbclient to be invoked with -W NTGROUP.
An example dumptype in amanda.conf would be:
define dumptype nocomp-user-gnutar { program "GNUTAR" comment "user partitions dumped with tar and no compression" options no-compress priority medium }
Essentially, the entry in disklist is a 'pseudo-disk' which contains all the relevant information needed by smbclient to backup the disk, but in a way that is compatible to Amanda.
amcheck does a quick check to see if smbclient exists and tries to connect to the PC clients. It also checks for the existence and permissions of /etc/amandapass.
Bugs and notes
- Samba will not back up open files (such as PAGEFILE.SYS and registry files) nor Access Control List data. Furthermore, at restore time, smbclient is unable to overwrite read-only files. Hence, AMANDA+Samba is not a perfect solution for backing up (restoring, actually) system disks.
- Samba does not use the Windows Backup API, so configuring the AMANDA backup user as a member of group backup on the Windows host is useless. You will probably have to configure it as an Administrator, and make sure it can read and change permission of all files in the share.
- It seems impossible to detect when a per-user based login fails, e.g. the username doesn't have sufficient access. It connects but cannot see any files (e.g. backups do nothing). The selfcheck code isn't particularly robust in this area either, so you may get no warnings when a disk isn't being backed up. Just check to see that level 0 dumps are bigger than 64K, otherwise it means the backup was empty.
- The estimate and totals are probably a bit off since tar pads to the nearest 512 bytes after each file (I think). Not sure how much of a problem this is.
- smbclient only supports excluding a single file from the command line, not a file of patterns like GNU tar. So "exclude" is supported from a dumptype but not "exclude list".
- Also the new option "exclude append" is not yet supported with smbclient.
- Since Samba-3.0.2a smbclient supports multiple exclusion-patterns. It is one of the "Ongoing Projects" to make use of this in AMANDA. Refer to http://www.amanda.org/ongoing.php for details.
- The size estimate calculation does not use the same method as the dump, so it may be inaccurate. It also does not support any type of exclusion ("exclude" is ignored). Things are done this way because doing a simulated dump to /dev/null, like other dump programs, would take forever with current implementations of Samba.
- If you compile with support for smbclient, GNU-tar support is automatically enabled. If you aren't using the GNU-tar part, you may get warnings about the availability of /usr/local/bin/gtar (or whatever it was compiled with). These may safely be ignored, unless you enable index generation for those filesystems.
Client side encryption
As of Amanda 2.5.0, native server and client data encryption is available. See amanda.conf for details.
pre and post- backup scripts (wrappers)
Bert de Ridder's suggestions
This is a mini-howto explaining how to control other running tasks on a server where the AMANDA software is used to backup data.
Problem : Lots of software is picky about their datafiles being backed up while the files are in use. It sometimes is even necessary to know the state of the datafiles at the moment of backup so that when restoring you know exactly *what* you are restoring. And most of the time there are dependencies between the datafiles as well (for instance, the pure datafiles and the controlfiles of an Oracle database.)
The solution is actually quite simple; you just use a custom made backupscript instead of the standard tar command. Inside this tar command, you do some necessary processing before executing the tar command and - if necessary - do some more processing. This way, you can easily stop an Oracle database, tar the files, send them to the tape server and restart the Oracle database. This of course is just an example, anything you can do in a shell script can be done.
- Create the script: This is the most important step, this script is the work horse of the solution. I've called it /bin/amandatar. You can call it whatever you want though. It's a Perl script, it may not be very pretty code, but it does the job. In the script, an example is given for the backup of a Lotus Notes Domino server.
#!/usr/bin/perl
# Tar wrapper for Amanda's tar. # use Getopt::Long qw(:config pass_through); # Obtain directory and file information from the command line.
$result = GetOptions ( 'directory=s' => \$dir, 'file=s' => \$file );
# Check whether Amanda wants to do some administrative task (eg. indexinfo # or obtain the number of bytes to be backed up) # if file = /dev/null it's an administrative task and most of the time, no extra # processing is necessary.
# What you see here is just a log of the backup start time, and – more important # the stopping of the domino server
if ( $file ne '/dev/null' ) { if ( $dir eq '/local/notesdata' ) { system "echo 'Start backup notes at ' >> /var/lib/amanda/runtime" ; system "date >> /var/lib/amanda/runtime"; system ( "/etc/init.d/domino stop >> /var/lib/amanda/runtime" ); } }
# The command line is being 'reconstructed'. Necessary because the GetOptions # call above has stripped the file and directory information. # This is what I meant with 'ugly' code ;-)
while ( $ARGV[0] ne ) { $val = $ARGV[0] ; unshift ( @NEWARGV, $val, ) ; shift; }
while ( $NEWARGV[0] ne ) { $val = $NEWARGV[0] ; unshift ( @ARGV, $val ) ; shift @NEWARGV; }
if ( $dir ne ) { unshift ( @ARGV, '--directory', $dir ); } if ( $file ne ) { unshift ( @ARGV, '--file', $file ); }
if ( $file ne '/dev/null' ) { system "echo 'Backing up directory ' $dir >> /var/lib/amanda/runtime" ; }
# And finally make sure tar is called :-) # (path may differ on your installation) unshift ( @ARGV , "/bin/tar" ) ;
system ( @ARGV ) ;
# Postprocessing # # If Notes backup was requested, restart the server. # Log the backup end time. #
if ( $file ne '/dev/null' ) { if ( $dir eq '/local/notesdata' ) { system ( "/etc/init.d/domino start >> /var/lib/amanda/runtime" ); system "echo 'End backup notes at ' >> /var/lib/amanda/runtime" ; system "date >> /var/lib/amanda/runtime"; } }
exit 0;
# End script
On some systems it may be necessary to setuid root the script.
- Rebuild AMANDA so that it uses your newly created script.
Download the sources, untar them to a directory. I'm sure there are lots of documents already available on how to do this, so I won't go into too much detail. (Refer to Amanda Installation Notes).
Fast Path:
/usr/local/src # tar -xvzf amanda-source.tar.gz /usr/local/src # cd amanda-version /usr/local/src/amanda-version # ./configure \ --with-user=amanda \ --prefix=/usr/local \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --libexecdir=/usr/lib/amanda \ --with-configdir=/etc/amanda \ --with-group=disk \ --with-gnutar=/bin/amandatar \ --with-gnutar-listdir=/var/lib/amanda/gnutar-lists \ --with-tmpdir=/tmp/amanda \ --with-smbclient=/usr/bin/smbclient \ --mandir=/usr/local/man
Here, it may be necessary to adjust some paths to match your installation. This setup works on SuSE Linux (also SLES) and MacOSX although you may have to use another binary tar.
As you see, you may also "replace" the smbclient if necessary. I haven't yet tested it though. I'll leave it as an exercise for the reader <g>.
/usr/local/src/amanda-version # make /usr/local/src/amanda-version # make install
Now proceed as with a "normal" installation.
Paul Bijnens's suggestions
Currently, there is no direct support to run a program before or after a backup on a client. But there is an easy workaround by using a wrapper for GNU-tar that does the additional tasks.
Let's suppose you want to stop a database before the backup, and start it up again when the backup is finished. You have already two scripts "shutdb" and "startdb" to shutdown and startup the database.
First you have to configure AMANDA on the client to use the gnutar-wrapper instead of the real GNU-tar:
./configure ... --with-gnutar=/usr/local/bin/amgtar ...
and re-compile AMANDA. The program "amgtar" can be a simple link to the real GNU-tar-binary on clients that don't need special handling, or it can be a script. Because "configure" tests the flavor of gnutar, you must have created that link, or have the wrapper installed before executing "configure". You can change the link into a real wrapper afterwards.
AMANDA expects that the bytestream on stdout is the backup image, and the bytestream on stderr are messages. The stderr messages are filtered against a known set of strings, and anything unexpected is flagged as "STRANGE" in the AMANDA report. The return-codes of the program should be the same as the return-codes of GNU-tar:
- 0 = ok (backup image will be put on tape)
- 1 = not ok (backup image will not be put on tape, same level will be tried next time).
The arguments passed to the program are pretty static (see in the sources client-src/sendbackup-gnutar.c, line 483). To decide if you need to stop/start the database you have to check if:
- this run makes a backup and not a restore: look for "--create"
- this is not an estimate run: look for "--file /dev/null" (estimate) or "--file -" (real run)
- this run is for the database directory: look for "--directory /my/data/base"
In all other cases, we just pass the args and run the real GNU-tar.
Here is an example script in Bourne shell:
#!/bin/sh # # uncomment next block to follow the flow # LOG=/tmp/amanda/mytar.debug # date >> $LOG # echo "$@" >> $LOG # if [ "$3" = "/dev/null" ] # then echo "Estimate only" >> $LOG # else echo "Real backup" >> $LOG # fi # - Avoid output to stdout! (the backup stream by tar) # - Any output to stderr is flagged as "strange" by amanda # and may be used to pass error messages into the report if [ "$1" = "--create" -a "$3" = "-" -a "$5" = "/my/dir" ] then # echo "/my/dir: want to execute some progs first" >>$LOG /usr/local/bin/shutdb thedb >&2 /usr/local/bin/gtar "$@" rc=$? # echo "Finished the real backup; some postprocessing" >>$LOG /usr/local/bin/startdb thedb >&2 exit $rc else /usr/local/bin/gtar "$@" fi
Here is an example script in perl:
#!/usr/bin/perl -w use Getopt::Long qw(:config pass_through); my @saveopts = @ARGV; GetOptions ( 'create' => \$create, 'directory=s' => \$dir, 'file=s' => \$file, ); @ARGV = @saveopts; my $postproc = 0; if ($create && $dir eq '/my/data/base' && $file ne '/dev/null') { system '/usr/local/bin/dbshut thedb >/tmp/amanda/dbshut.debug >&2'; $postproc = 1; } unshift(@ARGV, "/usr/local/bin/gtar"); system @ARGV; my $rc = $? >> 8; if ($postproc) { system '/usr/local/bin/dbstart thedb >/tmp/amanda/dbstart.debug >&2'; } exit $rc;
Chris Hoogendyk's Example
As of 2.5.1p3, there is no explicit support for putting a wrapper around dump; that is, there is no "--with-dump=..." comparable to the "--with-gnutar=..." However, a similar result can be achieved.
First, create a directory for wrappers and similar tools in the amanda home directory. For, example, /usr/local/etc/amanda/tools. Initially, for the configure, create symlinks within this directory pointing to gtar and ufsdump (I'm writing from the perspective of Solaris). This is so that configure can find them here and test their behaviour. After building amanda, the symlinks can be replaced with the wrapper scripts.
Second, edit the amanda configure script. Locate the line where SYSPATH is assigned a path list, and prepend that path list with "/usr/local/etc/amanda/tools:". This will ensure that configure looks here first so that amanda will be built to use the gtar and ufsdump in this directory.
Then proceed to build amanda, or the amanda client, as you normally would. If you are going to use a wrapper around gtar, use the "--with-gnutar=/usr/local/etc/amanda/tools/gtar". Since this option is built into configure, it's defaults may bypass what we are trying to do with SYSPATH if we don't use it.
Finally, remove the symlinks and move the wrappers into place.
The code for the wrapper script is a bit long. The reason I wanted to have a wrapper for ufsdump was to use file system snapshots (fssnap on Solaris 9). Previous experience scripting backups on Solaris 9 had turned up some specific issues that had to be dealt with. For one, the snapshot has to be on a different partition than the file system that it is a snapshot of. For another, if the snapshot is of the root partition, there is a conflict with real time processes (xntpd, for example). This requires shutting down any such processes, taking the snapshot, and then starting them back up again. All of this is taken care of in the script that follows. Additionally, there is a fair bit of commentary and debugging code in the script. I have left that in, because, if changes in amanda ever broke the script, it would be useful to be able to easily see what was happening.
Note that, as in the gnutar examples above, amanda should see the return code, stdout, and stderr all just as though this were nothing but ufsdump running. Any additional output that is allowed to go to stdout will break the dump, and any output that is allowed to go to stderr will be flagged by amanda as "STRANGE".
Note also that this script does not deal with issues related to database dumps. Those can be dealt with using a separate cron that dumps them to a partition that will be backed up, or by using a gnutar wrapper as described in the above examples. Also, in a related issue, while snapshots protect the backup from changes during the course of the backup, they do not guarantee the consistency of the file system if there are programs actively modifying the file system when the snapshot is initiated. In other words, if a program is juggling data in memory, and has only part of it written out when a snapshot is initiated, there are circumstances where the backed up data for that program may be inconsistent within itself. The more quiescent a file system is, the better.
#!/bin/ksh # Concept follows the gnutar examples in the online amanda docs or zmanda wiki, but ... # This is very specific to Solaris 9 with fssnap & ufsdump and is based on code # I developed for "tapewriter" (my own backup program) before we adopted amanda. # If you use this code on another site, it is your responsibility to read it carefully, # and be sure that it works appropriately for your site (or for Solaris 8 or 10). # -- 2/7/2007, Chris Hoogendyk. # [email protected] # Set DEBUG to 0,1 or 2 to get debugging output. DEBUG=2; # D is a format for time stamps in the debug file. D="%b %e %T"; # Debugging output goes to LOGFILE (this happens to be in the same directory as the script). LOGFILE="/usr/local/etc/amanda/tools/debug.log"; # Following is where fssnap is going to put the snapshots. SNAPSHOT="/usr/local/etc/amanda/snapshots"; # NOTE: A snapshot cannot be on the partition that it is a snapshot of. Therefore, if the directory # $SNAPSHOT is not a partition of its own, we won't be able to snapshot /usr/local in it. To get # around this, if the partition is /usr/local/, there must be a symlink named "usrlocal" (strip /'s) # linking to space on another partition (e.g. /snapshots or /var/snapshots) that can be used to # snapshot /usr/local/. Code further below will assume this has been done. # There are a couple of things we can't do without being root, but this script runs as amanda. # So, we need sudo. You must configure sudo to allow amanda to run xntpd, fssnap & ufsdump with # exactly the following paths (edit to fit your system). SUDO="/usr/local/bin/sudo"; XNTPD="/etc/init.d/xntpd"; FSSNAP="/usr/lib/fs/ufs/fssnap"; UFSDUMP="/usr/lib/fs/ufs/ufsdump"; # Grab our process ID for debugging, and format it so the debug log lines up more neatly. PID=$$; typeset -R6 PID; # All the debug lines are set up as a single line, bracketed by the if...fi. if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - parameter list: $@" >> ${LOGFILE}; fi # NOTE: Based on trial results from above debug line, # amanda 2.5.1p3 calls ufsdump (or this script) as follows: # ufsdump 0Ssf 1048576 - /dev/rdsk/c0t0d0s3 # ufsdump 1Ssf 1048576 - /dev/rdsk/c0t0d0s3 # ufsdump 0usf 1048576 - /dev/rdsk/c0t0d0s3 # So it does a couple of estimates and then does the actual dump. # Coming into this script, $#=4, $1=options, etc. # - Avoid output to stdout! The backup stream for ufsdump goes back to amanda via stdout. # - Any output to stderr (other than ufsdump's standard commentary) is flagged as "STRANGE" by # amanda and may be used to pass error messages into the report. # $1 is the option list for ufsdump, if it contains "S", then this is just an estimate. if [[ $1 = *S* ]]; then # Not actually dumping, just estimating, so just do it. ${UFSDUMP} "$@"; STATUS=$?; else # Actually doing a dump, so get a snapshot, dump it, then release it. # However, cannot snapshot (or log) a read-only file-system (such as our local /archive). RDEV=$4; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - RDEV=\"${RDEV}\"" >> ${LOGFILE}; fi P=`grep -v '^#' /etc/vfstab | grep ${RDEV} | awk '{ print $3 }'`; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - P=\"${P}\"" >> ${LOGFILE}; fi if /usr/sbin/mount -v | grep " ${P} " | grep "read-only" > /dev/null; then # Can't do snapshot -- read-only -- so just do ufsdump. ${UFSDUMP} "$@"; STATUS=$?; else # "Bug" wrt realtime modules and code page locking causes fssnap on / to fail. # Solution is to stop & start such modules around fssnap. # The only real time module we are running is xntpd. if [[ "${P}" = "/" ]]; then if (( ${DEBUG} >= 1 )); then echo "`date +\"${D}\"` [${PID}] - stopping xntpd" >> ${LOGFILE}; fi ${SUDO} ${XNTPD} stop; fi # Determine what partition snapshots are on. WHICHPART=`df -k ${SNAPSHOT} | grep "%" | awk '{ print $6 }'`; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - WHICHPART=\"${WHICHPART}\"" >> ${LOGFILE}; fi if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - initiating snapshot" >> ${LOGFILE}; fi if [[ "${P}" != "${WHICHPART}" ]]; then # Snapshots are on different partition, which is OK, so just do it. WHICHSNAP=`${SUDO} ${FSSNAP} -o raw,bs=${SNAPSHOT},unlink ${P} 2>>${LOGFILE}`; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - WHICHSNAP=\"${WHICHSNAP}\"" >> ${LOGFILE}; fi else # Snapshots are on same partition. Sysadmin has to have set up a link to another partition. # If, for example, /usr/local/ contains snapshots, then link snapshots/usrlocal to another partition. PALPH=`echo ${P} | tr -d "/"`; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - PALPH=\"${PALPH}\"" >> ${LOGFILE}; fi WHICHPART=`df -k "${SNAPSHOT}/${PALPH}" | grep "%" | awk '{ print $6 }'`; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - WHICHPART=\"${WHICHPART}\"" >> ${LOGFILE}; fi WHICHSNAP=`${SUDO} ${FSSNAP} -o raw,bs=${SNAPSHOT}/${PALPH},unlink ${P} 2>>${LOGFILE}`; if (( ${DEBUG} >= 2 )); then echo "`date +\"$D\"` [$PID] - WHICHSNAP=\"${WHICHSNAP}\"" >> ${LOGFILE}; fi fi if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - using ${WHICHSNAP} on ${WHICHPART}" >> ${LOGFILE}; fi # Now, if it was root partition, we can restart realtime modules (xntpd for us). if [[ "${P}" = "/" ]]; then if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - restarting xntpd" >> ${LOGFILE}; fi ${SUDO} ${XNTPD} start; fi # Set up a new parameter list for ufsdump with raw device for dumpdates and snapshot for dumping. PLIST="${1}N ${2} ${3} ${RDEV} ${WHICHSNAP}"; if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - new parameter list: ${PLIST}" >> ${LOGFILE}; fi # Finally, proceed to ufsdump. # The following line was to test with just what was passed in. #${UFSDUMP} $@; # Catching stderr in the following line is useful during debugging, but amanda has to # have the output to stderr for successful backups, so the redirect has to be commented out. #${SUDO} ${UFSDUMP} ${PLIST} 2>>${LOGFILE}; ${SUDO} ${UFSDUMP} ${PLIST}; STATUS=$?; if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - ufsdump completed, status: ${STATUS}" >> ${LOGFILE}; fi sleep 120; if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - removing snapshot" >> ${LOGFILE}; fi ${SUDO} ${FSSNAP} -d ${P} > /dev/null 2>>${LOGFILE}; # Following should do nothing if snapshots have been deleted successfully. SNAPSGONE=`${SUDO} ${FSSNAP} -i 2>>${LOGFILE}`; if [[ "x${SNAPSGONE}" != "x" ]]; then if (( ${DEBUG} >= 1 )); then echo "`date +\"$D\"` [$PID] - check snapshots: ${SNAPSGONE}" >> ${LOGFILE}; fi fi fi fi exit ${STATUS}
Just an addendum 2 or 3 years after writing the above.
I just implemented this on another department's network. Since everything was identical, I just moved all the source over and went through all the same build and configuration steps. I thought I had it right, and the first backup went alright (it had to be all full backups), although there were some puzzling errors interspersed in the wrapper's debug.log.
Subsequent backups were getting mostly failures with a couple of successes. The debug.log had lots of instances of the error message “fssnap: ioctl: error 16: Device busy” when trying to initiate a snapshot. I had a lot trouble tracking this until I noticed a couple of things. The parameter list coming in to the wrapper never had an upper case “S” (for estimate). There were closely spaced instances of “0sf” followed by “1sf” for the same partition. The first would initiate a snapshot and a full dump, the second would try and fail with the above error message and then remove the associated snapshot, thus failing the first one. These should have been requests for estimates, coming in with “0SSsf” and “1SSsf”. Only later should there have been an actual request for a dump with “0usf”.
What this meant was that Amanda didn't get configured to work properly with the Solaris version of dump, i.e. ufsdump. I had gone through the “./configure && make && make install” and missed a necessary option the first time. After doing some trials, I had gone back and done it over (starting with a “make clean”) with the full set of options, but I had forgotten to swap out my wrapper so that Amanda could configure itself with ufsdump directly. After realizing this, I went back once more. In my /usr/local/etc/amanda/tools directory, I moved the wrapper and symlinked ufsdump. Then I did the whole “make clean && ./configure && make && make install”. Then I removed the symlink and put my wrapper back in place. Everything worked just fine and the errors went away.
It can get a little messy when you realize the Amanda can spawn a lot of processes, and there may be multiple instances of the wrapper running simultaneously. Hopefully, this example, with the error message, will save someone else some trouble.