Several other packages may be required to complete an Amanda install. Before continuing, you should locate and install packages your environment will need. In particular, consider the following:

Be sure to look in the Amanda patches directory and the patches section on the web page for updates to these packages. SAMBA versions before 2.0.3, in particular, must have patches applied to make them work properly with Amanda. Without the patches, backups appear to work but the resulting images are corrupt.

When Amanda is configured, locations of additional software used on the clients, such as GNU-tar and SAMBA, get built into the Amanda programs, so additional software must be installed in the same place on the Amanda build machine and all the clients.

A typical Amanda configuration runs as a user other than root, such as backup or amanda, given just enough permissions to do backups. Often, direct login as the user is disallowed. To use the vendor dump program instead of GNU-tar, the Amanda user must be in a group with read access to the raw disk devices. Membership in this group should be tightly controlled since it opens up every file on the client for viewing.

There are two ways to link Amanda and the raw device group membership. Either put the Amanda user in the group that currently owns the raw devices, as the primary group or as a secondary, or pick a new group for Amanda and change the group ownership of the devices. Amanda (actually, the vendor dump program) needs only read access, so turn off group write permission. Turn off all "world" access.

To use GNU-tar, Amanda runs it under a setuid-root program that grants the needed permissions. The GNU version of tar must be used with Amanda. Vendor supplied versions (unless they originated from GNU and are at least version 1.12) do not work because Amanda depends on additional features.

Use the Amanda user and group for the --with-user and --with-group options to ./configure. For instance, to use amanda for the user and backup as the group: ./configure --with-user=amanda --with-group=backup ...

No other options are required for ./configure, but all the possibilities may be seen with ./configure --help. Don't get carried away changing options. The defaults are usually suitable and some require experience with Amanda to fully understand. Leave --with-debugging enabled so debug log files are created on the clients. They take very little space but are often necessary for tracking down problems.

The normal build creates both tape server and client software. The tape server host is often backed up by Amanda and needs the client parts. However, the clients usually do not need the tape server parts. A little disk space and build time may be saved by adding --without-server to the ./configure arguments when building for them.

The default security mechanism uses a file formatted just like .rhosts but called .amandahosts. This keeps Amanda operations separate from normal rsh/rcp work that might use the same user. It is not recommended, but .rhosts and hosts.equiv may be used by adding --without-amandahosts to the ./configure arguments.

The TCP ports used for data transfer may be restricted with --with-portrange to use Amanda between hosts separated by a firewall. A typical entry would be: ./configure --with-portrange=50000,50100 ... This does not affect the initial UDP requests made from the tape server to the clients. The amanda UDP port (typically 10080) must be allowed through the firewall.

If more than just a few ./configure options are used, they may be put in /usr/local/share/config.site or /usr/local/etc/config.site to keep them the same from build to build. An example is in example/config.site.

After ./configure is done, run make to build Amanda, then make install to install it. The make install step must be done as root because some Amanda programs require system privileges. Unless the base location is changed, Amanda installs into these areas:

Now is a good time to read the main Amanda man page. It provides an overview of Amanda, a description of each program, and detailed configuration information.

The following programs must be setuid-root (which make install as root does). The first group (amcheck,dumper, and planner) run on the tape server machine and need a privileged network port for secure communication with the clients. The others are utility routines optionally used on the clients, depending on the dump program used and operating system type.

All these programs are installed with world access disabled and group access set to the Amanda group from --with-group. Be sure all members of that group are trustworthy since rundump and runtar in particular give access to every file on the system. If Amanda software is made available via NFS, be sure the mount options allow setuid programs. Also, if GNU-tar is used, root needs write access to /usr/local/var/amanda/gnutar-lists (or the --with-gnutar-list value to ./configure) to store information about each partial level.

If the build has trouble or Amanda needs to be rebuilt, especially with different ./configure options, the following sequence makes sure everything is cleaned up from the previous build: make distclean ./configure ... make make install (as root) Problems with the ./configure step can sometimes be diagnosed by looking at the config.log file. It contains detailed output of tests ./configure runs. Note that it is normal for many of the tests to "fail" as part of ./configure determining how to access various features on the system.

A common problem when using the GNU C compiler is not re-installing it after the underlying operating system version changes. Gcc is particularly sensitive to system header files and must be re-installed or have its fixincludes step rerun (see the gcc release installation notes) if the operating system is upgraded. Running gcc --verbose shows where gcc gets its information, and contains an indication of the operating system version expected.

Amanda needs changes to the network services and inetd configuration files. The client-src/patch-system script should be able to set up systems in most cases. It does not currently handle systems that deliver service entries via YP/NIS. If the script does not work, add the following entries to the services file (e.g., /etc/services) or YP/NIS map: Amanda 10080/udp Amandaidx 10082/tcp Amidxtape 10083/tcp

Each client needs an entry in the inetd configuration file (e.g., /etc/inetd.conf) like this, substituting the Amanda user for Amanda and the full path to the Amanda libexec directory for PATH: amanda dgram udp wait Amanda /PATH/libexec/amandad amandad

The amanda service is used by all Amanda controlling programs to perform functions on the clients.

The tape server host needs entries like these if the amrecover tool is to be used: amandaidx stream tcp nowait Amanda /PATH/libexec/amindexd amindexd amidxtape stream tcp nowait Amanda /PATH/libexec/amidxtaped amidxtaped

The amandaidx service provides access to the catalogues, while amidxtape provides remote access to a tape device. After every inetd configuration file change, send a HUP signal to the inetd process and check the system logs for errors.

Once installed, Amanda must be configured to your environment.

The first thing to decide is what machine will be the Amanda tape server. Amanda can be CPU-intensive if configured to do server compression, and almost certainly network and I/O-intensive. It does not typically use much real memory. It needs direct access to a tape device that supports media with enough capacity to handle the expected load.

To get a rough idea of the backup sizes, take total disk usage (not capacity), Usage, and divide it by how often full dumps will be done, Runs. Pick an estimated run-to-run change rate, Change. Each Amanda run, on average, does a full dump of Usage/Runs. Another Usage/Runs*Change is done of areas that got a full dump the previous run, Usage/Runs*Change* is done of areas that got a full dump two runs ago, and so on.

For example, with 100 GB of space in use, a full dump every seven runs (e.g., days) and estimated run-to-run changes (new or altered files) of 5 percent:

	  100 GBytes / 7              = 14.3 GB
	  100 GBytes / 7 * 5%         =  0.7 GB
	  100 GBytes / 7 * 5% * 2     =  1.4 GB
	  100 GBytes / 7 * 5% * 3     =  2.1 GB
	  100 GBytes / 7 * 5% * 4     =  2.9 GB
	  100 GBytes / 7 * 5% * 5     =  3.6 GB
	  100 GBytes / 7 * 5% * 6     =  4.3 GB 
	                              = 29.3 GB
	

If 50 percent compression is expected, the actual amount of tape capacity needed for each run, which might be on more than one tape, would be 14.7 GB. This is very simplistic, and could be improved with greater knowledge of actual usage, but should be close enough to start with. It also gives an estimate of how long each run will take by dividing expected capacity by drive speed.

Unix operating systems typically incorporate device characteristics into the file name used to access a tape device. The two to be concerned with are "rewind" and "compression." Amanda must be configured with the non-rewinding tape device, so called because when the device is opened and closed it stays at the same position and does not automatically rewind. This is typically a name with an n in it, such as /dev/rmt/0n or /dev/nst0. On AIX, it is a name with a .1 or .5 suffix.

Put the Amanda user in the group that currently owns the tape device, either as the primary group or as a secondary, or pick a new group for Amanda and change the group ownership of the device. Amanda needs both read and write access. Turn off all "world" access.

Dump images may optionally be compressed on the client, the tape server, or the tape device hardware. Software compression allows Amanda to track usage and make better estimates of image sizes, but hardware compression is more efficient of CPU resources. Turn off hardware compression when using software compression on the client or server. See the operating system documentation for how hardware compression is controlled; on many systems it is done via the device file name just like the non-rewinding flag. AIX uses the chdev command.

If at all possible, allocate some holding disk space for Amanda on the tape server. Holding disk space can significantly reduce backup time by allowing several dumps to be done at once while the tape is being written. Also, for streaming tape devices, Amanda keeps the device going at speed, and that may increase capacity. Amanda may be configured to limit disk use to a specific value so it can share with other applications, but a better approach is to allocate one or more inexpensive disks entirely to Amanda.

Ideally, there should be enough holding disk space for the two largest backup images simultaneously, so one image can be coming into the holding disk while the other is being written to tape. If that is not practical, any amount that holds at least a few of the smaller images helps. The Amanda report for each run shows the size of the dump image after software compression (if enabled). That, in addition to the amplot and amstatus tools, may be used to tune the space allocated.

Decide how often Amanda should do full dumps. This is the "dump cycle." Short periods make restores easier because there are fewer partials, but use more tape and time. Longer periods let Amanda spread the load better but may require more steps during a restore.

Large amounts of data to back up or small capacity tape devices also affect the dump cycle. Choose a period long enough that Amanda can do a full dump of every area during the dump cycle and still have room in each run for the partials. Typical dump cycles are one or two weeks. Remember that the dump cycle is an upper limit on how often full dumps are done, not a strict value. Amanda runs them more often and at various times during the cycle as it balances the backup load. It violates the limit only if a dump fails repeatedly, and issues warnings in the e-mail report if that is about to happen.

By default, Amanda assumes it is run every day. If that is not the case, set "runs per cycle" (described below) to a different value. For instance, a dump cycle of seven days and runs per cycle of five would be used if runs are done only on weekdays.

Normally, Amanda uses one tape per run. With a tape changer (even the chg-manual one), the number of tapes per run may be set higher for extra capacity. This is an upper limit on the number of tapes. Amanda uses only as much tape as it needs. Amanda does not yet do overflow from one tape to another. If it hits end of tape (or any other error) while writing an image, that tape is unmounted, the next one is loaded, and the image starts over from the beginning. This sequence continues if the image cannot fit on a tape.

Runs per cycle and tapes per run determine the minimum number of tapes needed, called the "tape cycle." To ensure the current run is not overwriting the last full dump, one more run should be included. For instance, a dump cycle of two weeks, with default runs per cycle of 14 (every day) and default tapes per run of one, needs at least 15 tapes (14+1 runs * one tape/run). Using two tapes per run needs 30 tapes (14+1 runs * two tapes/run). Doing backups just on weekdays with a dump cycle of two weeks, runs per cycle of 10, and two tapes per run needs 22 tapes (10+1 runs * two tapes/run).

More tapes than the minimum should be allocated to handle error situations. Allocating at least two times the minimum allows the previous full dump to be used if the most recent full dump cannot be read. Allocating more tapes than needed also goes back further in time to recover lost files. Amanda does not have a limit on the number of tapes in the tape cycle.

Pick a name for the configuration (the name Daily will be used for the rest of this section). Create a directory on the tape server machine to hold the configuration files, typically /usr/local/etc/amanda/Daily. Access to this directory (or perhaps its parent) should be restricted to the Amanda group or even just the Amanda user.

Each tape assigned to a configuration needs a unique label. For this example, we'll use the configuration name, a dash, and a three-digit suffix, Daily-000 through Daily-999. Do not use blanks, tabs, slashes (/), shell wildcards, or non-printable characters.

Amanda limits network usage so backups do not take all the capacity. This limit is imposed when Amanda is deciding whether to perform a dump by estimating the throughput and adding that to dumps that are already running. If the value exceeds the bandwidth allocated to Amanda, the dump is deferred until enough others complete. Once a dump starts, Amanda lets underlying network components do any throttling.

Copy the template example/amanda.conf file to the configuration directory and edit it. Full documentation is in the amanda man page. There are many parameters, but probably only a few need to be changed. Start with the following (some of which are described later):

The following parameters probably do not need to be changed, but look at their values to know where Amanda expects to find things:

Define each holding disk in an amanda.conf holdingdisk section. If partitions are dedicated to Amanda, set the use value to a small negative number, such as -10 MB. This tells Amanda to use all but that amount of space. If space is shared with other applications, set the value to the amount Amanda may use, create the directory and set the permissions so only the Amanda user can access it.

Set a chunksize value for each holding disk. Positive numbers split dumps in the holding disk into chunks no larger than the chunksize value. Negative numbers are no longer supported. Even though the images are split in the holding disk, they are written to tape as a single image. At the moment, all chunks for a given image go to the same holding disk.

Older operating systems that do not support individual files larger than 2GB need a chunk size slightly smaller, such as 2000 MB, so the holding disk can still be used for very large dump images. Systems that support individual files larger than 2 GB should have a very large value, such as 2000 GBytes.

Amanda needs to know some characteristics of the tape media. This is set in a tapetype section. The example amanda.conf, web page, and amanda-users mailing list archives have entries for most common media. Currently, all tapes should have the same characteristics. For instance, do not use both 60-meter and 90-meter DAT tapes since Amanda must be told the smaller value, and larger tapes may be underutilized.

If the media type is not listed and there are no references to it in the mailing list archives, go to the tape-src directory, make tapetype, mount a scratch tape in the drive and run ./tapetype NAME DEV where NAME is a text name for the media and DEV is the no-rewind tape device with hardware compression disabled. This program rewinds the tape, writes random data until it fills the tape, rewinds, and then writes random data and tape marks until it fills the tape again. This can take a very long time (hours or days). When finished, it generates a new tapetype section to standard output suitable for adding to the amanda.conf file. Post the results to the amanda-users mailing list so others may benefit from your effort.

When using hardware compression, change the length value based on the estimated compression rate. This typically means multiplying by something between 1.5 and 2.0.

The length and filemark values are used by Amanda only to plan the backup schedule. Once dumps start, Amanda ignores the values and writes until it gets an error. It does not stop writing just because it reaches the tapetype length. Amanda does not currently use the tapetype speed parameter.

Once the tapetype definition is in amanda.conf, set the tapetype parameter to reference it.

Without special hardware to mount tapes, such as a robot or stacker, either set the tapedev parameter to the no-rewind device name or set up the Amanda chg-manual changer. The manual changer script prompts for tape mounts as needed. The prompts normally go to the terminal of the person running Amanda, but the changer may be configured to send requests via e-mail or to some other system logging mechanism.

To configure the manual changer, set tapedev to the no-rewind tape device and set tpchanger to chg-manual. To send tape mount prompts someplace other than the terminal, which is necessary if Amanda is run from a cron job, see the request shell function comments in changer-src/chg-manual.sh.in.

Another common tape changer is chg-multi. This script can drive stackers that advance to the next tape when the drive is unloaded or it can use multiple tape drives on the tape sever machine to emulate a changer. The chg-multi script has a configuration file and a state file. Put the path to the configuration file in the amanda.conf changerfile parameter. There is a sample in example/chg-multi.conf. It has the following keyword/value pairs separated by whitespace:

chg-multi may also be used as a framework to write a new changer. Look for XXX comments in the script and insert calls to commands appropriate for the device. Make any source changes to the changer-src/chg-multi.sh.in file. That file is processed by ./configure to generate chg-multi.sh, which turns into chg-multi with make. If chg-multi.sh or chg-multi is altered, the changes will be lost the next time Amanda is rebuilt.

A third popular changer is chg-scsi. It can drive devices that have their own SCSI interface. An operating system kernel module may need to be installed to control such devices, like sst for Solaris, which is released with Amanda, or chio, available for various systems. As with chg-multi, set the amanda.conf changerfile parameter to the changer configuration file path. There is a sample in example/chg-scsi.conf. The initial section has parameters common to the entire changer:

Test any changer setup with the amtape command. Make sure it can load a specific tape with the slot NNN suboption, eject the current tape with eject and advance to the next slot with slot next.

Tapes must be pre-labeled with amlabel so Amanda can verify the tape is one it should use. Run amlabel as the Amanda user, not root. For instance:

	  
	    # su amanda -c "amlabel Daily Daily-123 slot 123"
	  
	

After tapes are labeled, pick the first client, often the tape server host itself, and the filesystems or directories to back up. For each area to back up, choose either the vendor dump program or GNU-tar. Vendor dump programs tend to be more efficient and do not disturb files being dumped, but are usually not portable between different operating systems. GNU-tar is portable and has some additional features, like the ability to exclude patterns of files, but alters the last access time for every file backed up and may not be as efficient. GNU-tar may also deal with active filesystems better than vendor dump programs, and is able to handle very large filesystems by breaking them up by subdirectories.

Choose the type of compression for each area, if any. Consider turning off compression of critical areas needed to bring a machine back from the dead in case the decompression program is not available. Client compression spreads the load to multiple machines and reduces network traffic, but may not be appropriate for slow or busy clients. Server compression increases the load on the tape server machine, possibly by several times since multiple dumps are done at once. For either, if GNU GNU-zip is used, compression may be set to fast for faster but less aggressive compression or best for slower but more aggressive compression. Set compression to none to disable software compression or use hardware compression.

Pick or alter an existing dumptype that matches the desired options, or create a new one. Each dumptype should reference the global dumptype. It is used to set options for all other dumptypes. For instance, to use the indexing facility, enable it in the global dumptype and all other dumptypes will inherit that value.

The indexing facility generates a compressed catalogue of each dump image. These are useful for finding lost files and are the basis of the amrecover program. Long dump cycles or areas with many or very active files can cause the catalogues to use a lot of disk space. Amanda automatically removes catalogues for images that are no longer on tape.

Create a file named disklist in the same directory as amanda.conf and either copy the file from example/disklist or start a new one. Make sure it is readable by the Amanda user. Each line in disklist defines an area to be backed up. The first field is the client host name (fully qualified names are recommended), the second is the area to be backed up on the client and the third is the dumptype. The area may be entered as a disk name, (sd0a), a device name, (/dev/rsd0)a, or a logical name, (/usr). Logical names make it easier to remember what is being backed up and to deal with disk reconfiguration.

To set up a Windows client, set the host name to the name of the Unix machine running SAMBA and the area to the Windows share name, such as //some-pc/C$. Note that Unix-style forward slashes are used instead of Windows-style backward slashes.

Enable Amanda access to the client from the tape server host (even if the client is the tape server host itself) by editing .amandahosts (or .rhosts, depending on what was set with ./configure) in the Amanda user home directory on the client. Enter the fully qualified tape server host name and Amanda user, separated by a blank or tab. Make sure the file is owned by the Amanda user and does not allow access to anyone other than the owner (e.g. mode 0600 or 0400).

For Windows clients, put the share password in /etc/amandapass on the SAMBA host. The first field is the Windows share name, the second is the clear text password and the optional third field is the domain.

Because this file contains clear text passwords, it should be carefully protected, owned by the Amanda user and only allow user access. By default, Amanda uses SAMBA user backup. This can be changed with --with-samba-user to ./configure.

Test the setup with amcheck. As with all Amanda commands, run it as the Amanda user, not root:

	  
	    # su amanda -c "amcheck Daily"
	  
	

Many errors reported by amcheck are described in docs/FAQ or the amcheck man page. The most common error reported to the Amanda mailing lists is selfcheck request timed out, meaning amcheck was not able to talk to amandad on the client. In addition to the ideas in docs/FAQ, here are some other things to try:

	  
	    #include <stdio.h>
	    #include <string.h>
	    #include <netdb.h>

	    main ( 
	        int argc, 
		char **argv)
	    { 
	        char *pn; 
		char *service; 
		char *protocol = "tcp"; 
		struct servent *s;
		
		if ((pn = strrchr (*argv, '/')) == NULL) { 
		    pn = *argv; 
		} else {
		    pn++;
	        } if (argc < 2) { 
		      fprintf (stderr, "usage: %s service [protocol]\n", pn); 
		      return 1; 
		} 
		service = *++argv; 
		if (argc > 2) { 
		protocol = *++argv; 
		} 
		if ((s = getservbyname (service, protocol)) == NULL) { 
		    fprintf (stderr, "%s: %s/%s lookup failed\n", pn,
		      service, protocol); 
		    return 1; 
		} 
		printf ("%s/%s: %d\n", service, protocol, 
		  (int) ntohs (s->s_port)); 
		return 0;
	    }
	  
	

Run it on both the tape server and client and make sure the port numbers match:

	  
	    $ cc check-service.c -lnsl -lsocket (Solaris)
	    $ a.out amanda udp
	      amanda/udp: 10080
	    $ a.out amandaidx
	      amandaidx/tcp: 10082
	    $ a.out amidxtape
	      amidxtape/tcp: 10083
	  
	

Do not proceed until amcheck is happy with the configuration.

For initial testing, set the record option to no in the global dumptype, but remember to set it back to yes when Amanda goes into normal production. This parameter controls whether the dump program on the client updates its own database, such as /etc/dumpdates for vendor dump.

To forget about an individual test run, use amrmtape to remove references to the tapes used, then use amlabel to relabel them. To completely start over, remove the files or directories named in the infofile and indexdir parameters, the tapelist file named in the tapelist parameter, all amdump.* files in the configuration directory and all log.* files in the directory named by the logdir parameter. These files contain history information Amanda needs between runs and also what is needed to find particular dump images for restores and should be protected when Amanda goes into production.

The amdump script controls a normal Amanda backup run. However, it's common to do site-specific things as well with a wrapper shell script around amdump. amdump is meant to run unattended from cron. See the operating system documentation for how to set up a cron task. Be sure it runs as the Amanda user, not root or the installer.

The amdump script does the following:

There are several ways to determine which tapes Amanda will need for a run. One is to look at the Amanda e-mail report from the previous run. The tapes used during that run and those expected for the next run are listed. Another is to run amcheck during normal working hours. In addition to showing which tapes are needed, it makes sure things are set up properly so problems can be fixed before the real Amanda run. A third is to use the tape suboption of amadmin. Without a tape changer, Amanda expects the first tape to be mounted in the drive when it starts. Automated tape changers should be able to locate the tapes. The chg-manual changer prompts for the tapes.

An Amanda report has several sections:

	  	  
	    These dumps were to tape Daily-009, Daily-010
	    Tonight's dumps should go onto 2 tapes: Daily-011, Daily-012.
	  
	

This shows which tapes were used during the run and which tapes are needed next.

	  
	    FAILURE AND STRANGE DUMP SUMMARY: 
	      gurgi.cc.p /var lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.] 
	      gurgi.cc.p / lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.]
	      pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"]
	      samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE
	      mace.cc.pu /master lev 0 FAILED [dumps too big, but cannot incremental dump new 
	      disk]
	  
	

Problems found during the run are summarized in this section. In this example:

	  
	    STATISTICS:
	                                 Total	          Full         Daily
                                      --------        --------      -------- 
	      Dump Time (hrs:min)         5:03            3:23          0:33   (0:14 start, 0:53 idle) 
	      Output Size (meg)        20434.4         17960.0        2474.4 
	      Original Size (meg)      20434.4         17960.0        2474.4 
	      Avg Compressed Size (%)      --              --            -- 
	      Tape Used (%)              137.4           120.0          17.4    (level:#disks ...) 
	      Filesystems Dumped            90              21            69    (1:64 2:2 3:3) 
	      Avg Dump Rate (k/s)       1036.5          1304.3         416.2 
	      Avg Tp Write Rate (k/s)   1477.6          1511.2        1271.9 
	  
	

This summarizes the entire run. It took just over five hours, almost 3.5 hours writing full dumps and about half an hour for partials. It took 14 minutes to get started, mostly in the planner step getting the estimates, and taper was idle almost one hour waiting on dumps to come into the holding disk.

In this example, hardware compression was used so Avg Compressed Size is not applicable and Output Size written to tape matches Original Size from the clients. About 137% of the length of the tape as defined in the tapetype was used (remember that two tapes were written), 120% for full dumps and 17% for partials. The Rate lines give the dump speed from client to tape server and tape writing speed, all in KBytes per second. The Filesystems Dumped line says 90 areas were processed, 21 full dumps and 69 partials. Of the partials, 64 were level 1, two were level 2 and three were level 3.

	  
	    FAILED AND STRANGE DUMP DETAILS:
	    
              /-- pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"] 
	      sendbackup: start [pete.cc.purdue.edu:/var/mail level 0] 
	      sendbackup: info BACKUP=/usr/sbin/ufsdump
	      sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
	      sendbackup: info end 
	      | DUMP: Writing 32 Kilobyte records 
	      | DUMP: Date of this level 0 dump: Sat Jan 02 02:03:22 1999 
	      | DUMP: Date of last level 0 dump: the epoch 
	      | DUMP: Dumping /dev/md/rdsk/d5 (pete.cc.purdue.edu:/var/mail) to standard output.
	      | DUMP: Mapping (Pass I) [regular files]
	      | DUMP: Mapping (Pass II) [directories]
	      | DUMP: Estimated 13057170 blocks (6375.57MB) on 0.09 tapes. 
	      | DUMP: Dumping (Pass III) [directories] 
	      | DUMP: Dumping (Pass IV) [regular files] 
	      | DUMP: 13.99% done, finished in 1:02 
	      | DUMP: 27.82% done, finished in 0:52
	      | DUMP: 41.22% done, finished in 0:42
	      
	      /-- samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE 
	      sendbackup: start [samba.cc.purdue.edu://nt-test/F$ level 1] 
	      sendbackup: info BACKUP=/usr/local/bin/smbclient 
	      sendbackup: info RECOVER_CMD=/usr/local/bin/smbclient -f... - 
	      sendbackup: info end 
	      ? Can't load /usr/local/samba-2.0.2/lib/smb.conf - run testparm to debug it 
	      | session request to NT-TEST.CC.PURD failed
	      |                 directory \top\
	      |                 directory \top\Division\
	      |        238 (    2.7 kb/s) \top\Division\contract.txt
	      |      19456 ( 169.6 kb/s)  \top\Division\stuff.doc
	    ...
	  
	

Failures and unexpected results are detailed here. The dump of /var/mail would not fit on the first tape so was aborted and rerun on the next tape, as described further in the next section.

The dump of F$ on nt-test.cc.purdue.edu failed due to a problem with the SAMBA configuration file. It's marked STRANGE because the line with a question mark does not match any of the regular expressions built into Amanda. When dumping Windows clients via SAMBA, it's normal to get errors about busy files, such as PAGEFILE.SYS and the registry. Other arrangements should be made to get these safely backed up, such as a periodic task on the PC that creates a copy that will not be busy at the time Amanda runs.

	  
	    NOTES: 
	      planner: Adding new disk j.cc.purdue.edu:/var.
	      planner: Adding new disk mace.cc.purdue.edu:/master. 
	      planner: Last full dump of mace.cc.purdue.edu:/src on tape Daily-012 overwritten 
	               in 2 runs. 
	      planner: Full dump of loader.cc.purdue.edu:/var promoted from 2 days ahead.
	      planner: Incremental of sage.cc.purdue.edu:/var bumped to level 2. 
	      taper: tape Daily-009 kb 19567680 fm 90 writing file: short write 
	      taper: retrying pete.cc.purdue.edu:/var/mail.0 on new tape: [writing file: short 
	             write] 
	      driver: pete.cc.purdue.edu /var/mail 0 [dump to tape failed, will try again] 
	      taper: tape Daily-010 kb 6201216 fm 1 [OK]
	  
	

Informational notes about the run are listed here. The messages from planner say:

The rest of the notes say taper was not able to write as much data as it wanted, probably because of hitting end of tape. Up to that point, it had written 19567680 KBytes in 90 files on tape Daily-009. Another attempt at the full dump of /var/mail from pete.cc.purdue.edu was made on the next tape (Daily-010) and it succeeded, writing 6201216 KBytes in one file.

	  
	    DUMP SUMMARY:
	    
	                                     DUMPER STATS                   TAPER STATS 
      HOSTNAME  DISK           L   ORIG-KB   OUT-KB COMP%   MMM:SS   KB/s  MMM:SS   KB/s 
      --------------------------- --------------------------------------- --------------
      boiler.cc /              1      2624     2624   --      0:13  200.1    0:02 1076.0 
      boiler.cc /home/boiler/a 1       192      192   --      0:07   26.7    0:02  118.5 
      boiler.cc /usr           1       992      992   --      0:41   24.2    0:02  514.7 
      boiler.cc /usr/local     1       288      288   --      0:09   31.2    0:04   86.3
      boiler.cc /var           1       425     4256   --      0:21  205.9    0:04 1104.3 
      egbert.cc /              1     41952    41952   --      1:26  487.3    0:37 1149.4 
      egbert.cc /opt           1       224      224   --      0:06   37.5    0:02  136.0 
      egbert.cc -laris/install 1        64       64   --      0:11    5.8    0:02   49.5 
      gurgi.cc. /              0    FAILED --------------------------------------------- 
      gurgi.cc. /var           0    FAILED --------------------------------------------- 
      pete.cc.p /              1     13408    13408   --      0:41  328.2    0:08 1600.5 
      pete.cc.p /opt           1      3936     3936   --      1:04   61.2    0:03 1382.6 
      pete.cc.p /usr           1      1952     1952   --      0:29   67.0    0:03  584.3 
      pete.cc.p /var           1    300768   300768   --      2:33 1963.8    2:50 1768.8 
      pete.cc.p /var/mail      0   6201184  6201184   --     73:45 1401.3   73:47 1400.8

     ...
     (brought to you by Amanda version 2.4.1p1)
	  
	

This section (which has been abbreviated) reports each area dumped showing client, area, backup level, sizes, time to dump and time to write to tape. Entries are in alphabetic order by client and then by area. This is not the same as the tape order. Tape order can be determined with the find or info suboption of the amadmin command, amtoc can generate a tape table of contents after a run, or amreport can generate a printed listing. By default, client names are truncated on the right, area names on the left, to keep the report width under 80 character. This typically leaves the unique portions of both.

Two log files are created during an Amanda run. One is named amdump.NN, where NN is a sequence number (1 is most recent, 2 is next most recent, etc), and is in the same directory as amanda.conf. The file contains detailed step by step information about the run and is used for statistics by amplot and amstatus, and for debugging. The other file is named log.YYYYMMDD.N where YYYYMMDD is the date of the Amanda run and N is a sequence number in case more than one run is made on the same day (0 for the first run, 1 for the second, etc). This file is in the directory specified by the logdir amanda.conf parameter. It contains a summary of the run and is the basis for the e-mail report. In fact, amreport may be run by hand and given an old file to regenerate a report.

Old amdump.NN files are removed by the amdump script. Old log.YYYYMMDD.N files are not automatically removed and should be cleared out periodically by hand. Keeping a full tape cycle is a good idea. If the tape cycle is 40 and Amanda is run once a day, the following command would do the job:

	  
	    #find log.????????.* -mtime +40 -print | xargs rm
	  
	

If --with-pid-debug-files was used on ./configure, clients accumulate debug files in /tmp/amanda (or whatever --with-debug was set to) and should be cleaned out periodically. Without this option, client debug files have fixed names and are reused from run to run.

While amdump is running, amstatus can track how far along it is. amstatus may also be used afterward to generate statistics on how many dumpers were used, what held things up and so on.

When a tape error happens on the last tape allowed in a run (as set by runtapes), Amanda continues to do backups into the holding disks. This is called degraded mode. By default, full dumps are not done and any that were scheduled have a partial done instead. A portion of the holding disk area may be allocated to do full dumps during degraded mode by reducing the value of the parameter reserve in amanda.conf below 100%.

A tape server crash may also leave images in the holding disks. Run amflush, as the Amanda user, to flush images in the holding disk to the next tape after correcting any problems. It goes through the same tape request mechanism as amdump. If more than one set of dumps are in the holding disk area, amflush prompts to choose one to write or to write them all. amflush generates an e-mail report just like amdump.

Operating systems vary in how they report end of tape to programs. A no space or short write error probably means end of tape. For I/O error, look at the report to see how much was written. If it is close to the expected tape capacity, it probably means end of tape, otherwise it means a real tape error happened and the tape may need to be replaced the next time through the tape cycle.

To swap out a partially bad tape, wait until it is about to be used again so any valid images can still be retrieved. Then swap the tapes, run amrmtape on the old tape and run amlabel on the replacement so it has a proper Amanda label.

If a tape is marked to not be reused with the no-reuse suboption of amadmin, such as one that has been removed or is failing, Amanda may want a freshly labeled tape on the next run to get the number of tapes back up to the full tape cycle.

If a tape goes completely bad, use amrmtape to make Amanda forget about it. As with marking a tape no-reuse, this may reduce the number of tapes Amanda has in use below the tape cycle and it may request a newly labeled tape on the next run.

These steps let Amanda know about all tapes, including those that do not have data yet. When the cycle gets to the last old tape (Daily-099), the next tape used will be the first new one (Daily-100). A new option is planned for amlabel to do these steps automatically.

Multiple amdump runs may be made in the same day, although catalogues are currently stored without a timestamp so amrecover may not show all restore possibilities. To redo a few areas that failed during the normal run, edit the disklist file by hand to comment out all the other entries, run amdump, then restore the disklist file.

Use the force suboption of amadmin to schedule a full dump of an area on the next run. Run this as the Amanda user, not root. Amanda automatically detects new disklist entries and schedules an initial full dump. But for areas that go through a major change, such as an operating system upgrade or full restore, force Amanda to do a full dump to get things back into sync.

Amanda does not automatically notice new client areas, so keep the disklist in sync by hand. Amanda usually notices areas that are removed and reports an error as a reminder to remove the entry from the disklist. Use the delete suboption of amadmin (as the Amanda user) to make Amanda completely forget about an area, but wait until the information is not needed for restores. This does not remove the entry from the disklist file — that must be done by hand.

Non—Amanda backups may still be done with Amanda installed, but do not let the client dump program update its database. For vendor dump programs, this usually means not using the u flag, or saving and restoring /etc/dumpdates. For GNU-tar it means the --listed-incremental flag (if used) should not point to the same file Amanda uses.

As with all backup systems, verify the resulting tapes, if not each one then at least periodically or by random sample. The amverify script does a reasonably good job of making sure tapes are readable and images are valid. For GNU-tar images, the test is very good. For vendor dump images of the same operating system type as the tape server machine, the test is OK but does not really check the whole image due to the limited way the catalogue option works. For vendor dump images from other operating systems, amverify can tell if the image is readable from tape but not whether it is valid.

Tape drives are notorious for being able to read only what they wrote, so run amverify on another machine with a different drive, if possible, so an alternate is available if the primary drive fails. Make a copy of the Amanda configuration directory on the other machine to be able to run amverify. This copy is also a good way to have a backup of the Amanda configuration and database in case the tape server machine needs to be recovered.

Several dumptype parameters control the backup level Amanda picks for a run:

Note that dumpcycle is both a general amanda.conf parameter and a specific dumptype parameter. The value in a specific dumptype takes precedence. To handle areas that change significantly between each run and should get a full dump each time (such as the mail spool on a busy e-mail server or a database area), create a dumptype based on another dumptype with attributes changed as desired (client dump program, compression, etc) and set dumpcycle in the new dumptype to 0:

	  	  
	    define mail-spool {
	        comp-user-tar 
		dumpcycle 0
	    }
	  
	

To run full dumps by hand outside of Amanda (perhaps they are too large for the normal tape capacity, or need special processing), create a new dumptype and set strategy to incronly:

	  
	    define full-too-big {
	        comp-user-tar 
	        strategy incronly
	    }
	  
	

Tell Amanda when a full dump of the area has been done with the force suboption of amadmin. Take care to do full dumps often enough that the tape cycle does not wrap around and overwrite the last good non-full backups.

To never do full dumps (such as an area easily regenerated from vendor media), create a new dumptype and set strategy to nofull:

	  
	    define man-pages {
	    	comp-user-tar 
		strategy nofull
	    }
	  
	

Only level 1 backups of such areas are done, so wrapping around the tape cycle is not a problem.

To do periodic archival full dumps, create a new Amanda configuration with its own set of tapes but the same disklist as the normal configuration (e.g. symlink them together). Copy amanda.conf, setting all dumpcycle values to 0 and record to no, e.g. in the global dumptype. If a changer is used, set runtapes very high so tape capacity is not a planning restriction. Disable the normal Amanda run, or set the hold file as described in "Operating Amanda", so Amanda does not try to process the same client from two configurations at the same time.

Amanda starts several dumper processes and keeps as many as possible running at once. The following options control their activity:

The default maxdumps is one, meaning only one dumper is assigned to a client at a time. If a client can support the load, increase maxdumps so more than one dump on that client is running at once. Note that maxdumps is both a general amanda.conf parameter and a specific dumptype parameter. The value in a specific dumptype takes precedence.

Field four of the disklist file is a "spindle number". Areas with the same non-negative spindle number are not backed up at the same time if maxdumps is greater than one. This prevents thrashing on an individual physical disk. Set spindle number to -1 (which is the default) for independent areas that can be done in conjunction with any other area, such as a whole physical disk. If the tape server has multiple network connections, an amanda.conf interface section may be set up for each one and clients allocated to a particular interface with field five of the disklist. Individual interfaces take precedence over the general netusage bandwidth limit and follow the same guidelines described above in "Configuring Amanda": the limit is imposed when deciding whether to start a dump, but once a dump starts, Amanda lets underlying network components do any throttling.

Individual Amanda interface definitions do not control which physical connection is used. That is left up to the operating system network software. While it's common to give an Amanda interface definition the same name as a physical connection, e.g. le0, it might be better to use logical names such as back-door-atm to avoid confusion.

The starttime dumptype parameter delays a backup some amount of time after Amanda is started. The value is entered as HHMM, so 230, for instance, would wait 2.5 hours. This may be used to delay backups of some areas until they are known to be idle.

amstatus may be used to get a summary of dumper activity:

	  
	# su amanda -c "amstatus Daily --file amdump.1 --summary"
	...
	 dumper0  busy  :  5:52:01  ( 98.03%)
	 dumper1  busy  :  0:23:09  (  6.45%)
	 dumper2  busy  :  0:13:27  (  3.75%)
	 dumper3  busy  :  0:16:13  (  4.52%)
	 dumper4  busy  :  0:06:40  (  1.86%)
	 dumper5  busy  :  0:03:39  (  1.02%) 
	   taper  busy  :  3:54:20  ( 65.26%)
        0 dumpers busy  :  0:03:21  (  0.93%) 	    file-too-large:  0:03:21  (100.00%)
	1 dumper  busy  :  4:03:22  ( 67.78%)         no-diskspace:  3:40:55  (	90.77%)
	                                            file-too-large:  0:21:13  (	 8.72%)
						      no-bandwidth:  0:01:13  (  0.50%)
	2 dumpers busy  :  0:17:33  (  4.89%)         no-bandwidth:  0:17:33  (100.00%)
	3 dumpers busy	:  0:07:42  (  2.14%)         no-bandwidth:  0:07:42  (100.00%)
	4 dumpers busy	:  0:02:05  (  0.58%)         no-bandwidth:  0:02:05  (100.00%)
	5 dumpers busy	:  0:00:40  (  0.19%)         no-bandwidth:  0:00:40  (100.00%)
	6 dumpers busy	:  0:03:33  (  0.99%)             not-idle:  0:01:53  (	53.10%)
	                                                no-dumpers:  0:01:40  ( 46.90%)
	  
	

This says:

This configuration would benefit from additional holding disk space, which would allow more dumpers to run at once and probably keep taper busy more of the time.

Other common status indicators are:

If the tape server machine has multiple tape drives, more than one Amanda configuration may run at the same time. Clients and holding disks should be assigned to only one configuration, however.

Amanda waits a fixed amount of time for a client to respond with dump size estimates. The default is five minutes per area on the client. For instance, if a client has four areas to back up (entries in disklist), Amanda waits at most 20 minutes for the estimates. During dumping, Amanda aborts a dump if the client stops sending data for 30 minutes. Various conditions, such as slow clients, which dump program is used and characteristics of the area, may cause timeouts. The values may be changed with the amanda.conf etimeout parameter for estimates and dtimeout for data. Positive etimeout values are multiplied by the number of areas. The absolute value of a negative number is used for the whole client regardless of the number of areas.

GNU-tar can exclude items from the dump image based on file name patterns controlled by the dumptype exclude parameter. A single pattern may be put on the exclude line itself or multiple patterns may be put in a file on the client. The dumptype exclude line in that case includes a list keyword and the path to the file.

Exclusion entries are shell-style wildcard expressions except * matches through any number of / characters. If a matched item is a directory, it and all its contents are omitted. For instance:

One way to restore items with Amanda is with amrecover on the client. Before amrecover can work, Amanda must run with the dumptype index parameter set to yes and the amindexd and amidxtaped services must be installed and enabled to inetd, usually on the tape server machine (the default build sequence installs them). Also, add the client to .amandahosts (or .rhosts) for the Amanda user on the server machine. Since amrecover must run as root on the client, the entry must list root as the remote user, not the Amanda user. amrecover should not be made setuid-root because it would open up catalogues of the entire system to everyone.

For this example, user jj has requested two files, both named molecule.dat, in subdirectories named work/sample-21 and work/sample-22 and said they want the versions last modified on the 13th of January. Become root on the client, cd to the area and start amrecover:

	  
	  $ su 
	  Password:
	  # cd ~jj
	  # amrecover Daily
	  AMRECOVER Version 2.4.1p1.
	  Contacting server on amanda.cc.purdue.edu ...
	  220 amanda Amanda index server (2.4.1p1) ready.
	  200 Access OK
	  Setting restore date to	today (1999-01-18)
	  200 Working date set to 1999-01-18.
	  200 Config set to Daily.
	  200 Dump host set to pete.cc.purdue.edu.
	  $CWD '/home/pete/u66/jj' is on disk '/home/pete/u66' mounted at '/home/pete/u66'.
	  200 Disk set to /home/pete/u66.
	  amrecover>
	  
	

At this point, a command line interface allows browsing the image catalogues. Move around with the cd command, see what is available with ls, change date with setdate, add files and directories to the extraction list with add and so on. The extract command starts actual recovery:

	  
	      amrecover> setdate ---14
	      200 Working date set to 1999-01-14.
	      amrecover> cd work/sample-21
	      /home/pete/u66/jj/work/sample-21
	      amrecover> add molecule.dat
	      Added /jj/work/sample-21/molecule.dat
	      amrecover> cd ../sample-22
	      /home/pete/u66/jj/work/sample-22
	      amrecover> add molecule.dat
	      Added /jj/work/sample-22/molecule.dat
	      amrecover> extract
	      Extracting files using tape drive /dev/rmt/0mn on host amanda.cc.purdue.edu.
	      The following tapes are needed: Daily-034

	      Restoring files into directory /home/pete/u66
	      Continue? [Y/n]: y

	      Load tape Daily-034 now
	      Continue? [Y/n]: y
	      Warning: ./jj: File exists
	      Warning: ./work: File exists
	      Warning: ./work/sample-21: File exists
	      Warning: ./work/sample-22: File exists
	      set owner/mode for '.'? [yn] n
	      amrecover> quit
	  
	

amrecover finds which tapes contain the images, prompts through mounting them in the proper order, searches the tape for the image, optionally decompresses it, brings it across the network to the client and pipes it into the appropriate restore program with the arguments needed to extract the requested items. amrecover does not know how to run every client restore program. See the amrecover manpage for current information. amrecover should not be used to do full filesystem recovery with vendor restore tools, but does work with GNU-tar. Vendor tools should be run with the r flag for a full recovery and amrecover is oriented toward extracting individual items with the x flag. Full filesystem recovery with vendor restore should be done with amrestore. amrecover (actually the amidxtaped server) does not know about tape changers, so mount the tapes by hand or use amtape if a changer is available.

The amrestore command retrieves whole images from tape. First, find which tapes have the desired images. The find suboption of amadmin generates output like this (abbreviated):

	  
	    # su amanda -c "amadmin Daily find pete u66"
	    Scanning /amanda...

	    date       host                 disk    	      lv tape or file   file status
	    ...
	    1999-01-12 pete.cc.purdue.edu   /home/pete/u66    1  Daily-032        14 OK
	    1999-01-13 pete.cc.purdue.edu   /home/pete/u66    1	 Daily-033        26 OK
	    1999-01-14 pete.cc.purdue.edu   /home/pete/u66    1  Daily-034        40 OK
	    1999-01-15 pete.cc.purdue.edu   /home/pete/u66    1  Daily-000        34 OK
	    1999-01-16 pete.cc.purdue.edu   /home/pete/u66    1  Daily-001        31 OK
	    1999-01-17 pete.cc.purdue.edu   /home/pete/u66    0  Daily-002        50 OK
	    1999-01-18 pete.cc.purdue.edu   /home/pete/u66    1  Daily-003        20 OK
	  
	

The Scanning /amanda... message says amadmin looked in the holding disk (/amanda) for any images left there. It then lists all tapes or files in the holding disk that contain the requested area.

The info suboption to amadmin shows tapes with the most recent images:

	  
	    # su amanda -c "amadmin Daily info pete u66"
	    Current info for pete.cc.purdue.edu /home/pete/u66: 
	    Stats: dump rates (kps), Full:  652.0, 648.0, 631.0
	                      Incremental:  106.0, 258.0, 235.0
	            compressed size, Full: -100.0%,-100.0%,-100.0%
		              Incremental: -100.0%,-100.0%,-100.0% 
	    Dumps: lev datestmp  tape             file   origK   compK secs 
	            0  19990117  Daily-002          50  582239  582272	892 
		    1  19990118  Daily-003          20    3263    3296	 31 
		    2  19981214  Daily-032          21    7039    7072   37
	  
	

Old information may appear, such as 19981214 (14-Dec-1998) in this example. While it's true this was the last level 2 dump of this area, it is of little interest because at least one full and level 1 dump have been done since then. The compressed size values here may be ignored because this particular configuration uses hardware compression so no software compression data are available.

A third way to know what tape has an image is to generate a tape table of contents with amtoc after each Amanda run:

	  
	    #  partition                      	lvl  size[Kb]  method
	    0  Daily-002                          -         -  19990117
	    1  boiler.cc.purdue.edu:/usr/local    1        31  normal
	    2  egbert.cc.purdue.edu:/opt          1       127  normal
	    3  boiler.cc.purdue.edu:/usr          1        95  normal
	   ...
	   50 pete.cc.purdue.edu:/home/pete/u66   0    582239  normal
	   ...
	  
	

A printed report similar to the amtoc output may be automatically generated by amreport for each run with the lbl-templ tapetype parameter in amanda.conf using the example/3hole.ps template.

The find and info suboptions to amadmin need the Amanda log files and database. These are not usually large amounts of information and a copy should be pushed after each amdump run to an alternate machine that also has the Amanda tape server software installed so they are available if the primary tape server machine dies. Tools like rdist (ftp://usc.edu/pub/rdist/) or rsync (ftp://samba.anu.edu.au/pub/rsync/) are useful.

If Amanda was built using --with-db=text (the default), the database is stored in a set of text files under the directory listed in the infofile amanda.conf parameter. Here is the file that matches the above info amadmin output:

	  
	    # cd /usr/local/etc/amanda/Daily/curinfo
	    # cat pete.cc.purdue.edu/_home_pete_u66/info
	    version: 0
	    command: 0
	    full-rate: 652.000000 648.000000 631.000000
	    full-comp:
	    incr-rate: 106.000000 258.000000 235.000000
	    incr-comp:
	    stats: 0 582239 582272 892 916549924 50 Daily-002
	    stats: 1 3263 3296 31 916637269 20 Daily-003
	    stats: 2 7039 7072 37 913614357 21 Daily-032
	    //
	  
	

The first field of each stats line is the dump level. The last field is the VSN and the field just before it is the tape file number. The field with the large number just before that is a Unix epoch time value, which may be converted to text with this Perl script:

	  
	    $ cat epoch.pl
	    #!/usr/local/bin/perl
	    use warnings;
	    use strict; 
	    require 'ctime.pl';
	    foreach (@ARGV) { 
	      s/,//; 
	      if (m/[a-fA-FxX]/) {
	      	unless (m/^0[xX]/) { 
		  $_ = '0x' . $_; 
		} 
		$_ = oct; 
	      }
	      print &ctime ($_);
	    }
	    exit (0);
	    $ epoch.pl 916549924
	    Sun Jan 17 0:12:04 US/East-Indiana 1999
	  
	

Prepositioning the tape to the image with mt fsf may significantly reduce the time needed to do a restore. Some media contain an index for very fast file searching compared to the one file at a time scanning done by amrestore. Each tape location method listed above also shows the tape file. Use that number with mt fsf after a rewind to position to a particular image.

amrestore takes client, area and date stamp patterns as optional arguments to search for matching images. Each argument is a grep-style regular expression, so multiple images may match. This also means an image may need a specific pattern. For instance:

	  
	    # amrestore $TAPE pete /
	  
	

finds not just the root area for the pete client, but images for any client with pete someplace in the hostname and a slash anywhere in the area name. Assuming only one client matches pete, the following gets just the root area:

	  
	    # amrestore $TAPE pete '^/$'
	  
	

The up arrow (caret) at the beginning says the pattern must start with this string. The dollar sign at the end says it must end there. The quote marks around the pattern protect the special characters from shell expansion.

Without flags, amrestore finds every matching image, uncompresses it if needed and creates a disk file in the current working directory with a name made up of the client, area and dump level. These images may be used directly by the client restore program.

amrestore may be used to generate a tape table of contents by giving it a host pattern that cannot match:

	  
	    # mt rewind
	    # amrestore $TAPE no.such.host
	  
	

As it searches in vain for no.such.host it reports images that are skipped:

	  
	    amrestore: 0: skipping start of tape: date 19990117 label Daily-002
	    amrestore: 1: skipping boiler.cc.purdue.edu._.19990117.1
	    amrestore: 2: skipping egbert.cc.purdue.edu._opt.19990117.1
	    amrestore: 3: skipping boiler.cc.purdue.edu._.19990117.1
	    ...
	  
	

For large images, the p flag writes the first match to standard output, which may then be piped into the client restore program. This flag is also useful for moving an image across the network. For instance, here is one way to restore a file directly from the tape server (amanda.cc.purdue.edu) while logged in to the client:

	  
	    # rsh -n amanda.cc.purdue.edu amrestore -p $TAPE pete
	?'^/$? ' \ | gtar xf - ./the-file
	  
	

Tell vendor restore programs to use a small blocking factor to handle the arbitrary size chunks of data available through a pipeline:

	  
	    # rsh -n amanda.cc.purdue.edu amrestore -p $TAPE pete u66 \ |
	    ufsrestore -ivbf 2 -
	  
	

The Amanda tape format is deliberately simple and restoring data can be done without any Amanda tools if necessary. The first tape file is a volume label with the tape VSN and date it was written. It is not in ANSI VOL1 format, but is plain text. Each file after that contains one image using 32 KByte blocks. The first block is an Amanda header with client, area and options used to create the image. As with the volume label, the header is not in ANSI format, but is plain text. The image follows, starting at the next tape block, until end of file.

To retrieve an image with standard Unix utilities if amrestore is not available, position the tape to the image, then use dd to read it:

	  
	    # mt rewind
	    # mt fsf NN
	    # dd if=$TAPE bs=32k skip=1 of=dump_image
	  
	

The skip=1 option tells dd to skip over the Amanda file header. Without the of= option, dd writes the image to standard output, which can be piped to the decompression program, if needed, and then to the client restore program.

Since the image header is text, it may be viewed with:

	  
	    # mt rewind
	    # mt fsf NN
	    # dd if=$TAPE bs=32k count=1
	  
	

In addition to describing the image, it contains text showing the commands needed to do a restore. Here's a typical entry for the root filesystem on pete.cc.purdue.edu. It is a level 1 dump done without compression using the vendor ufsdump program:

	  
	    
	      Amanda: FILE 19981206 pete.cc.purdue.edu / lev 1
	      comp N program /usr/sbin/ufsdump
	    
	  
	

To restore, position the tape at start of file and run:

	  
	    # dd if=$TAPE bs=32k skip=1 | /usr/sbin/ufsrestore -f... -
	  
	

As with any backup system, test these procedures while in normal production so the principles and techniques are familiar when disaster strikes.