2 Chapter 16. Using AMANDA
3 Prev Part IV. Various Information Next
5 -------------------------------------------------------------------------------
7 Chapter 16. Using AMANDA
20 <ghenry@suretecsystems.com>
24 XML-conversion, Updates
34 Future_Capabilities_of_AMANDA
41 Install_Related_Packages
43 Perform_Preliminary_Setup
45 Configure_the_AMANDA_Build
47 Build_and_Install_AMANDA
51 Decide_on_a_Tape_Server
53 Decide_Which_Tape_Devices_to_Use
55 Decide_Whether_to_Use_Compression
57 Decide_Where_the_Holding_Space_Will_Be
59 Compute_Your_Dump_Cycle
61 Copy_and_Edit_the_Default_Configuration_File
63 Configure_the_Holding_Disk
65 Configure_Tape_Devices_and_Label_Tapes
67 Configure_Backup_Clients
79 Monitor_Tape_and_Holding_Disk_Status
81 Adding_Tapes_at_a_Particular_Position_in_the_Cycle
83 Miscellanous_Operational_Notes
86 Advanced_AMANDA_Configuration
89 Adjust_the_Backup_Cycle
93 Monitor_for_Possible_Improvements
101 Configuring_and_Using_amrecover
105 Restoring_Without_AMANDA
111 Refer to http://www.amanda.org/docs/using.html for the current version of this
119 This chapter was written by John R. Jackson with input from Alexandre Oliva. It
120 is part of the O'Reilly book "Unix Backup & Recovery" by W. Curtis Preston and
121 has been provided online at http://www.backupcentral.com/amanda.html since the
122 first edition of this book.
123 During the Docbook-conversion of the AMANDA-docs we asked for permission to
124 include this chapter in the Official AMANDA documentation and W. Curtis Preston
125 allowed to us to include the now converted version. There will be some updates
126 to this chapter in the next few months to reflect various changes and
128 You can find online versions of this chapter at http://www.amanda.org/docs/
129 using.html and at http://www.backupcentral.com/amanda.html.
130 AMANDA, the Advanced Maryland Automated Network Disk Archiver, is a public
131 domain utility developed at the University of Maryland. It is as advanced as a
132 free backup utility gets, and has quite a large user community. AMANDA allows
133 you to set up a single master backup server to back up multiple hosts to a
134 single backup drive. (It also works with a number of stackers.) AMANDA uses
135 native dump and/or GNU-tar, and can back up a large number of workstations
136 running multiple versions of Unix. Recent versions can also use SAMBA to back
137 up Microsoft Windows (95/98/NT/2000)-based hosts. More information about AMANDA
138 can be found at http://www.amanda.org
139 AMANDA was written primarily by James da Silva at the Department of Computer
140 Science of the University of Maryland around 1992. The goal was to be able to
141 back up large numbers of client workstations to a single backup server machine.
142 AMANDA was driven by the introduction of large capacity tape drives, such as
143 ExaByte 8mm and DAT 4mm. With these drives, and the increased number of
144 personal workstations, it no longer made sense to back up individual machines
145 to separate media. Coordinating access and providing tape hardware was
146 prohibitive in effort and cost. A typical solution to this problem reaches out
147 to each client from the tape host and dumps areas one by one across the
148 network. But this usually cannot feed the tape drive fast enough to keep it in
149 streaming mode, causing a severe performance penalty.
153 Since AMANDA is optimized to take advantage of tape drives, we will use the
154 word tape throughout this section. However, that doesn't mean that you couldn
\19t
155 use it with an optical or CD-R drive.
156 The AMANDA approach is to use a "holding disk" on the tape server machine, do
157 several dumps in parallel into files in the holding disk, and have an
158 independent process take data out of the holding disk. Because most dumps are
159 small partials, even a modest amount of holding disk space can provide an
160 almost optimal flow of dump images onto tape.
161 AMANDA also has a unique approach to scheduling dumps. A "dump cycle" is
162 defined for each area to control the maximum time between full dumps. AMANDA
163 takes that information, statistics about past dump performance, and estimates
164 on the size of dumps for this run to decide which backup level to do. This gets
165 away from the traditional static "it's Friday so do a full dump of /usr on
166 client A" approach and frees AMANDA to balance the dumps so the total run time
167 is roughly constant from day to day.
168 AMANDA is freely-available software maintained by the AMANDA Users Group. Based
169 on membership of AMANDA-related mailing lists, there are probably well over
170 1500 sites using it. This chapter is based on AMANDA version 2.4.2. Updated
171 versions of this section will be available with the AMANDA source code.
175 AMANDA is designed to handle large numbers of clients and data, yet is
176 reasonably simple to install and maintain. It scales well, so small
177 configurations, even a single host, are possible. The code is portable to a
178 large number of Unix platforms. It calls standard backup software, such as
179 vendor provided dump or GNU-tar, to perform actual client dumping. There is
180 also support for backing up Windows-based hosts via SAMBA. There is no
181 Macintosh support yet.
182 AMANDA provides its own network protocols on top of TCP and UDP. It does not,
183 for instance, use rsh or rdump/rmt. Each client backup program is instructed to
184 write to standard output, which AMANDA collects and transmits to the tape
185 server host. This allows AMANDA to insert compression and encryption and also
186 gather a catalogue of the image for recovery. Multiple clients are typically
187 backed up in parallel to files in one or more holding disk areas. A separate
188 tape writing process strives to keep the tape device streaming at maximum
189 throughput. AMANDA can run direct to tape without holding disks, but with
191 AMANDA supports using more than one tape in a single run, but does not yet
192 split a dump image across tapes. This also means it does not support dump
193 images larger than a single tape. AMANDA currently starts a new tape for each
194 run and does not provide a mechanism to append a new run to the same tape as a
195 previous run, which might be an issue for small configurations.
196 AMANDA supports a wide range of tape storage devices. It uses basic operations
197 through the normal operating system I/O subsystem and a simple definition of
198 characteristics. New devices are usually trivial to add. Several tape changers,
199 stackers, and robots are supported to provide truly hands-off operation. The
200 changer interface is external to AMANDA and well-documented, so unsupported
201 changers can be added without a lot of effort.
202 Either the client or tape server may do software compression, or hardware
203 compression may be used. On the client side, software compression reduces
204 network traffic. On the server side, it reduces client CPU load. Software
205 compression may be selected on an image-by-image basis. If Kerberos is
206 available, clients may use it for authentication and dump images may be
207 encrypted. Without Kerberos, .amandahosts authentication (similar to .rhosts)
208 is used, or AMANDA may be configured to use .rhosts (although rsh/rlogin/rexec
209 are not themselves used). AMANDA works well with security tools like TCP
210 Wrappers (ftp://info.cert.org/pub/network_tools) and firewalls.
211 Since standard software is used for generating dump images and software
212 compression, only normal Unix tools such as mt, dd, and gunzip/uncompress are
213 needed to recover a dump image from tape if AMANDA is not available. When
214 AMANDA software is available, it locates which tapes are needed and finds
216 AMANDA is meant to run unattended, such as from a nightly cron job. Client
217 hosts that are down or hung are noted and bypassed. Tape errors cause AMANDA to
218 fall back to ?degraded? mode where backups are still performed but only to the
219 holding disks. They may be flushed to tape by hand after the problem is
221 AMANDA has configuration options for controlling almost all aspects of the
222 backup operation and provides several scheduling methods. A typical
223 configuration does periodic full dumps with partial dumps in between. There is
226 * Periodic archival backup, such as taking full dumps to a vault away from the
228 * Incremental-only backups where full dumps are done outside of AMANDA, such as
229 very active areas that must be taken offline, or no full dumps at all for
230 areas that can easily be recovered from vendor media.
231 * Always doing full dumps, such as database areas that change completely
232 between each run or critical areas that are easier to deal with during an
233 emergency if they are a single-restore operation.
235 It's easy to support multiple configurations on the same tape server machine,
236 such as a periodic archival configuration along side a normal daily
237 configuration. Multiple configurations can run simultaneously on the same tape
238 server if there are multiple tape drives.
239 Scheduling of full dumps is typically left up to AMANDA. They are scattered
240 throughout the dump cycle to balance the amount of data backed up each run.
241 It's important to keep logs of where backup images are for each area (which
242 AMANDA does for you), since they are not on a specific, predictable, tape
243 (e.g., the Friday tape will not always have a full dump of /usr for client A).
244 The partial backup level is also left to AMANDA. History information about
245 previous levels is kept and the backup level automatically increases when
246 sufficient dump size savings will be realized.
247 AMANDA uses a simple tape management system and protects itself from
248 overwriting tapes that still have valid dump images and from tapes not
249 allocated to the configuration. Images may be overwritten when a client is down
250 for an extended period or if not enough tapes are allocated, but only after
251 AMANDA has issued several warnings. AMANDA can also be told to not reuse
253 A validation program may be used before each run to note potential problems
254 during normal working hours when they are easier to correct. An activity report
255 is sent via e-mail after each run. AMANDA can also send a report to a printer
256 and even generate sticky tape labels.
257 There is no graphical interface. For administration, there is usually only a
258 single simple text file to edit, so this is not much of an issue. For security
259 reasons, AMANDA does not support user controlled file recovery. There is an
260 ftp-like restore utility for administrators to make searching online dump
261 catalogues easier when recovering individual files.
263 Future Capabilities of AMANDA
265 In addition to the usual enhancements and fixes constantly being added by the
266 AMANDA Core Development Team, three main changes are in various stages of
269 * A new internal security framework will make it easier for developers to add
270 other security methods, such as SSH (ftp://ftp.cs.hut.fi/pub/ssh/) and SSL
271 (Secure Socket Layer).
272 * Another major project is a redesign of how AMANDA runs the client dump
273 program. This is currently hardcoded for a vendor dump program, GNU-tar or
274 SAMBA tar. The new mechanism will allow arbitrary programs such as cpio,
275 star, and possibly other backup systems. It will also add optional pre-dump
276 and post-dump steps that can be used for locking and unlocking, and snapshots
277 of rapidly changing data such as databases or the Windows registry.
278 * The third major project is a redesign of the output subsystem to support non-
279 tape media such as CD-ROM, local files, remote files via tools like rcp and
280 ftp, remote tapes, etc. It will also be able to split dump images across
281 media, handle multiple simultaneous media of different types such as writing
282 to multiple tapes or a tape and a CD-ROM, and handle writing copies of images
283 to multiple media such as a tape to keep on site and a CD-ROM or duplicate
285 * In addition, the output format will be enhanced to include a file-1 and a
286 file-n. The idea is to put site-defined emergency recovery tools in file-1
287 (the first file on the output) that can be retrieved easily with standard
288 non-AMANDA programs like tar, then use those tools to retrieve the rest of
289 the data. The file-n area is the last file on the output and can contain
290 items such as the AMANDA database, which would be complete and up to date by
291 the time file-n is written.
296 AMANDA may be obtained via the web page http://www.amanda.org or with anonymous
297 ftp at ftp://ftp.amanda.org/pub/amanda.A typical release is a gzip compressed
298 tar file with a name like amanda-2.4.1.tar.gz, which means it is major version
299 2.4 and minor version 1. There are occasional patch releases that have a name
300 like amanda-2.4.1p1.tar.gz (release 2.4.1 plus patch set 1). Beta test pre-
301 releases have a names like amanda-2.5.0b3.tar.gz (third beta test pre-release
303 Some operating system distributions provide pre-compiled versions of AMANDA,
304 but because AMANDA hardcodes some values into the programs, they may not match
305 the configuration. Work is being done to move these values to run-time
306 configuration files, but for now AMANDA should be built from source.
307 The AMANDA web page contains useful information about patches not yet part of a
308 release, how to subscribe to related mailing lists, and pointers to mailing
309 list archives. Subscribe to at least amanda-announce to get new release
310 announcements or amanda-users to get announcements plus see problems and
311 resolutions from other AMANDA users. The amanda-users mailing list is a
312 particularly good resource for help with initial setup as well as problems.
313 When posting to it, be sure to include the following information:
316 * OS version on the server and client(s)
317 * Exact symptoms seen, such as error messages, relevant sections of e-mail
318 reports, debugging and log files
319 * Anything unusual or recent changes to the environment
320 * A valid return e-mail address
322 Finally, the docs directory in the release contains several files with helpful
323 information, such as a FAQ.
327 After downloading and unpacking the AMANDA release, read the README, docs/
328 INSTALL, and docs/SYSTEM.NOTES files. They contain important and up-to-date
329 information about how to set up AMANDA.
331 Install Related Packages
333 Several other packages may be required to complete an AMANDA install. Before
334 continuing, you should locate and install packages your environment will need.
335 In particular, consider the following:
338 GNU-tar 1.12 or later
\14 www.gnu.org
339 The GNU version of the standard tar program with enhancements to do
340 partial backups and omit selected files. It is one of the client backup
341 programs AMANDA knows how to use.
343 Samba 1.9.18p10 or later
\14 www.samba.org
344 SAMBA is an implementation of the System Message Block (SMB) protocol
345 used by Windows-based systems for file access. It contains a tool,
346 smbclient, that AMANDA can use to back them up.
348 Perl 5.004 or later
\14 www.perl.org
349 Perl is a scripting programming language oriented toward systems
350 programming and text manipulation. It is used for a few optional AMANDA
351 reporting tools and by some tape changers.
353 GNU readline 2.2.1 or later
\14 www.gnu.org
354 The GNU readline library may be incorporated into interactive programs to
355 provide command-line history and editing. It is built into the AMANDA
356 amrecover restoration tool, if available.
358 GNU awk 3.0.3 or later
\14 www.gnu.org
359 The GNU version of the awk programming language contains a common version
360 across platforms and some additional features. It is used for the
361 optional AMANDA amplot statistics tool.
363 Gnuplot 3.5 or later
\14 ftp://ftp.dartmouth.edu/pub/gnuplot/
364 This gnuplot library (which has nothing to do with the GNU tools, see the
365 accompanying README) is a graph plotting package. It is used for the
366 optional AMANDA amplot statistics tool.
368 Be sure to look in the AMANDA patches directory and the patches section on the
369 web page for updates to these packages. SAMBA versions before 2.0.3, in
370 particular, must have patches applied to make them work properly with Amanda.
371 Without the patches, backups appear to work but the resulting images are
373 When AMANDA is configured, locations of additional software used on the
374 clients, such as GNU-tar and SAMBA, get built into the AMANDA programs, so
375 additional software must be installed in the same place on the AMANDA build
376 machine and all the clients.
378 Perform Preliminary Setup
380 A typical AMANDA configuration runs as a user other than root, such as backup
381 or amanda, given just enough permissions to do backups. Often, direct login as
382 the user is disallowed. To use the vendor dump program instead of GNU-tar, the
383 AMANDA user must be in a group with read access to the raw disk devices.
384 Membership in this group should be tightly controlled since it opens up every
385 file on the client for viewing.
386 There are two ways to link AMANDA and the raw device group membership. Either
387 put the AMANDA user in the group that currently owns the raw devices, as the
388 primary group or as a secondary, or pick a new group for AMANDA and change the
389 group ownership of the devices. AMANDA (actually, the vendor dump program)
390 needs only read access, so turn off group write permission. Turn off all
392 To use GNU-tar, AMANDA runs it under a setuid-root program that grants the
393 needed permissions. The GNU version of tar must be used with AMANDA. Vendor
394 supplied versions (unless they originated from GNU and are at least version
395 1.12) do not work because AMANDA depends on additional features.
397 Configure the AMANDA Build
399 Use the AMANDA user and group for the --with-user and --with-group options to
400 ./configure. For instance, to use amanda for the user and backup as the group:
401 ./configure --with-user=amanda --with-group=backup ...
402 No other options are required for ./configure, but all the possibilities may be
403 seen with ./configure --help. Don't get carried away changing options. The
404 defaults are usually suitable and some require experience with AMANDA to fully
405 understand. Leave --with-debugging enabled so debug log files are created on
406 the clients. They take very little space but are often necessary for tracking
408 The normal build creates both tape server and client software. The tape server
409 host is often backed up by AMANDA and needs the client parts. However, the
410 clients usually do not need the tape server parts. A little disk space and
411 build time may be saved by adding --without-server to the ./configure arguments
412 when building for them.
413 The default security mechanism uses a file formatted just like .rhosts but
414 called .amandahosts. This keeps AMANDA operations separate from normal rsh/rcp
415 work that might use the same user. It is not recommended, but .rhosts and
416 hosts.equiv may be used by adding --without-amandahosts to the ./configure
418 The TCP ports used for data transfer may be restricted with --with-portrange to
419 use AMANDA between hosts separated by a firewall. A typical entry would be: ./
420 configure --with-portrange=50000,50100 ... This does not affect the initial UDP
421 requests made from the tape server to the clients. The amanda UDP port
422 (typically 10080) must be allowed through the firewall.
423 If more than just a few ./configure options are used, they may be put in /usr/
424 local/share/config.site or /usr/local/etc/config.site to keep them the same
425 from build to build. An example is in example/config.site.
427 Build and Install AMANDA
429 After ./configure is done, run make to build AMANDA, then make install to
430 install it. The make install step must be done as root because some AMANDA
431 programs require system privileges. Unless the base location is changed, AMANDA
432 installs into these areas:
436 Programs administrators run.
442 Private programs only AMANDA uses.
447 Now is a good time to read the main AMANDA man page. It provides an overview of
448 AMANDA, a description of each program, and detailed configuration information.
449 The following programs must be setuid-root (which make install as root does).
450 The first group (amcheck,dumper, and planner) run on the tape server machine
451 and need a privileged network port for secure communication with the clients.
452 The others are utility routines optionally used on the clients, depending on
453 the dump program used and operating system type.
457 AMANDA sanity checker program
460 Client communication program
463 Estimate gathering program
466 Used to kill vendor dump programs that run as root
469 Setuid wrapper for systems that need to run the vendor dump program as
473 Setuid wrapper to run GNU-tar as root
475 All these programs are installed with world access disabled and group access
476 set to the AMANDA group from --with-group. Be sure all members of that group
477 are trustworthy since rundump and runtar in particular give access to every
478 file on the system. If AMANDA software is made available via NFS, be sure the
479 mount options allow setuid programs. Also, if GNU-tar is used, root needs write
480 access to /usr/local/var/amanda/gnutar-lists (or the --with-gnutar-list value
481 to ./configure) to store information about each partial level.
482 If the build has trouble or AMANDA needs to be rebuilt, especially with
483 different ./configure options, the following sequence makes sure everything is
484 cleaned up from the previous build: make distclean ./configure ... make make
485 install (as root) Problems with the ./configure step can sometimes be diagnosed
486 by looking at the config.log file. It contains detailed output of tests ./
487 configure runs. Note that it is normal for many of the tests to "fail" as part
488 of ./configure determining how to access various features on the system.
489 A common problem when using the GNU C compiler is not re-installing it after
490 the underlying operating system version changes. Gcc is particularly sensitive
491 to system header files and must be re-installed or have its fixincludes step
492 rerun (see the gcc release installation notes) if the operating system is
493 upgraded. Running gcc --verbose shows where gcc gets its information, and
494 contains an indication of the operating system version expected.
495 AMANDA needs changes to the network services and inetd configuration files. The
496 client-src/patch-system script should be able to set up systems in most cases.
497 It does not currently handle systems that deliver service entries via YP/NIS.
498 If the script does not work, add the following entries to the services file
499 (e.g., /etc/services) or YP/NIS map: Amanda 10080/udp Amandaidx 10082/tcp
501 Each client needs an entry in the inetd configuration file (e.g., /etc/
502 inetd.conf) like this, substituting the AMANDA user for Amanda and the full
503 path to the AMANDA libexec directory for PATH: amanda dgram udp wait Amanda /
504 PATH/libexec/amandad amandad
505 The amanda service is used by all AMANDA controlling programs to perform
506 functions on the clients.
507 The tape server host needs entries like these if the amrecover tool is to be
508 used: amandaidx stream tcp nowait Amanda /PATH/libexec/amindexd amindexd
509 amidxtape stream tcp nowait Amanda /PATH/libexec/amidxtaped amidxtaped
510 The amandaidx service provides access to the catalogues, while amidxtape
511 provides remote access to a tape device. After every inetd configuration file
512 change, send a HUP signal to the inetd process and check the system logs for
517 Once installed, AMANDA must be configured to your environment.
519 Decide on a Tape Server
521 The first thing to decide is what machine will be the AMANDA tape server.
522 AMANDA can be CPU-intensive if configured to do server compression, and almost
523 certainly network and I/O-intensive. It does not typically use much real
524 memory. It needs direct access to a tape device that supports media with enough
525 capacity to handle the expected load.
526 To get a rough idea of the backup sizes, take total disk usage (not capacity),
527 Usage, and divide it by how often full dumps will be done, Runs. Pick an
528 estimated run-to-run change rate, Change. Each AMANDA run, on average, does a
529 full dump of Usage/Runs. Another Usage/Runs*Change is done of areas that got a
530 full dump the previous run, Usage/Runs*Change* is done of areas that got a full
531 dump two runs ago, and so on.
532 For example, with 100 GB of space in use, a full dump every seven runs (e.g.,
533 days) and estimated run-to-run changes (new or altered files) of 5 percent:
535 100 GBytes / 7 = 14.3 GB
536 100 GBytes / 7 * 5% = 0.7 GB
537 100 GBytes / 7 * 5% * 2 = 1.4 GB
538 100 GBytes / 7 * 5% * 3 = 2.1 GB
539 100 GBytes / 7 * 5% * 4 = 2.9 GB
540 100 GBytes / 7 * 5% * 5 = 3.6 GB
541 100 GBytes / 7 * 5% * 6 = 4.3 GB
545 If 50 percent compression is expected, the actual amount of tape capacity
546 needed for each run, which might be on more than one tape, would be 14.7 GB.
547 This is very simplistic, and could be improved with greater knowledge of actual
548 usage, but should be close enough to start with. It also gives an estimate of
549 how long each run will take by dividing expected capacity by drive speed.
551 Decide Which Tape Devices to Use
553 Unix operating systems typically incorporate device characteristics into the
554 file name used to access a tape device. The two to be concerned with are
555 "rewind" and "compression." AMANDA must be configured with the non-rewinding
556 tape device, so called because when the device is opened and closed it stays at
557 the same position and does not automatically rewind. This is typically a name
558 with an n in it, such as /dev/rmt/0n or /dev/nst0. On AIX, it is a name with a
560 Put the AMANDA user in the group that currently owns the tape device, either as
561 the primary group or as a secondary, or pick a new group for AMANDA and change
562 the group ownership of the device. AMANDA needs both read and write access.
563 Turn off all "world" access.
565 Decide Whether to Use Compression
567 Dump images may optionally be compressed on the client, the tape server, or the
568 tape device hardware. Software compression allows AMANDA to track usage and
569 make better estimates of image sizes, but hardware compression is more
570 efficient of CPU resources. Turn off hardware compression when using software
571 compression on the client or server. See the operating system documentation for
572 how hardware compression is controlled; on many systems it is done via the
573 device file name just like the non-rewinding flag. AIX uses the chdev command.
575 Decide Where the Holding Space Will Be
577 If at all possible, allocate some holding disk space for AMANDA on the tape
578 server. Holding disk space can significantly reduce backup time by allowing
579 several dumps to be done at once while the tape is being written. Also, for
580 streaming tape devices, AMANDA keeps the device going at speed, and that may
581 increase capacity. AMANDA may be configured to limit disk use to a specific
582 value so it can share with other applications, but a better approach is to
583 allocate one or more inexpensive disks entirely to AMANDA.
584 Ideally, there should be enough holding disk space for the two largest backup
585 images simultaneously, so one image can be coming into the holding disk while
586 the other is being written to tape. If that is not practical, any amount that
587 holds at least a few of the smaller images helps. The AMANDA report for each
588 run shows the size of the dump image after software compression (if enabled).
589 That, in addition to the amplot and amstatus tools, may be used to tune the
592 Compute Your Dump Cycle
594 Decide how often AMANDA should do full dumps. This is the "dump cycle." Short
595 periods make restores easier because there are fewer partials, but use more
596 tape and time. Longer periods let AMANDA spread the load better but may require
597 more steps during a restore.
598 Large amounts of data to back up or small capacity tape devices also affect the
599 dump cycle. Choose a period long enough that AMANDA can do a full dump of every
600 area during the dump cycle and still have room in each run for the partials.
601 Typical dump cycles are one or two weeks. Remember that the dump cycle is an
602 upper limit on how often full dumps are done, not a strict value. AMANDA runs
603 them more often and at various times during the cycle as it balances the backup
604 load. It violates the limit only if a dump fails repeatedly, and issues
605 warnings in the e-mail report if that is about to happen.
606 By default, AMANDA assumes it is run every day. If that is not the case, set
607 "runs per cycle" (described below) to a different value. For instance, a dump
608 cycle of seven days and runs per cycle of five would be used if runs are done
610 Normally, AMANDA uses one tape per run. With a tape changer (even the chg-
611 manual one), the number of tapes per run may be set higher for extra capacity.
612 This is an upper limit on the number of tapes. AMANDA uses only as much tape as
613 it needs. AMANDA does not yet do overflow from one tape to another. If it hits
614 end of tape (or any other error) while writing an image, that tape is
615 unmounted, the next one is loaded, and the image starts over from the
616 beginning. This sequence continues if the image cannot fit on a tape.
617 Runs per cycle and tapes per run determine the minimum number of tapes needed,
618 called the "tape cycle." To ensure the current run is not overwriting the last
619 full dump, one more run should be included. For instance, a dump cycle of two
620 weeks, with default runs per cycle of 14 (every day) and default tapes per run
621 of one, needs at least 15 tapes (14+1 runs * one tape/run). Using two tapes per
622 run needs 30 tapes (14+1 runs * two tapes/run). Doing backups just on weekdays
623 with a dump cycle of two weeks, runs per cycle of 10, and two tapes per run
624 needs 22 tapes (10+1 runs * two tapes/run).
625 More tapes than the minimum should be allocated to handle error situations.
626 Allocating at least two times the minimum allows the previous full dump to be
627 used if the most recent full dump cannot be read. Allocating more tapes than
628 needed also goes back further in time to recover lost files. AMANDA does not
629 have a limit on the number of tapes in the tape cycle.
631 Copy and Edit the Default Configuration File
633 Pick a name for the configuration (the name Daily will be used for the rest of
634 this section). Create a directory on the tape server machine to hold the
635 configuration files, typically /usr/local/etc/amanda/Daily. Access to this
636 directory (or perhaps its parent) should be restricted to the AMANDA group or
637 even just the AMANDA user.
638 Each tape assigned to a configuration needs a unique label. For this example,
639 we'll use the configuration name, a dash, and a three-digit suffix, Daily-000
640 through Daily-999. Do not use blanks, tabs, slashes (/), shell wildcards, or
641 non-printable characters.
642 AMANDA limits network usage so backups do not take all the capacity. This limit
643 is imposed when AMANDA is deciding whether to perform a dump by estimating the
644 throughput and adding that to dumps that are already running. If the value
645 exceeds the bandwidth allocated to AMANDA, the dump is deferred until enough
646 others complete. Once a dump starts, AMANDA lets underlying network components
648 Copy the template example/amanda.conf file to the configuration directory and
649 edit it. Full documentation is in the amanda man page. There are many
650 parameters, but probably only a few need to be changed. Start with the
651 following (some of which are described later):
655 This string will be in the Subject line of AMANDA e-mail reports.
658 Target address for AMANDA e-mail reports.
661 Same as --with-user from ./configure.
673 Number of tapes to use per run.
676 The no-rewind tape device if a changer is not being used, or if the
677 manual changer is being used.
683 Network bandwidth allocated to AMANDA.
686 A regular expression (grep pattern) used to make sure each tape is
687 allocated to this AMANDA configuration. Our example might use Daily-[0-9]
690 The following parameters probably do not need to be changed, but look at their
691 values to know where AMANDA expects to find things:
695 Location of AMANDA history database. Older versions of AMANDA used this
696 as the base name of a database file. Newer versions use this as a
700 Directory where AMANDA logs are stored.
703 Location of optional AMANDA catalogue database.
706 Configure the Holding Disk
708 Define each holding disk in an amanda.conf holdingdisk section. If partitions
709 are dedicated to AMANDA, set the use value to a small negative number, such as
710 -10 MB. This tells AMANDA to use all but that amount of space. If space is
711 shared with other applications, set the value to the amount AMANDA may use,
712 create the directory and set the permissions so only the AMANDA user can access
714 Set a chunksize value for each holding disk. Negative numbers cause AMANDA to
715 write dumps larger than the absolute value directly to tape, bypassing the
716 holding disk. Positive numbers split dumps in the holding disk into chunks no
717 larger than the chunksize value. Even though the images are split in the
718 holding disk, they are written to tape as a single image. At the moment, all
719 chunks for a given image go to the same holding disk.
720 Older operating systems that do not support individual files larger than 2GB
721 need a chunk size slightly smaller, such as 2000 MB, so the holding disk can
722 still be used for very large dump images. Systems that support individual files
723 larger than 2 GB should have a very large value, such as 2000 GBytes.
725 Configure Tape Devices and Label Tapes
727 AMANDA needs to know some characteristics of the tape media. This is set in a
728 tapetype section. The example amanda.conf, web page, and amanda-users mailing
729 list archives have entries for most common media. Currently, all tapes should
730 have the same characteristics. For instance, do not use both 60-meter and 90-
731 meter DAT tapes since AMANDA must be told the smaller value, and larger tapes
732 may be underutilized.
733 If the media type is not listed and there are no references to it in the
734 mailing list archives, go to the tape-src directory, make tapetype, mount a
735 scratch tape in the drive and run ./tapetype NAME DEV where NAME is a text name
736 for the media and DEV is the no-rewind tape device with hardware compression
737 disabled. This program rewinds the tape, writes random data until it fills the
738 tape, rewinds, and then writes random data and tape marks until it fills the
739 tape again. This can take a very long time (hours or days). When finished, it
740 generates a new tapetype section to standard output suitable for adding to the
741 amanda.conf file. Post the results to the amanda-users mailing list so others
742 may benefit from your effort.
743 When using hardware compression, change the length value based on the estimated
744 compression rate. This typically means multiplying by something between 1.5 and
746 The length and filemark values are used by AMANDA only to plan the backup
747 schedule. Once dumps start, AMANDA ignores the values and writes until it gets
748 an error. It does not stop writing just because it reaches the tapetype length.
749 AMANDA does not currently use the tapetype speed parameter.
750 Once the tapetype definition is in amanda.conf, set the tapetype parameter to
752 Without special hardware to mount tapes, such as a robot or stacker, either set
753 the tapedev parameter to the no-rewind device name or set up the AMANDA chg-
754 manual changer. The manual changer script prompts for tape mounts as needed.
755 The prompts normally go to the terminal of the person running AMANDA, but the
756 changer may be configured to send requests via e-mail or to some other system
758 To configure the manual changer, set tapedev to the no-rewind tape device and
759 set tpchanger to chg-manual. To send tape mount prompts someplace other than
760 the terminal, which is necessary if AMANDA is run from a cron job, see the
761 request shell function comments in changer-src/chg-manual.sh.in.
762 Another common tape changer is chg-multi. This script can drive stackers that
763 advance to the next tape when the drive is unloaded or it can use multiple tape
764 drives on the tape sever machine to emulate a changer. The chg-multi script has
765 a configuration file and a state file. Put the path to the configuration file
766 in the amanda.conf changerfile parameter. There is a sample in example/chg-
767 multi.conf. It has the following keyword/value pairs separated by whitespace:
771 Number of the first slot in the device.
774 Number of the last slot in the device.
777 Set to 1 if the device is gravity fed and cannot go backwards, otherwise
781 Set to 1 if the tape needs to be ejected to advance to a new tape,
785 Set to 1 if sending multiple ejects causes the changer to advance through
786 the tapes, otherwise set to 0. If set to 1, gravity must also be set to 1
787 because the script currently does not handle carousels that wrap back
788 around to the first tape after the last one. Also, needeject must be set
792 Set to a number of seconds of extra delay after ejecting a tape if it
793 takes a while before the next tape is ready.
796 Set to the path to a file chg-multi builds and maintains with the current
797 state of the changer.
800 Repeat as needed to define all the slots and corresponding tape devices.
801 The first field after slot is the slot number. The next field is the no-
802 rewind tape device name. For changers that have a single tape device,
803 repeat the device name for each slot. To emulate a changer by using
804 multiple tape devices, list a different no-rewind tape device for each
807 chg-multi may also be used as a framework to write a new changer. Look for XXX
808 comments in the script and insert calls to commands appropriate for the device.
809 Make any source changes to the changer-src/chg-multi.sh.in file. That file is
810 processed by ./configure to generate chg-multi.sh, which turns into chg-multi
811 with make. If chg-multi.sh or chg-multi is altered, the changes will be lost
812 the next time AMANDA is rebuilt.
813 A third popular changer is chg-scsi. It can drive devices that have their own
814 SCSI interface. An operating system kernel module may need to be installed to
815 control such devices, like sst for Solaris, which is released with AMANDA, or
816 chio, available for various systems. As with chg-multi, set the amanda.conf
817 changerfile parameter to the changer configuration file path. There is a sample
818 in example/chg-scsi.conf. The initial section has parameters common to the
823 Set to the number of tape drives connected to this changer. The default
827 Set to 1 if tape drives need an explicit eject command before advancing
828 to the next tape, otherwise set to 0.
831 Set to the number of seconds to wait for a tape drive to become ready.
834 Set to the device path of the changer. This may be set in the amanda.conf
835 file instead of here if preferred. Following the common parameters is a
836 section for each tape device:
839 Set to the configuration number, starting with 0.
842 Set to the tape drive number, usually the same as the configuration
846 Set to the no-rewind device name of the tape drive.
849 Set to the number of the first slot served by this drive.
852 Set to the number of the last slot served by this drive.
855 Set to the path to a file chg-scsi will build and maintain with the
856 current state of this drive.
858 Test any changer setup with the amtape command. Make sure it can load a
859 specific tape with the slot NNN suboption, eject the current tape with eject
860 and advance to the next slot with slot next.
861 Tapes must be pre-labeled with amlabel so AMANDA can verify the tape is one it
862 should use. Run amlabel as the AMANDA user, not root. For instance:
865 # su amanda -c "amlabel Daily Daily-123 slot 123"
870 Configure Backup Clients
872 After tapes are labeled, pick the first client, often the tape server host
873 itself, and the filesystems or directories to back up. For each area to back
874 up, choose either the vendor dump program or GNU-tar. Vendor dump programs tend
875 to be more efficient and do not disturb files being dumped, but are usually not
876 portable between different operating systems. GNU-tar is portable and has some
877 additional features, like the ability to exclude patterns of files, but alters
878 the last access time for every file backed up and may not be as efficient. GNU-
879 tar may also deal with active filesystems better than vendor dump programs, and
880 is able to handle very large filesystems by breaking them up by subdirectories.
881 Choose the type of compression for each area, if any. Consider turning off
882 compression of critical areas needed to bring a machine back from the dead in
883 case the decompression program is not available. Client compression spreads the
884 load to multiple machines and reduces network traffic, but may not be
885 appropriate for slow or busy clients. Server compression increases the load on
886 the tape server machine, possibly by several times since multiple dumps are
887 done at once. For either, if GNU GNU-zip is used, compression may be set to
888 fast for faster but less aggressive compression or best for slower but more
889 aggressive compression. Set compression to none to disable software compression
890 or use hardware compression.
891 Pick or alter an existing dumptype that matches the desired options, or create
892 a new one. Each dumptype should reference the global dumptype. It is used to
893 set options for all other dumptypes. For instance, to use the indexing
894 facility, enable it in the global dumptype and all other dumptypes will inherit
896 The indexing facility generates a compressed catalogue of each dump image.
897 These are useful for finding lost files and are the basis of the amrecover
898 program. Long dump cycles or areas with many or very active files can cause the
899 catalogues to use a lot of disk space. AMANDA automatically removes catalogues
900 for images that are no longer on tape.
901 Create a file named disklist in the same directory as amanda.conf and either
902 copy the file from example/disklist or start a new one. Make sure it is
903 readable by the AMANDA user. Each line in disklist defines an area to be backed
904 up. The first field is the client host name (fully qualified names are
905 recommended), the second is the area to be backed up on the client and the
906 third is the dumptype. The area may be entered as a disk name, (sd0a), a device
907 name, (/dev/rsd0)a, or a logical name, (/usr). Logical names make it easier to
908 remember what is being backed up and to deal with disk reconfiguration.
909 To set up a Windows client, set the host name to the name of the Unix machine
910 running SAMBA and the area to the Windows share name, such as //some-pc/C$.
911 Note that Unix-style forward slashes are used instead of Windows-style backward
913 Enable AMANDA access to the client from the tape server host (even if the
914 client is the tape server host itself) by editing .amandahosts (or .rhosts,
915 depending on what was set with ./configure) in the AMANDA user home directory
916 on the client. Enter the fully qualified tape server host name and AMANDA user,
917 separated by a blank or tab. Make sure the file is owned by the AMANDA user and
918 does not allow access to anyone other than the owner (e.g. mode 0600 or 0400).
919 For Windows clients, put the share password in /etc/amandapass on the SAMBA
920 host. The first field is the Windows share name, the second is the clear text
921 password and the optional third field is the domain. Because this file contains
922 clear text passwords, it should be carefully protected, owned by the AMANDA
923 user and only allow user access. By default, AMANDA uses SAMBA user backup.
924 This can be changed with --with-samba-user to ./configure.
928 Test the setup with amcheck. As with all AMANDA commands, run it as the AMANDA
932 # su amanda -c "amcheck Daily"
936 Many errors reported by amcheck are described in docs/FAQ or the amcheck man
937 page. The most common error reported to the AMANDA mailing lists is selfcheck
938 request timed out, meaning amcheck was not able to talk to amandad on the
939 client. In addition to the ideas in docs/FAQ, here are some other things to
942 * Are the AMANDA services listed properly in /etc/services or a YP/NIS map? The
943 C program in Figure 4-1 uses the same system call as AMANDA to look up
946 Example 16.1. A C Program to Check the AMANDA Service Numbers
959 char *protocol = "tcp";
962 if ((pn = strrchr (*argv, '/')) == NULL) {
967 fprintf (stderr, "usage: %s service [protocol]\n", pn);
974 if ((s = getservbyname (service, protocol)) == NULL) {
975 fprintf (stderr, "%s: %s/%s lookup failed\n", pn,
979 printf ("%s/%s: %d\n", service, protocol,
980 (int) ntohs (s->s_port));
986 Run it on both the tape server and client and make sure the port numbers match:
989 $ cc check-service.c -lnsl -lsocket (Solaris)
1000 * Is there a line in the inetd configuration file on the client to start
1002 * Was inetd sent a HUP signal after the configuration file was changed?
1003 * Are there system log messages from inetd about amanda or amandad? For
1004 instance, inetd complains if it cannot look up the AMANDA services.
1005 * Is /tmp/amanda/amandad/debug being updated?
1006 * Is the access time on the amandad executable (ls -lu) being updated? If not,
1007 inetd is probably not able to run it, possibly because of an error in the
1008 inetd configuration file or a permission problem.
1009 * Run the amandad program by hand as the AMANDA user on the client. It should
1010 sit for about 30 seconds, then terminate. Enter the full path exactly as it
1011 was given to inetd, perhaps by using copy/paste.
1013 Do not proceed until amcheck is happy with the configuration.
1014 For initial testing, set the record option to no in the global dumptype, but
1015 remember to set it back to yes when AMANDA goes into normal production. This
1016 parameter controls whether the dump program on the client updates its own
1017 database, such as /etc/dumpdates for vendor dump.
1018 To forget about an individual test run, use amrmtape to remove references to
1019 the tapes used, then use amlabel to relabel them. To completely start over,
1020 remove the files or directories named in the infofile and indexdir parameters,
1021 the tapelist file named in the tapelist parameter, all amdump.* files in the
1022 configuration directory and all log.* files in the directory named by the
1023 logdir parameter. These files contain history information AMANDA needs between
1024 runs and also what is needed to find particular dump images for restores and
1025 should be protected when AMANDA goes into production.
1029 Once configured, you will need to setup the automated use of AMANDA.
1033 The amdump script controls a normal AMANDA backup run. However, it's common to
1034 do site-specific things as well with a wrapper shell script around amdump.
1035 amdump is meant to run unattended from cron. See the operating system
1036 documentation for how to set up a cron task. Be sure it runs as the AMANDA
1037 user, not root or the installer.
1038 The amdump script does the following:
1040 * If a file named hold is in the configuration directory, amdump pauses until
1041 it goes away. This may be created and removed by hand to temporarily delay
1042 AMANDA runs without having to change the cron task.
1043 * If it looks like another copy of amdump is running, or a previous run
1044 aborted, amdump logs an error and terminates. If an earlier run aborted,
1045 amcleanup must be run. An amcleanup step should be added to the tape server
1046 system boot sequence to handle crashes. No backups can be performed after an
1047 abort or crash until amcleanup is run.
1048 * The AMANDA planner program decides what areas to back up and at what level.
1049 It does this by connecting to each client and getting estimated sizes of a
1050 full dump, the same partial level that was done on the previous run and
1051 possibly the next partial level. All clients are done in parallel, but it can
1052 take a while to gather all this information.
1053 * The schedule is then passed to the driver program that controls actual
1054 dumping. It, in turn, starts up several dumper processes (based on the
1055 inparallel amanda.conf parameter) and a single taper process. The taper
1056 process splits into two parts, a reader and a writer, to keep streaming tape
1058 * driver commands dumpers to start backups, telling each its client, area,
1059 options such as compression and whether the result should go to the holding
1060 disk or direct to tape. Each dumper connects to amandad on the client and
1061 sends a request describing the dump program to run and options such as
1062 whether to do compression or indexing. The image comes back to the dumper who
1063 writes it, possibly via the server compression program, into the holding disk
1064 or directly to a taper connection. If enabled, dumper also collects catalogue
1065 information generated on the client and compresses it into the indexdir area.
1066 The driver also commands taper to write files from the holding disk to tape
1067 or to prepare to receive an image directly from a dumper.
1068 * After backups are done, amreport is run to generate the e-mail report. It
1069 also renames the log file for the run to a unique log.YYYYMMDD.N name.
1070 * Old amdump.NN debug log files are rolled so only enough to match the tape
1072 * The amtrmidx program is run to remove old catalogues if indexing has been
1075 There are several ways to determine which tapes AMANDA will need for a run. One
1076 is to look at the AMANDA e-mail report from the previous run. The tapes used
1077 during that run and those expected for the next run are listed. Another is to
1078 run amcheck during normal working hours. In addition to showing which tapes are
1079 needed, it makes sure things are set up properly so problems can be fixed
1080 before the real AMANDA run. A third is to use the tape suboption of amadmin.
1081 Without a tape changer, AMANDA expects the first tape to be mounted in the
1082 drive when it starts. Automated tape changers should be able to locate the
1083 tapes. The chg-manual changer prompts for the tapes.
1085 Read AMANDA's Reports
1087 An AMANDA report has several sections:
1092 These dumps were to tape Daily-009, Daily-010
1093 Tonight's dumps should go onto 2 tapes: Daily-011, Daily-012.
1097 This shows which tapes were used during the run and which tapes are needed
1101 FAILURE AND STRANGE DUMP SUMMARY:
1102 gurgi.cc.p /var lev 0 FAILED [Request to gurgi.cc.purdue.edu timed
1104 gurgi.cc.p / lev 0 FAILED [Request to gurgi.cc.purdue.edu timed out.]
1105 pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken pipe"]
1106 samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE
1107 mace.cc.pu /master lev 0 FAILED [dumps too big, but cannot incremental
1113 Problems found during the run are summarized in this section. In this example:
1115 * gurgi.cc.purdue.edu was down, so all its backups failed.
1116 * The /var/mail problem on pete.cc.purdue.edu and F$ problem on nt-
1117 test.cc.purdue.edu are detailed later.
1118 * The /master area on mace.cc.purdue.edu is new to AMANDA so a full dump is
1119 required, but it would not fit in the available tape space for this run.
1125 -------- -------- --------
1126 Dump Time (hrs:min) 5:03 3:23 0:33 (0:14
1128 Output Size (meg) 20434.4 17960.0 2474.4
1129 Original Size (meg) 20434.4 17960.0 2474.4
1130 Avg Compressed Size (%) -- -- --
1131 Tape Used (%) 137.4 120.0 17.4
1133 Filesystems Dumped 90 21 69 (1:
1135 Avg Dump Rate (k/s) 1036.5 1304.3 416.2
1136 Avg Tp Write Rate (k/s) 1477.6 1511.2 1271.9
1140 This summarizes the entire run. It took just over five hours, almost 3.5 hours
1141 writing full dumps and about half an hour for partials. It took 14 minutes to
1142 get started, mostly in the planner step getting the estimates, and taper was
1143 idle almost one hour waiting on dumps to come into the holding disk.
1144 In this example, hardware compression was used so Avg Compressed Size is not
1145 applicable and Output Size written to tape matches Original Size from the
1146 clients. About 137% of the length of the tape as defined in the tapetype was
1147 used (remember that two tapes were written), 120% for full dumps and 17% for
1148 partials. The Rate lines give the dump speed from client to tape server and
1149 tape writing speed, all in KBytes per second. The Filesystems Dumped line says
1150 90 areas were processed, 21 full dumps and 69 partials. Of the partials, 64
1151 were level 1, two were level 2 and three were level 3.
1154 FAILED AND STRANGE DUMP DETAILS:
1156 /-- pete.cc.pu /var/mail lev 0 FAILED ["data write: Broken
1158 sendbackup: start [pete.cc.purdue.edu:/var/mail level 0]
1159 sendbackup: info BACKUP=/usr/sbin/ufsdump
1160 sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
1161 sendbackup: info end
1162 | DUMP: Writing 32 Kilobyte records
1163 | DUMP: Date of this level 0 dump: Sat Jan 02 02:03:22 1999
1164 | DUMP: Date of last level 0 dump: the epoch
1165 | DUMP: Dumping /dev/md/rdsk/d5 (pete.cc.purdue.edu:/var/mail) to
1167 | DUMP: Mapping (Pass I) [regular files]
1168 | DUMP: Mapping (Pass II) [directories]
1169 | DUMP: Estimated 13057170 blocks (6375.57MB) on 0.09 tapes.
1170 | DUMP: Dumping (Pass III) [directories]
1171 | DUMP: Dumping (Pass IV) [regular files]
1172 | DUMP: 13.99% done, finished in 1:02
1173 | DUMP: 27.82% done, finished in 0:52
1174 | DUMP: 41.22% done, finished in 0:42
1176 /-- samba.cc.p //nt-test.cc.purdue.edu/F$ lev 1 STRANGE
1177 sendbackup: start [samba.cc.purdue.edu://nt-test/F$ level 1]
1178 sendbackup: info BACKUP=/usr/local/bin/smbclient
1179 sendbackup: info RECOVER_CMD=/usr/local/bin/smbclient -f... -
1180 sendbackup: info end
1181 ? Can't load /usr/local/samba-2.0.2/lib/smb.conf - run testparm to
1183 | session request to NT-TEST.CC.PURD failed
1185 | directory \top\Division\
1186 | 238 ( 2.7 kb/s) \top\Division\contract.txt
1187 | 19456 ( 169.6 kb/s) \top\Division\stuff.doc
1192 Failures and unexpected results are detailed here. The dump of /var/mail would
1193 not fit on the first tape so was aborted and rerun on the next tape, as
1194 described further in the next section.
1195 The dump of F$ on nt-test.cc.purdue.edu failed due to a problem with the SAMBA
1196 configuration file. It's marked STRANGE because the line with a question mark
1197 does not match any of the regular expressions built into AMANDA. When dumping
1198 Windows clients via SAMBA, it's normal to get errors about busy files, such as
1199 PAGEFILE.SYS and the registry. Other arrangements should be made to get these
1200 safely backed up, such as a periodic task on the PC that creates a copy that
1201 will not be busy at the time AMANDA runs.
1205 planner: Adding new disk j.cc.purdue.edu:/var.
1206 planner: Adding new disk mace.cc.purdue.edu:/master.
1207 planner: Last full dump of mace.cc.purdue.edu:/src on tape Daily-012
1210 planner: Full dump of loader.cc.purdue.edu:/var promoted from 2 days
1212 planner: Incremental of sage.cc.purdue.edu:/var bumped to level 2.
1213 taper: tape Daily-009 kb 19567680 fm 90 writing file: short write
1214 taper: retrying pete.cc.purdue.edu:/var/mail.0 on new tape: [writing
1217 driver: pete.cc.purdue.edu /var/mail 0 [dump to tape failed, will try
1219 taper: tape Daily-010 kb 6201216 fm 1 [OK]
1223 Informational notes about the run are listed here. The messages from planner
1226 * There are new disklist entries for j.cc.purdue.edu and mace.cc.purdue.edu.
1227 * Tape Daily-012 is due to be overwritten in two more runs and contains the
1228 most recent full dump of /src from mace.cc.purdue.edu, so the tape cycle may
1229 not be large enough.
1230 * The next scheduled full dump of /var on loader.cc.purdue.edu was moved up two
1231 days to improve the load balance.
1232 * The partial dump of /var on sage.cc.purdue.edu was bumped from level 1 to
1233 level 2 because the higher level was estimated to save enough space to make
1236 The rest of the notes say taper was not able to write as much data as it
1237 wanted, probably because of hitting end of tape. Up to that point, it had
1238 written 19567680 KBytes in 90 files on tape Daily-009. Another attempt at the
1239 full dump of /var/mail from pete.cc.purdue.edu was made on the next tape
1240 (Daily-010) and it succeeded, writing 6201216 KBytes in one file.
1247 HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/
1249 --------------------------- --------------------------------------- ---
1251 boiler.cc / 1 2624 2624 -- 0:13 200.1
1253 boiler.cc /home/boiler/a 1 192 192 -- 0:07 26.7
1255 boiler.cc /usr 1 992 992 -- 0:41 24.2
1257 boiler.cc /usr/local 1 288 288 -- 0:09 31.2
1259 boiler.cc /var 1 425 4256 -- 0:21 205.9
1261 egbert.cc / 1 41952 41952 -- 1:26 487.3
1263 egbert.cc /opt 1 224 224 -- 0:06 37.5
1265 egbert.cc -laris/install 1 64 64 -- 0:11 5.8
1267 gurgi.cc. / 0 FAILED ----------------------------------
1269 gurgi.cc. /var 0 FAILED ----------------------------------
1271 pete.cc.p / 1 13408 13408 -- 0:41 328.2
1273 pete.cc.p /opt 1 3936 3936 -- 1:04 61.2
1275 pete.cc.p /usr 1 1952 1952 -- 0:29 67.0
1277 pete.cc.p /var 1 300768 300768 -- 2:33 1963.8
1279 pete.cc.p /var/mail 0 6201184 6201184 -- 73:45 1401.3
1283 (brought to you by Amanda version 2.4.1p1)
1287 This section (which has been abbreviated) reports each area dumped showing
1288 client, area, backup level, sizes, time to dump and time to write to tape.
1289 Entries are in alphabetic order by client and then by area. This is not the
1290 same as the tape order. Tape order can be determined with the find or info
1291 suboption of the amadmin command, amtoc can generate a tape table of contents
1292 after a run, or amreport can generate a printed listing. By default, client
1293 names are truncated on the right, area names on the left, to keep the report
1294 width under 80 character. This typically leaves the unique portions of both.
1295 Two log files are created during an AMANDA run. One is named amdump.NN, where
1296 NN is a sequence number (1 is most recent, 2 is next most recent, etc), and is
1297 in the same directory as amanda.conf. The file contains detailed step by step
1298 information about the run and is used for statistics by amplot and amstatus,
1299 and for debugging. The other file is named log.YYYYMMDD.N where YYYYMMDD is the
1300 date of the AMANDA run and N is a sequence number in case more than one run is
1301 made on the same day (0 for the first run, 1 for the second, etc). This file is
1302 in the directory specified by the logdir amanda.conf parameter. It contains a
1303 summary of the run and is the basis for the e-mail report. In fact, amreport
1304 may be run by hand and given an old file to regenerate a report.
1305 Old amdump.NN files are removed by the amdump script. Old log.YYYYMMDD.N files
1306 are not automatically removed and should be cleared out periodically by hand.
1307 Keeping a full tape cycle is a good idea. If the tape cycle is 40 and AMANDA is
1308 run once a day, the following command would do the job:
1311 #find log.????????.* -mtime +40 -print | xargs rm
1315 If --with-pid-debug-files was used on ./configure, clients accumulate debug
1316 files in /tmp/amanda (or whatever --with-debug was set to) and should be
1317 cleaned out periodically. Without this option, client debug files have fixed
1318 names and are reused from run to run.
1320 Monitor Tape and Holding Disk Status
1322 While amdump is running, amstatus can track how far along it is. amstatus may
1323 also be used afterward to generate statistics on how many dumpers were used,
1324 what held things up and so on.
1325 When a tape error happens on the last tape allowed in a run (as set by
1326 runtapes), AMANDA continues to do backups into the holding disks. This is
1327 called degraded mode. By default, full dumps are not done and any that were
1328 scheduled have a partial done instead. A portion of the holding disk area may
1329 be allocated to do full dumps during degraded mode by reducing the value of the
1330 parameter reserve in amanda.conf below 100%.
1331 A tape server crash may also leave images in the holding disks. Run amflush, as
1332 the AMANDA user, to flush images in the holding disk to the next tape after
1333 correcting any problems. It goes through the same tape request mechanism as
1334 amdump. If more than one set of dumps are in the holding disk area, amflush
1335 prompts to choose one to write or to write them all. amflush generates an e-
1336 mail report just like amdump.
1337 Operating systems vary in how they report end of tape to programs. A no space
1338 or short write error probably means end of tape. For I/O error, look at the
1339 report to see how much was written. If it is close to the expected tape
1340 capacity, it probably means end of tape, otherwise it means a real tape error
1341 happened and the tape may need to be replaced the next time through the tape
1343 To swap out a partially bad tape, wait until it is about to be used again so
1344 any valid images can still be retrieved. Then swap the tapes, run amrmtape on
1345 the old tape and run amlabel on the replacement so it has a proper AMANDA
1347 If a tape is marked to not be reused with the no-reuse suboption of amadmin,
1348 such as one that has been removed or is failing, AMANDA may want a freshly
1349 labeled tape on the next run to get the number of tapes back up to the full
1351 If a tape goes completely bad, use amrmtape to make AMANDA forget about it. As
1352 with marking a tape no-reuse, this may reduce the number of tapes AMANDA has in
1353 use below the tape cycle and it may request a newly labeled tape on the next
1356 Adding Tapes at a Particular Position in the Cycle
1359 * Run amlabel on the new tapes.
1360 * Edit the tapelist file by hand and move the new tapes before the tape to be
1361 used just ahead of them. For instance, move Daily-100 before Daily-099.
1362 * Set the date stamp on the new tapes to the same as the previous tape, e.g.
1363 make them the same for Daily-099 and Daily-100.
1364 * Update the tapecycle amanda.conf parameter if new tapes are being added.
1366 These steps let AMANDA know about all tapes, including those that do not have
1367 data yet. When the cycle gets to the last old tape (Daily-099), the next tape
1368 used will be the first new one (Daily-100). A new option is planned for amlabel
1369 to do these steps automatically.
1371 Miscellanous Operational Notes
1373 Multiple amdump runs may be made in the same day, although catalogues are
1374 currently stored without a timestamp so amrecover may not show all restore
1375 possibilities. To redo a few areas that failed during the normal run, edit the
1376 disklist file by hand to comment out all the other entries, run amdump, then
1377 restore the disklist file.
1378 Use the force suboption of amadmin to schedule a full dump of an area on the
1379 next run. Run this as the AMANDA user, not root. AMANDA automatically detects
1380 new disklist entries and schedules an initial full dump. But for areas that go
1381 through a major change, such as an operating system upgrade or full restore,
1382 force AMANDA to do a full dump to get things back into sync.
1383 AMANDA does not automatically notice new client areas, so keep the disklist in
1384 sync by hand. AMANDA usually notices areas that are removed and reports an
1385 error as a reminder to remove the entry from the disklist. Use the delete
1386 suboption of amadmin (as the AMANDA user) to make AMANDA completely forget
1387 about an area, but wait until the information is not needed for restores. This
1388 does not remove the entry from the disklist file
\14 that must be done by hand.
1389 Non
\14AMANDA backups may still be done with AMANDA installed, but do not let the
1390 client dump program update its database. For vendor dump programs, this usually
1391 means not using the u flag, or saving and restoring /etc/dumpdates. For GNU-tar
1392 it means the --listed-incremental flag (if used) should not point to the same
1394 As with all backup systems, verify the resulting tapes, if not each one then at
1395 least periodically or by random sample. The amverify script does a reasonably
1396 good job of making sure tapes are readable and images are valid. For GNU-tar
1397 images, the test is very good. For vendor dump images of the same operating
1398 system type as the tape server machine, the test is OK but does not really
1399 check the whole image due to the limited way the catalogue option works. For
1400 vendor dump images from other operating systems, amverify can tell if the image
1401 is readable from tape but not whether it is valid.
1402 Tape drives are notorious for being able to read only what they wrote, so run
1403 amverify on another machine with a different drive, if possible, so an
1404 alternate is available if the primary drive fails. Make a copy of the AMANDA
1405 configuration directory on the other machine to be able to run amverify. This
1406 copy is also a good way to have a backup of the AMANDA configuration and
1407 database in case the tape server machine needs to be recovered.
1409 Advanced AMANDA Configuration
1411 Once you have AMANDA running for a while, you may choose to do some additional
1412 advanced configuration.
1414 Adjust the Backup Cycle
1416 Several dumptype parameters control the backup level AMANDA picks for a run:
1420 Maximum days between full dumps.
1423 Never schedule (or run) a full dump.
1426 Only schedule non-full dumps.
1428 Note that dumpcycle is both a general amanda.conf parameter and a specific
1429 dumptype parameter. The value in a specific dumptype takes precedence. To
1430 handle areas that change significantly between each run and should get a full
1431 dump each time (such as the mail spool on a busy e-mail server or a database
1432 area), create a dumptype based on another dumptype with attributes changed as
1433 desired (client dump program, compression, etc) and set dumpcycle in the new
1446 To run full dumps by hand outside of AMANDA (perhaps they are too large for the
1447 normal tape capacity, or need special processing), create a new dumptype and
1448 set strategy to incronly:
1451 define full-too-big {
1458 Tell AMANDA when a full dump of the area has been done with the force suboption
1459 of amadmin. Take care to do full dumps often enough that the tape cycle does
1460 not wrap around and overwrite the last good non-full backups.
1461 To never do full dumps (such as an area easily regenerated from vendor media),
1462 create a new dumptype and set strategy to nofull:
1472 Only level 1 backups of such areas are done, so wrapping around the tape cycle
1474 To do periodic archival full dumps, create a new AMANDA configuration with its
1475 own set of tapes but the same disklist as the normal configuration (e.g.
1476 symlink them together). Copy amanda.conf, setting all dumpcycle values to 0 and
1477 record to no, e.g. in the global dumptype. If a changer is used, set runtapes
1478 very high so tape capacity is not a planning restriction. Disable the normal
1479 AMANDA run, or set the hold file as described in "Operating AMANDA", so AMANDA
1480 does not try to process the same client from two configurations at the same
1485 AMANDA starts several dumper processes and keeps as many as possible running at
1486 once. The following options control their activity:
1490 Total number of dumpers.
1493 Maximum dumpers for a single client.
1495 The default maxdumps is one, meaning only one dumper is assigned to a client at
1496 a time. If a client can support the load, increase maxdumps so more than one
1497 dump on that client is running at once. Note that maxdumps is both a general
1498 amanda.conf parameter and a specific dumptype parameter. The value in a
1499 specific dumptype takes precedence.
1500 Field four of the disklist file is a "spindle number". Areas with the same non-
1501 negative spindle number are not backed up at the same time if maxdumps is
1502 greater than one. This prevents thrashing on an individual physical disk. Set
1503 spindle number to -1 (which is the default) for independent areas that can be
1504 done in conjunction with any other area, such as a whole physical disk. If the
1505 tape server has multiple network connections, an amanda.conf interface section
1506 may be set up for each one and clients allocated to a particular interface with
1507 field five of the disklist. Individual interfaces take precedence over the
1508 general netusage bandwidth limit and follow the same guidelines described above
1509 in "Configuring AMANDA": the limit is imposed when deciding whether to start a
1510 dump, but once a dump starts, AMANDA lets underlying network components do any
1512 Individual AMANDA interface definitions do not control which physical
1513 connection is used. That is left up to the operating system network software.
1514 While it's common to give an AMANDA interface definition the same name as a
1515 physical connection, e.g. le0, it might be better to use logical names such as
1516 back-door-atm to avoid confusion.
1517 The starttime dumptype parameter delays a backup some amount of time after
1518 AMANDA is started. The value is entered as HHMM, so 230, for instance, would
1519 wait 2.5 hours. This may be used to delay backups of some areas until they are
1522 Monitor for Possible Improvements
1524 amstatus may be used to get a summary of dumper activity:
1527 # su amanda -c "amstatus Daily --file amdump.1 --summary"
1529 dumper0 busy : 5:52:01 ( 98.03%)
1530 dumper1 busy : 0:23:09 ( 6.45%)
1531 dumper2 busy : 0:13:27 ( 3.75%)
1532 dumper3 busy : 0:16:13 ( 4.52%)
1533 dumper4 busy : 0:06:40 ( 1.86%)
1534 dumper5 busy : 0:03:39 ( 1.02%)
1535 taper busy : 3:54:20 ( 65.26%)
1536 0 dumpers busy : 0:03:21 ( 0.93%) file-too-large: 0:03:21
1538 1 dumper busy : 4:03:22 ( 67.78%) no-diskspace: 3:40:55
1540 file-too-large: 0:21:13 (
1542 no-bandwidth: 0:01:13 ( 0.50%)
1543 2 dumpers busy : 0:17:33 ( 4.89%) no-bandwidth: 0:17:33
1545 3 dumpers busy : 0:07:42 ( 2.14%) no-bandwidth: 0:07:42
1547 4 dumpers busy : 0:02:05 ( 0.58%) no-bandwidth: 0:02:05
1549 5 dumpers busy : 0:00:40 ( 0.19%) no-bandwidth: 0:00:40
1551 6 dumpers busy : 0:03:33 ( 0.99%) not-idle: 0:01:53
1560 * dumper 0 was busy almost all the time.
1561 * dumper 1 (and above) were not used very much.
1562 * taper was busy about 2/3 of the total run time.
1563 * All dumpers were idle less than 1% of the total runtime.
1564 * One dumper was busy 67.78% of the total run time and the reason two dumpers
1565 were not started when one was busy was not enough holding disk space (no-
1566 diskspace) 90.77% of that time, the next image to dump was too large to fit
1567 in the holding disk at all (file-too-large) 8.72% of that time and network
1568 bandwidth was exhausted (no-bandwidth) 0.50% of that time
1570 This configuration would benefit from additional holding disk space, which
1571 would allow more dumpers to run at once and probably keep taper busy more of
1573 Other common status indicators are:
1577 Everything is running that can be.
1580 All dumpers are busy and there are other dumps that could be started.
1583 The maximum number of dumpers for remaining clients are already running,
1584 or all spindles are already in use.
1587 All remaining dumps are delayed until a specific time of day.
1589 If the tape server machine has multiple tape drives, more than one AMANDA
1590 configuration may run at the same time. Clients and holding disks should be
1591 assigned to only one configuration, however.
1592 AMANDA waits a fixed amount of time for a client to respond with dump size
1593 estimates. The default is five minutes per area on the client. For instance, if
1594 a client has four areas to back up (entries in disklist), AMANDA waits at most
1595 20 minutes for the estimates. During dumping, AMANDA aborts a dump if the
1596 client stops sending data for 30 minutes. Various conditions, such as slow
1597 clients, which dump program is used and characteristics of the area, may cause
1598 timeouts. The values may be changed with the amanda.conf etimeout parameter for
1599 estimates and dtimeout for data. Positive etimeout values are multiplied by the
1600 number of areas. The absolute value of a negative number is used for the whole
1601 client regardless of the number of areas.
1605 GNU-tar can exclude items from the dump image based on file name patterns
1606 controlled by the dumptype exclude parameter. A single pattern may be put on
1607 the exclude line itself or multiple patterns may be put in a file on the
1608 client. The dumptype exclude line in that case includes a list keyword and the
1610 Exclusion entries are shell-style wildcard expressions except * matches through
1611 any number of / characters. If a matched item is a directory, it and all its
1612 contents are omitted. For instance:
1616 Omit the usr directory at the top level of the area and everything under
1620 Omit all items named core.
1623 Omit all items starting with core, e.g. core, core19970114, corespondent,
1624 or corexx/somefile (probably not a good idea).
1627 Omit all items starting with test and ending with .c, e.g. test.c,
1628 testing.c or testdir/pgm/main.c (probably not a good idea).
1631 Omit all items ending with .o.
1634 Omit all items within directories named OLD, including subdirectories and
1635 their contents, but dump the OLD directory entry itself.
1638 Restoring with AMANDA
1640 Remember that no one cares if you can back up ?only if you can restore.
1642 Configuring and Using amrecover
1644 One way to restore items with AMANDA is with amrecover on the client. Before
1645 amrecover can work, AMANDA must run with the dumptype index parameter set to
1646 yes and the amindexd and amidxtaped services must be installed and enabled to
1647 inetd, usually on the tape server machine (the default build sequence installs
1648 them). Also, add the client to .amandahosts (or .rhosts) for the AMANDA user on
1649 the server machine. Since amrecover must run as root on the client, the entry
1650 must list root as the remote user, not the AMANDA user. amrecover should not be
1651 made setuid-root because it would open up catalogues of the entire system to
1653 For this example, user jj has requested two files, both named molecule.dat, in
1654 subdirectories named work/sample-21 and work/sample-22 and said they want the
1655 versions last modified on the 13th of January. Become root on the client, cd to
1656 the area and start amrecover:
1663 AMRECOVER Version 2.4.1p1.
1664 Contacting server on amanda.cc.purdue.edu ...
1665 220 amanda AMANDA index server (2.4.1p1) ready.
1667 Setting restore date to today (1999-01-18)
1668 200 Working date set to 1999-01-18.
1669 200 Config set to Daily.
1670 200 Dump host set to pete.cc.purdue.edu.
1671 $CWD '/home/pete/u66/jj' is on disk '/home/pete/u66' mounted at '/home/
1673 200 Disk set to /home/pete/u66.
1678 At this point, a command line interface allows browsing the image catalogues.
1679 Move around with the cd command, see what is available with ls, change date
1680 with setdate, add files and directories to the extraction list with add and so
1681 on. The extract command starts actual recovery:
1684 amrecover> setdate ---14
1685 200 Working date set to 1999-01-14.
1686 amrecover> cd work/sample-21
1687 /home/pete/u66/jj/work/sample-21
1688 amrecover> add molecule.dat
1689 Added /jj/work/sample-21/molecule.dat
1690 amrecover> cd ../sample-22
1691 /home/pete/u66/jj/work/sample-22
1692 amrecover> add molecule.dat
1693 Added /jj/work/sample-22/molecule.dat
1695 Extracting files using tape drive /dev/rmt/0mn on host
1696 amanda.cc.purdue.edu.
1697 The following tapes are needed: Daily-034
1699 Restoring files into directory /home/pete/u66
1702 Load tape Daily-034 now
1704 Warning: ./jj: File exists
1705 Warning: ./work: File exists
1706 Warning: ./work/sample-21: File exists
1707 Warning: ./work/sample-22: File exists
1708 set owner/mode for '.'? [yn] n
1713 amrecover finds which tapes contain the images, prompts through mounting them
1714 in the proper order, searches the tape for the image, optionally decompresses
1715 it, brings it across the network to the client and pipes it into the
1716 appropriate restore program with the arguments needed to extract the requested
1717 items. amrecover does not know how to run every client restore program. See the
1718 amrecover manpage for current information. amrecover should not be used to do
1719 full filesystem recovery with vendor restore tools, but does work with GNU-tar.
1720 Vendor tools should be run with the r flag for a full recovery and amrecover is
1721 oriented toward extracting individual items with the x flag. Full filesystem
1722 recovery with vendor restore should be done with amrestore. amrecover (actually
1723 the amidxtaped server) does not know about tape changers, so mount the tapes by
1724 hand or use amtape if a changer is available.
1728 The amrestore command retrieves whole images from tape. First, find which tapes
1729 have the desired images. The find suboption of amadmin generates output like
1733 # su amanda -c "amadmin Daily find pete u66"
1736 date host disk lv tape or file file
1739 1999-01-12 pete.cc.purdue.edu /home/pete/u66 1 Daily-032 14
1741 1999-01-13 pete.cc.purdue.edu /home/pete/u66 1 Daily-033 26
1743 1999-01-14 pete.cc.purdue.edu /home/pete/u66 1 Daily-034 40
1745 1999-01-15 pete.cc.purdue.edu /home/pete/u66 1 Daily-000 34
1747 1999-01-16 pete.cc.purdue.edu /home/pete/u66 1 Daily-001 31
1749 1999-01-17 pete.cc.purdue.edu /home/pete/u66 0 Daily-002 50
1751 1999-01-18 pete.cc.purdue.edu /home/pete/u66 1 Daily-003 20
1756 The Scanning /amanda... message says amadmin looked in the holding disk (/
1757 amanda) for any images left there. It then lists all tapes or files in the
1758 holding disk that contain the requested area.
1759 The info suboption to amadmin shows tapes with the most recent images:
1762 # su amanda -c "amadmin Daily info pete u66"
1763 Current info for pete.cc.purdue.edu /home/pete/u66:
1764 Stats: dump rates (kps), Full: 652.0, 648.0, 631.0
1765 Incremental: 106.0, 258.0, 235.0
1766 compressed size, Full: -100.0%,-100.0%,-100.0%
1767 Incremental: -100.0%,-100.0%,-100.0%
1768 Dumps: lev datestmp tape file origK compK secs
1769 0 19990117 Daily-002 50 582239 582272 892
1770 1 19990118 Daily-003 20 3263 3296 31
1771 2 19981214 Daily-032 21 7039 7072 37
1775 Old information may appear, such as 19981214 (14-Dec-1998) in this example.
1776 While it's true this was the last level 2 dump of this area, it is of little
1777 interest because at least one full and level 1 dump have been done since then.
1778 The compressed size values here may be ignored because this particular
1779 configuration uses hardware compression so no software compression data are
1781 A third way to know what tape has an image is to generate a tape table of
1782 contents with amtoc after each AMANDA run:
1785 # partition lvl size[Kb] method
1786 0 Daily-002 - - 19990117
1787 1 boiler.cc.purdue.edu:/usr/local 1 31 normal
1788 2 egbert.cc.purdue.edu:/opt 1 127 normal
1789 3 boiler.cc.purdue.edu:/usr 1 95 normal
1791 50 pete.cc.purdue.edu:/home/pete/u66 0 582239 normal
1796 A printed report similar to the amtoc output may be automatically generated by
1797 amreport for each run with the lbl-templ tapetype parameter in amanda.conf
1798 using the example/3hole.ps template.
1799 The find and info suboptions to amadmin need the AMANDA log files and database.
1800 These are not usually large amounts of information and a copy should be pushed
1801 after each amdump run to an alternate machine that also has the AMANDA tape
1802 server software installed so they are available if the primary tape server
1803 machine dies. Tools like rdist (ftp://usc.edu/pub/rdist/) or rsync (ftp://
1804 samba.anu.edu.au/pub/rsync/) are useful.
1805 If AMANDA was built using --with-db=text (the default), the database is stored
1806 in a set of text files under the directory listed in the infofile amanda.conf
1807 parameter. Here is the file that matches the above info amadmin output:
1810 # cd /usr/local/etc/amanda/Daily/curinfo
1811 # cat pete.cc.purdue.edu/_home_pete_u66/info
1814 full-rate: 652.000000 648.000000 631.000000
1816 incr-rate: 106.000000 258.000000 235.000000
1818 stats: 0 582239 582272 892 916549924 50 Daily-002
1819 stats: 1 3263 3296 31 916637269 20 Daily-003
1820 stats: 2 7039 7072 37 913614357 21 Daily-032
1825 The first field of each stats line is the dump level. The last field is the VSN
1826 and the field just before it is the tape file number. The field with the large
1827 number just before that is a Unix epoch time value, which may be converted to
1828 text with this Perl script:
1832 #!/usr/local/bin/perl
1838 if (m/[a-fA-FxX]/) {
1839 unless (m/^0[xX]/) {
1847 $ epoch.pl 916549924
1848 Sun Jan 17 0:12:04 US/East-Indiana 1999
1852 Prepositioning the tape to the image with mt fsf may significantly reduce the
1853 time needed to do a restore. Some media contain an index for very fast file
1854 searching compared to the one file at a time scanning done by amrestore. Each
1855 tape location method listed above also shows the tape file. Use that number
1856 with mt fsf after a rewind to position to a particular image.
1857 amrestore takes client, area and date stamp patterns as optional arguments to
1858 search for matching images. Each argument is a grep-style regular expression,
1859 so multiple images may match. This also means an image may need a specific
1860 pattern. For instance:
1863 # amrestore $TAPE pete /
1867 finds not just the root area for the pete client, but images for any client
1868 with pete someplace in the hostname and a slash anywhere in the area name.
1869 Assuming only one client matches pete, the following gets just the root area:
1872 # amrestore $TAPE pete '^/$'
1876 The up arrow (caret) at the beginning says the pattern must start with this
1877 string. The dollar sign at the end says it must end there. The quote marks
1878 around the pattern protect the special characters from shell expansion.
1879 Without flags, amrestore finds every matching image, uncompresses it if needed
1880 and creates a disk file in the current working directory with a name made up of
1881 the client, area and dump level. These images may be used directly by the
1882 client restore program.
1883 amrestore may be used to generate a tape table of contents by giving it a host
1884 pattern that cannot match:
1888 # amrestore $TAPE no.such.host
1892 As it searches in vain for no.such.host it reports images that are skipped:
1895 amrestore: 0: skipping start of tape: date 19990117 label Daily-002
1896 amrestore: 1: skipping boiler.cc.purdue.edu._.19990117.1
1897 amrestore: 2: skipping egbert.cc.purdue.edu._opt.19990117.1
1898 amrestore: 3: skipping boiler.cc.purdue.edu._.19990117.1
1903 For large images, the p flag writes the first match to standard output, which
1904 may then be piped into the client restore program. This flag is also useful for
1905 moving an image across the network. For instance, here is one way to restore a
1906 file directly from the tape server (amanda.cc.purdue.edu) while logged in to
1910 # rsh -n amanda.cc.purdue.edu amrestore -p $TAPE pete
1911 ?'^/$? ' \ | gtar xf - ./the-file
1915 Tell vendor restore programs to use a small blocking factor to handle the
1916 arbitrary size chunks of data available through a pipeline:
1919 # rsh -n amanda.cc.purdue.edu amrestore -p $TAPE pete u66 \ |
1920 ufsrestore -ivbf 2 -
1925 Restoring Without AMANDA
1927 The AMANDA tape format is deliberately simple and restoring data can be done
1928 without any AMANDA tools if necessary. The first tape file is a volume label
1929 with the tape VSN and date it was written. It is not in ANSI VOL1 format, but
1930 is plain text. Each file after that contains one image using 32 KByte blocks.
1931 The first block is an AMANDA header with client, area and options used to
1932 create the image. As with the volume label, the header is not in ANSI format,
1933 but is plain text. The image follows, starting at the next tape block, until
1935 To retrieve an image with standard Unix utilities if amrestore is not
1936 available, position the tape to the image, then use dd to read it:
1941 # dd if=$TAPE bs=32k skip=1 of=dump_image
1945 The skip=1 option tells dd to skip over the AMANDA file header. Without the of=
1946 option, dd writes the image to standard output, which can be piped to the
1947 decompression program, if needed, and then to the client restore program.
1948 Since the image header is text, it may be viewed with:
1953 # dd if=$TAPE bs=32k count=1
1957 In addition to describing the image, it contains text showing the commands
1958 needed to do a restore. Here's a typical entry for the root filesystem on
1959 pete.cc.purdue.edu. It is a level 1 dump done without compression using the
1960 vendor ufsdump program:
1964 AMANDA: FILE 19981206 pete.cc.purdue.edu / lev 1
1965 comp N program /usr/sbin/ufsdump
1970 To restore, position the tape at start of file and run:
1973 # dd if=$TAPE bs=32k skip=1 | /usr/sbin/ufsrestore -f... -
1977 As with any backup system, test these procedures while in normal production so
1978 the principles and techniques are familiar when disaster strikes.
1979 -------------------------------------------------------------------------------
1982 Part IV. Various Information Home Chapter 17. AMANDA FAQ