Amanda Cheat Sheet

Config

The workings of Amanda all center around one or more config directories you set up We currently have only one configuration set up to dump all the workstations and it is called

all
All of the Amanda commands need the name of the config file so it knows how to handle your request. One item of interest is the tape device you are using for Amanda:

	# fgrep 'tapedev' /usr/local/amanda/config/all/amanda.conf
	tapedev "/dev/rmt/tps3d1nrvc"   # or use the (no-rewind!) tape device directly

you will need to know this to unmount tapes and do restores. One handy way to get this set correctly is to put something like this in the /bin/.cshrc file:

	setenv TAPE `grep tapedev /usr/local/amanda/config/all/amanda.conf | tr '"' ' ' | nawk '{print $2}'`

then the TAPE variable is set when you login as bin to do Amanda work.

Preparing a Tape

Before you can use a tape in Amanda you must label it. Put the tape in the drive you usually use for Amanda and get the label string from the config file so you give the tape a label that matches the pattern chosen for the config you are using. ie:

	# fgrep 'labelstr' /usr/local/amanda/config/all/amanda.conf
	labelstr "^ARCall[0-9][0-9]*$"  # label constraint regex:
	# amlabel all ARCall99

We label our tapes something like ARCall04 or ARCall999.

Preparing for an Amanda Dump

Amanda also provides a handy command to check and make sure things are correctly prepared for next dump. The following will check the server to make sure there is enough room on the holding disk to buffer the dumps before they are written to tape, and make sure the correct tape is in the drive:

	# /usr/local/amanda/bin/amcheck -s all
	Amanda Tape Server Host Check
	-----------------------------
	/export/backups/amanda/all: 8882376 KB disk space available, that's plenty.
	Tape ARCall152 label ok.
	NOTE: skipping tape-writeable test.
	Server check took 0.088 seconds.
	(brought to you by Amanda 2.3.0.4)

Errors from the above command are pretty self explanatory. Here are a few examples of what you might see:

	ERROR: cannot overwrite active tape ARCatRICE23.
		(expecting tape ARCatRICE24 or a new tape)
	ERROR: /dev/rmt/tps3d1nrvc: rewinding tape: Resource temporarily unavailable.
       		(expecting tape ARCall24 or a new tape)

This will check to see that all the clients are up and running and able to talk to Amanda:

	# /usr/local/amanda/bin/amcheck -c all
	Amanda Backup Client Hosts Check
	--------------------------------
	Client check: 46 hosts checked in 10.390 seconds, 0 problems found.
	(brought to you by Amanda 2.3.0.4)

Running an Amanda Dump

The version of Amanda we run uses the native Unix dump program to backup the filesystems. The following will do the nights dumps:

	# /usr/local/amanda/bin/amdump all

and send email to the people/alias listed in the config file. The output would look something like this:

	To: arc_amanda@arc.umn.edu
	Subject: AHPCRC AMANDA MAIL REPORT FOR April 28, 1999

	These dumps were to tape ARCall92.
	Tonight's dumps should go onto 1 tape: ARCall24.

	FAILURE AND STRANGE DUMP SUMMARY:
  	in7        / lev 0 FAILED [no estimate]

	STATISTICS:
                          	Total     Full    Daily
                       	-------- -------- --------
	Dump Time (hrs:min)       1:57     1:21     0:18 (0:07 start, 0:11 idle)
	Output Size (meg)       4043.0   3393.5    649.5
	Original Size (meg)     4043.0   3393.5    649.5
	Avg Compressed Size (%)    --       --       -- 
	Tape Used (%)             19.3     16.2      3.1 (level:#disks ...)
	Filesystems Dumped          57        5       52 (1:31 2:3 3:15 4:2 5:1)
	Avg Dump Rate (k/s)      559.1    713.2    262.6
	Avg Tp Write Rate (k/s)  698.3    712.8    631.1
	NOTES:
  	planner: Request to in7 timed out.
  	planner: Incremental of is:/usr/home bumped to level 4.
	DUMP SUMMARY:
                             	DUMPER STATS                  TAPER STATS
	HOSTNAME  DISK  L  ORIG-KB   OUT-KB COMP%  MMM:SS   KB/s  MMM:SS   KB/s
	----------------- -------------------------------------- --------------
	i0        /     1    38784    38784   --     0:58  666.0    0:25 1570.6
	i10       /     1    33632    33632   --     2:09  259.9    2:10  259.1
	i2        /     3     5120     5120   --     0:37  137.1    0:02 2903.5
	...
	(brought to you by Amanda version 2.3.0.4)

Flushing Amanda

Occasionally a normal dump won’t be run because Amanda can’t access the tape drive. This can be due to a variety of reasons, the drive might need cleaning and promptly kicked out tape the tape you thought you loaded. Or the scsi bus is getting reset. Or the wrong tape was loaded. Or the previous nights tape was never unloaded. Or…Anyway, Amanda will try to at least dump the incremental changes that occured on the system and put them on the holding disk. To get them onto tape, just mount the tape Amanda really wanted to write to and run a flush:

	# amadmin all tape
	The next Amanda run should go onto tape ARCall20 or a new tape.
	# amflush -f all
	Scanning /export/backups/amanda/all...
  	19990421: found non-empty Amanda directory.

	Flushing dumps in 19990421 to tape drive /dev/rmt/tps3d1nrvc.
	Expecting tape ARCall20 or a new tape.  (The last dumps were to tape ARCall19)
	Are you sure you want to do this? y
	taper: pid 11000 executable taper version 2.3.0.4
	taper: read label `ARCall20' date `19981223'
	taper: wrote label `ARCall20' date `19990421'
	taper: reader-side: got label ARCall20 filenum 1
	taper: reader-side: got label ARCall20 filenum 2
	taper: reader-side: got label ARCall20 filenum 3
	...
	taper: reader-side: got label ARCall20 filenum 18
	taper: DONE [idle wait: 2.002 secs]
	taper: writing end marker.

Locating the Right Tape for a Restore

Lets assume a user lost a file on machine ivie in the filesystem /usr/people. To find out what dump levels were done on what tapes on what days, use this command:

	# amadmin all find ivie /usr/people | head -6
	date        host disk lv tape  file status
	1999-08-31  ivie /usr/people 2  ARCatRICE178  19 OK
	1999-08-27  ivie /usr/people 2  ARCatRICE177  18 OK
	1999-08-26  ivie /usr/people 1  ARCatRICE176  12 OK
	1999-08-25  ivie /usr/people 1  ARCatRICE175  14 OK
	1999-08-24  ivie /usr/people 0  ARCatRICE174  50 OK

Performing a Local Restore

Now that you know what tape to load and restore from, you simply need to load the tape on the usual Amanda device. Since Amanda writes a tape label file on the front of a tape, and then a series of files for each filesystem it dumps, it is easier to restore if you use Amanda commands to extract the info from it.

	# mkdir /tmp/restore ; cd /tmp/restore
	# amrestore -p /dev/rmt/tps0d5nrv ivie /usr/people | restore -ivf - .
	Verify tape and initialize maps
	amrestore:   0: skipping start of tape: date 19990610 label ARCall122
	amrestore:   1: skipping kosh._.19990610.1
	amrestore:   2: skipping lupo._.19990610.1
	amrestore:   3: skipping s99._.19990610.1
	...
	amrestore:  54: restoring ivie._usr_people.19990610.0
	Dump   date: Thu Jun 10 20:56:01 1999
	Dumped from: the epoch
	Level 0 dump of / on ivie.arc.umn.edu:/dev/sd0s1a
	Label: none
	Extract directories from tape
	Initialize symbol table.
	restore >

Performing a Local XFS Restore

Beware! On an SGI there are several different types of filesystems. The EFS filesystem is the native one that the normal unix dump/restore will work on. SGI’s also have xfs filesystems and they must be built, checked, dumped and restored with a special set of xfs commands. Thus you need to use xfsrestore to pull files and dirs out of an xfsdump file. Note too that xfsrestore doesn’t like pipes to an interactive xfsrestore, so you have to do a bit more work to restore from an xfs filesystem. Here is an example:

	# amrestore -p $TAPE in10 '/usr' > /tmp/dumpfile
	amrestore:   0: skipping start of tape: date 19990819 label ARCall171
	amrestore:   1: skipping i10._usr_staff_Images.19990819.1
	amrestore:   2: skipping kosh._.19990819.1
	amrestore:   3: skipping i4._.19990819.2
	...
	amrestore:  32: restoring in10._usr_people.19990819.2
	# xfsrestore -i -v verbose -f /tmp/dumpfile .
	xfsrestore: version 2.0 - type ^C for status and control
	xfsrestore: searching media for dump
	xfsrestore: examining media file 0
	xfsrestore: dump description: 
	xfsrestore: hostname: in10
	xfsrestore: mount point: /usr/people
	xfsrestore: volume: /dev/dsk/dks0d3s6
	xfsrestore: session time: Thu Aug 19 20:20:04 1999
	xfsrestore: level: 2
	...
	xfsrestore: directory post-processing
	========== subtree selection dialog =======================
	the following commands are available:
	        pwd 
	        ls [  ]
	        cd [  ]
	        add [  ]
	        delete [  ]
	        extract 
	        quit 
	        help 
	
	 ->

Performing a Remote Restore

What if your Amanda server and the client you want to restore are different architectures, say an SGI server and a FreeBSD PC? Chances are the SGI machine won’t understand the FreeBSD machines dump. Try remote shelling over to the server from the client and piping the output back to the client. Also, don’t forget the “-n” option to rsh, otherwise you will lose control of the standard input to the restore command. This becomes obvious when you can’t enter anything in to the interactive prompt! Heres an example:

	# mkdir /tmp/restore ; cd /tmp/restore
	# rsh -n i0 "/usr/local/amanda/bin/amrestore -p $TAPE valen '^/$'" | restore -ivf - .
	...

# kinit root
# krsh i10 -n /usr/local/amanda/bin/amrestore -p /dev/rmt/tps3d1nrvc delenn /home5 | /sbin/restore -ivf - .               Verify tape and initialize maps
This rsh session is using DES encryption for all data transmissions.
amrestore:   0: skipping start of tape: date 20000321 label ARCall107
amrestore:   1: skipping valen._.20000321.1
amrestore:   2: skipping delenn._.20000321.1
...
amrestore:  56: skipping kosh._var_mail.20000321.1
amrestore:  57: skipping delenn._home2.20000321.3
amrestore:  58: restoring delenn._home5.20000321.0
Dump   date: Wed Mar 22 00:02:24 2000
Dumped from: the epoch
Level 0 dump of /home5 on delenn.arc.umn.edu:/dev/da2s1a
Label: none
Extract directories from tape
Initialize symbol table.
restore >  ls 
.:
     2 ./                 508349 herbert/           444864 nrowe-WES_DELETE/
     2 ../                301590 hinman/                 3 quota.user 
119211 avr/               507996 jrm/               484450 rannow/
 31744 bbryan-WES_DELETE/ 547593 kjm/               135105 ray-WES_DELETE/
325839 ewing/             531876 lbuhse/             47991 sko/
436493 frank/             452852 lost+found/        373477 tdavis/
103245 gumby/             214588 maier-WES_DELETE/     608 users.dat 

restore > cd kjm
restore > ls
./kjm:
547593 ./                     547653 .webspace-preferences 
     2 ../                    547654 .wm_style 
547594 ...cshrc               547655 .wshttymode 
547595 ...signature             8049 .xauth/
547596 ..cshrc                547656 .xcontactPrefs 
547597 ..disableDesktop       547657 .xinitrc 
547598 ..login                547658 .xinitrc.bak 
547599 ..mwmrc                547659 .xmodmap 
547601 .4Dwmrc                547660 .xrn 
restore > add .cshrc
Make node ./kjm
restore > extract
Extract requested files
extract file ./kjm/.cshrc
Add links
Set directory mode, owner, and times.
set owner/mode for '.'? [yn] n
restore > quit




Cron Entry

We run Amanda Monday thru Friday every week on I0 via cron. Here are the cron entries we use, note it is run as user bin-not root:

	# id
	uid=2(bin) gid=2(bin)
	# crontab -l |grep amanda
	0 15 * * 1-5 /usr/local/amanda/bin/amcheck -m all
	0 20 * * 1-5 /usr/local/amanda/bin/amdump all

The above commands help remind us to load the days tapes, flush any dumps that may be clogging up the holding disk and then run the dump automagically later on at night when we are gone and the system and network are more lightly used.

Common Problems and Fixes

If you use a non-root account to do your dumps with (which is highly recommended) you will find that machines with recent OS upgrades and new machines may not dump. If this is the case, you may need to make group and mode changes to your raw filesystem devices and your dump/restore binaries. In the examples below we use the “bin” account as the non-root account. We can confirm the problem is a permissions problem by connecting to the machine having problems and looking at the /tmp/sendsize.debug file:

	# less /tmp/sendsize.debug
	sendsize: debug 1 pid 13027 ruid 2 euid 2 start time Thu Dec 16 20:00:05 1999
	/usr/local/amanda/libexec/sendsize: version 2.3.0.4
	calculating for amname '/', dirname '/'
	sendsize: getting size via dump for / level 0
	sendsize: running "/sbin/dump 0sf 100000 - /"
	 DUMP: Cannot open/stat /dev/rroot, Permission denied <- This is the problem!
	.....
	(no size line match in above dump output)
	.....
	sendsize: pid 13027 finish time Thu Dec 16 20:00:17 1999
	

Next check the permissions on all the raw disk devices. They should all be group “bin” and mode 640:

	# ls -ld `df -l | tail +2 | sed 's?^/dev/?/dev/r?' | awk '{printf "%s ", $1}'`
	crw-------    2 root     root      128, 16 Feb  6 05:00 /dev/rroot
	crw-------    1 root     root      128,279 Feb  6 04:59 /dev/rdsk/dks1d1s7
	crw-------    1 root     root      128,310 Feb  6 03:26 /dev/rdsk/dks1d3s6

	# chgrp bin `df -l | tail +2 | sed 's?^/dev/?/dev/r?' | awk '{printf "%s ", $1}'`
	# chmod 640 `df -l | tail +2 | sed 's?^/dev/?/dev/r?' | awk '{printf "%s ", $1}'`

	# ls -ld `df -l | tail +2 | sed 's?^/dev/?/dev/r?' | awk '{printf "%s ", $1}`
	crw-r-----    2 root     bin      128, 16 Feb  6 05:00 /dev/rroot
	crw-r-----    1 root     bin      128,279 Feb  6 04:59 /dev/rdsk/dks1d1s7
	crw-r-----    1 root     bin      128,310 Feb  6 03:26 /dev/rdsk/dks1d3s6

Finally, you may have problems with the dump/restore or xfsdump/xfsrestore binaries. We had problems with the xfs commands on IRIX so we changed the group to “bin” and the mode to be suid root:

	# ls -ld /usr/sbin/xfsdump /sbin/xfsrestore
	-rwxr-xr-x    1 root     root      304084 Jan  6 10:34 /sbin/xfsrestore*
	-rwxr-xr-x    1 root     root      242644 Jan  6 10:37 /usr/sbin/xfsdump*

	# chgrp bin  /usr/sbin/xfsdump /sbin/xfsrestore
	# chmod 4750 /usr/sbin/xfsdump /sbin/xfsrestore
	# ls -ld /usr/sbin/xfsdump /sbin/xfsrestore
	-rwsr-x---    1 root     bin       304084 Jan  6 10:34 /sbin/xfsrestore*
	-rwsr-x---    1 root     bin       242644 Jan  6 10:37 /usr/sbin/xfsdump*

Commands to Know

Here is a short list of the Amanda commands and how to use them

amadmin (8)        - administrative interface to control Amanda backups
amanda (8)         - Advanced Maryland Automatic Network Disk Archiver
amcheck (8)        - Amanda pre-run self-check
amcleanup (8)      - runs the Amanda cleanup process after a failure
amdump (8)         - backs up all disks in an Amanda configuration
amflush (8)        - flushes Amanda backup files from holding disk to tape
amlabel (8)        - labels an Amanda tape
amrestore (8)      - extract files from an Amanda tape
xfsrestore (1M)    - XFS filesystem incremental restore utility

Here are some examples to jump start your use of Amanda:

	amlabel all ARCatRice99
	amadmin all tape
	amflush -f all
	amcheck all
	amcheck -c all
	amcheck -s all
	amadmin all force
	amadmin all unforce
	amadmin all balance
	amadmin all find ivie /usr/people
	amrestore -p /dev/rmt/tps0d5nrv ivie /usr/people | restore -ivf - .
This entry was posted in Linux How-To. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *