1deec2631f1eb0ba48931c68d1862031ab89946a
[debian/amanda] / docs / amanda.8.txt
1
2                                amanda
3 Prev  Chapter 35. The AMANDA Manual Pages.  Next
4
5 -------------------------------------------------------------------------------
6
7 Name
8
9 amanda \14 Advanced Maryland Automatic Network Disk Archiver
10
11 Synopsis
12
13 amadmin config command [options]
14 amcheck [options] config
15 amcheckdb config
16 amcleanup config
17 amdd [options]
18 amdump config
19 amflush [-f ] config
20 amgetconf [config] parameter
21 amlabel config label [ slot slot ]
22 ammt [options]
23 amoverview config [options]
24 amplot [options] amdump-files
25 amrecover [config] [options]
26 amreport [config] [options]
27 amrestore [options] tapedevice [ hostname [diskname]]
28 amrmtape [options] config label
29 amstatus config [options]
30 amtape config command [options]
31 amtapetype [options]
32 amtoc [options] logfile
33 amverify config
34 amverifyrun config
35
36 DESCRIPTION
37
38 AMANDA is the "Advanced Maryland Automatic Network Disk Archiver". This manual
39 page gives an overview of the AMANDA commands and configuration files for quick
40 reference.
41 Here are all the AMANDA commands. Each one has its own manual page. See them
42 for all the gory details.
43
44
45   amdump
46       Take care of automatic AMANDA backups. This is normally executed by cron
47       on a computer called the tape server host and requests backups of file
48       systems located on backup clients. Amdump backs up all disks in the
49       disklist file (discussed below) to tape or, if there is a problem, to a
50       special holding disk. After all backups are done, amdump sends mail
51       reporting failures and successes.
52
53   amflush
54       Flush backups from the holding disk to tape. Amflush is used after amdump
55       has reported it could not write backups to tape for some reason. When
56       this happens, backups stay in the holding disk. Run amflush after the
57       tape problem is corrected to write backups from the holding disk to tape.
58
59   amcleanup
60       Clean up after an interrupted amdump. This command is only needed if
61       amdump was unable to complete for some reason, usually because the tape
62       server host crashed while amdump was running.
63
64   amrecover
65       Provides an interactive interface to browse the AMANDA index files
66       (backup image catalogues) and select which tapes to recover files from.
67       It can also run amrestore and a restore program (e.g. tar) to actually
68       recover the files.
69
70   amrestore
71       Read an AMANDA tape, searching for requested backups. Amrestore is
72       suitable for everything from interactive restores of single files to a
73       full restore of all partitions on a failed disk.
74
75   amlabel
76       Write an AMANDA format label onto a tape. All AMANDA tapes must be
77       labeled with amlabel. Amdump and amflush will not write to an unlabeled
78       tape (see TAPE MANAGEMENT below).
79
80   amcheck
81       Verify the correct tape is mounted and all file systems on all backup
82       client systems are ready to be backed up. Often run by cron before amdump
83       to generate a mail warning that backups might fail unless corrective
84       action is taken.
85
86   amadmin
87       Take care of administrative tasks like finding out which tapes are needed
88       to restore a filesystem, forcing hosts to do full backups of selected
89       disks and looking at schedule balance information.
90
91   amtape
92       Take care of tape changer control operations like loading particular
93       tapes, ejecting tapes and scanning the tape storage slots.
94
95   amverify
96       Check AMANDA backup tapes for errors.
97
98   amrmtape
99       Delete a tape from the AMANDA databases.
100
101   amstatus
102       Report the status of a running or completed amdump.
103
104   amoverview
105       Display a chart of hosts and file systems backed up every run.
106
107   amplot
108       Generate utilization plots of AMANDA runs for performance tuning.
109
110   amreport
111       Generate an AMANDA summary E-mail report.
112
113   amtoc
114       Generate table of content files for AMANDA tapes.
115
116   amcheckdb
117       Verify every tape AMANDA knows about is consistent in the database.
118
119   amgetconf
120       Look up parameters in the AMANDA configuration file.
121
122   amtapetype
123       Generate a tapetype definition.
124
125
126 CONFIGURATION
127
128 There are three user-editable files that control the behavior of AMANDA.
129 The first is amanda.conf, the main configuration file. It contains parameters
130 to customize AMANDA for the site. Refer to the amanda.conf(5), manpage for
131 details on AMANDA configuration parameters.
132 Second is the disklist file, which lists hosts and disk partitions to back up.
133 Third is the tapelist file, which lists tapes that are currently active. These
134 files are described in more detail in the following sections.
135 All files are stored in individual configuration directories under /usr/local/
136 etc/amanda/. A site will often have more than one configuration. For example,
137 it might have a normal configuration for everyday backups and an archive
138 configuration for infrequent full archival backups. The configuration files
139 would be stored under directories /usr/local/etc/amanda/normal/ and /usr/local/
140 etc/amanda/archive/, respectively. Part of the job of an AMANDA administrator
141 is to create, populate and maintain these directories.
142 All log and database files generated by AMANDA go in corresponding directories
143 somewhere. The exact location is controlled by entries in amanda.conf. A
144 typical location would be under /var/adm/amanda. For the above example, the
145 files might go in /var/adm/amanda/normal/ and /var/adm/amanda/archive/.
146 As log files are no longer needed (no longer contain relevant information),
147 AMANDA cycles them out in various ways, depending on the type of file.
148 Detailed information about amdump runs are stored in files named amdump.NN
149 where NN is a sequence number, with 1 being the most recent file. Amdump
150 rotates these files each run, keeping roughly the last tapecycle (see below)
151 worth of them.
152 The file used by amreport to generate the mail summary is named log.YYYYMMDD.NN
153 where YYYYMMDD is the datestamp of the start of the amdump run and NN is a
154 sequence number started at 0. At the end of each amdump run, log files for runs
155 whose tapes have been reused are renamed into a subdirectory of the main log
156 directory (see the logdir parameter below) named oldlog. It is up to the AMANDA
157 administrator to remove them from this directory when desired.
158 Index (backup image catalogue) files older than the full dump matching the
159 oldest backup image for a given client and disk are removed by amdump at the
160 end of each run.
161
162 DISKLIST FILE
163
164 The disklist file determines which disks will be backed up by AMANDA. The file
165 usually contains one line per disk:
166
167   hostname diskname [diskdevice] dumptype [spindle [interface] ]
168
169 All pairs [ hostname diskname ] must be unique.
170 Lines starting with # are ignored, as are blank lines. The fields have the
171 following meanings:
172
173
174   hostname
175       The name of the host to be backed up. If diskdevice refers to a PC share,
176       this is the host AMANDA will run the Samba smbclient program on to back
177       up the share.
178
179   diskname
180       The name of the disk (a label). In most case, you set your diskname to
181       the diskdevice and you don't set the diskdevice. If you want multiple
182       entries with the same diskdevice, you must set a different diskname for
183       each entry. It's the diskname that you use on the commandline for any
184       AMANDA command. Look at the example/disklist file for example.
185
186   diskdevice
187       Default: same as diskname. The name of the disk device to be backed up.
188       It may be a full device name, a device name without the /dev/ prefix,
189       e.g. sd0a, or a mount point such as /usr.
190       It may also refer to a PC share by starting the name with two (forward)
191       slashes, e.g. //some-pc/home. In this case, the program option in the
192       associated dumptype must be entered as GNUTAR. It is the combination of
193       the double slash disk name and program GNUTAR in the dumptype that
194       triggers the use of Samba.
195
196   dumptype
197       Refers to a dumptype defined in the amanda.conf file. Dumptypes specify
198       backup related parameters, such as whether to compress the backups,
199       whether to record backup results in /etc/dumpdates, the disk's relative
200       priority, etc.
201
202   spindle
203       Default: -1. A number used to balance backup load on a host. AMANDA will
204       not run multiple backups at the same time on the same spindle, unless the
205       spindle number is -1, which means there is no spindle restriction.
206
207   interface
208       Default: local. The name of a network interface definition in the
209       amanda.conf file, used to balance network load.
210
211 Instead of naming a dumptype, it is possible to define one in-line, enclosing
212 dumptype options within curly braces, one per line, just like a dumptype
213 definition in amanda.conf. Since pre-existing dumptypes are valid option names,
214 this syntax may be used to customize dumptypes for particular disks.
215 A line break must follow the left curly bracket.
216 For instance, if a dumptype named normal is used for most disks, but use of the
217 holding disk needs to be disabled for the file system that holds it, this would
218 work instead of defining a new dumptype:
219
220   hostname diskname [ diskdevice ] {
221     normal
222     holdingdisk no
223   } [ spindle [ interface ] ]
224
225
226 TAPE MANAGEMENT
227
228 The tapelist file contains the list of tapes in active use. This file is
229 maintained entirely by AMANDA and should not be created or edited during normal
230 operation. It contains lines of the form:
231
232   YYYYMMDD label flags
233
234 Where YYYYMMDD is the date the tape was written, label is a label for the tape
235 as written by amlabel and flags tell AMANDA whether the tape may be reused, etc
236 (see the reuse options of amadmin).
237 Amdump and amflush will refuse to write to an unlabeled tape, or to a labeled
238 tape that is considered active. There must be more tapes in active rotation
239 (see the tapecycle option) than there are runs in the backup cycle (see the
240 dumpcycle option) to prevent overwriting a backup image that would be needed to
241 do a full recovery.
242
243 OUTPUT DRIVERS
244
245 The normal value for the tapedev parameter, or for what a tape changer returns,
246 is a full path name to a non-rewinding tape device, such as /dev/nst0 or /dev/
247 rmt/0mn or /dev/nst0.1 or whatever conventions the operating system uses.
248 AMANDA provides additional application level drivers that support non-
249 traditional tape-simulations or features. To access a specific output driver,
250 set tapedev (or configure your changer to return) a string of the form driver:
251 driver-info where driver is one of the supported drivers and driver-info is
252 optional additional information needed by the driver.
253 The supported drivers are:
254
255
256   tape
257       This is the default driver. The driver-info is the tape device name.
258       Entering
259
260         tapedev /dev/rmt/0mn
261
262       is really a short hand for
263
264         tapedev tape:/dev/rmt/0mn
265
266       .
267
268   null
269       This driver throws away anything written to it and returns EOF for any
270       reads except a special case is made for reading a label, in which case a
271       "fake" value is returned that AMANDA checks for and allows through
272       regardless of what you have set in labelstr. The driver-info field is not
273       used and may be left blank:
274
275         tapedev null:
276
277       The length value from the associated tapetype is used to limit the amount
278       of data written. When the limit is reached, the driver will simulate end
279       of tape.
280
281       Note
282
283       This driver should only be used for debugging and testing, and probably
284       only with the record option set to no.
285
286   rait
287       Redundant Array of Inexpensive (?) Tapes. Reads and writes tapes mounted
288       on multiple drives by spreading the data across N-1 drives and using the
289       last drive for a checksum. See docs/RAIT for more information.
290       The driver-info field describes the devices to use. Curly braces indicate
291       multiple replacements in the string. For instance:
292
293         tapedev rait:/dev/rmt/tps0d{4,5,6}n
294
295       would use the following devices:
296       /dev/rmt/tps0d4n /dev/rmt/tps0d5n /dev/rmt/tps0d6n
297
298
299
300   file
301       This driver emulates a tape device with a set of files in a directory.
302       The driver-info field must be the name of an existing directory. The
303       driver will test for a subdirectory of that named data and return offline
304       until it is present. When present, the driver uses two files in the data
305       subdirectory for each tape file. One contains the actual data. The other
306       contains record length information.
307       The driver uses a file named status in the file device directory to hold
308       driver status information, such as tape position. If not present, the
309       driver will create it as though the device is rewound.
310       The length value from the associated tapetype is used to limit the amount
311       of data written. When the limit is reached, the driver will simulate end
312       of tape.
313       One way to use this driver with a real device such as a CD-writer is to
314       create a directory for the file device and one or more other directories
315       for the actual data. Create a symlink named data in the file directory to
316       one of the data directories. Set the tapetype length to whatever the
317       medium will hold.
318       When AMANDA fills the file device, remove the symlink and (optionally)
319       create a new symlink to another data area. Use a CD writer software
320       package to burn the image from the first data area.
321       To read the CD, mount it and create the data symlink in the file device
322       directory.
323
324
325 AUTHORIZATION
326
327 AMANDA processes on the tape server host run as the dumpuser user listed in
328 amanda.conf. When they connect to a backup client, they do so with an AMANDA-
329 specific protocol. They do not, for instance, use rsh or ssh directly.
330 On the client side, the amandad daemon validates the connection using one of
331 several methods, depending on how it was compiled and on options it is passed:
332
333
334   .rhosts
335       Even though AMANDA does not use rsh, it can use .rhosts-style
336       authentication and a .rhosts file.
337
338   .amandahosts
339       This is essentially the same as .rhosts authentication except a different
340       file, with almost the same format, is used. This is the default mechanism
341       built into AMANDA.
342       The format of the .amandahosts file is:
343       hostname [ username ]
344       If username is ommitted, it defaults to the user running amandad, i.e.
345       the user listed in the inetd or xinetd configuration file.
346
347   Kerberos
348       AMANDA may use the Kerberos authentication system. Further information is
349       in the docs/KERBEROS file that comes with an AMANDA distribution.
350       For Samba access, AMANDA needs a file on the Samba server (which may or
351       may not also be the tape server) named /etc/amandapass with share names,
352       (clear text) passwords and (optional) domain names, in that order, one
353       per line, whitespace separated. By default, the user used to connect to
354       the PC is the same for all PC's and is compiled into AMANDA. It may be
355       changed on a host by host basis by listing it first in the password field
356       followed by a percent sign and then the password. For instance:
357
358           //some-pc/home normalpw
359           //another-pc/disk otheruser%otherpw
360
361       With clear text passwords, this file should obviously be tightly
362       protected. It only needs to be readable by the AMANDA-user on the Samba
363       server.
364       You can find further information in the docs/SAMBA file that comes with
365       an AMANDA distribution.
366
367
368 HOST & DISK EXPRESSION
369
370 All host and disk arguments to programs are special expressions. The command
371 applies to all disks that match your arguments. This section describes the
372 matcher.
373 The matcher matches by word, each word is a glob expression, words are
374 separated by the separator '.' for host and '/' for disk. You can anchor the
375 expression at left with a '^'. You can anchor the expression at right with a
376 '$'. The matcher is case insensitive for host but is case sensitive for disk. A
377 match succeeds if all words in your expression match contiguous words in the
378 host or disk.
379  ________________________________________________________
380 |._|word_separator_for_a_host____________________________|
381 |/_|word_separator_for_a_disk____________________________|
382 |^_|anchor_at_left_______________________________________|
383 |$_|anchor_at_right______________________________________|
384 |?_|match_exactly_one_character_except_the_separator_____|
385 |*_|match_zero_or_more_characters_except_the_separator___|
386 |**|match_zero_or_more_characters_including_the_separator|
387
388 Some examples:
389  ___________________________________________
390 |EXPRESSION|WILL_MATCH_______|WILL_NOT_MATCH|
391 |hosta_____|hosta____________|hostb_________|
392 |__________|hoSTA.dOMAIna.ORG|______________|
393 |__________|foo.hosta.org____|______________|
394 |host______|host_____________|hosta_________|
395 |host?_____|hosta____________|host__________|
396 |__________|hostb____________|______________|
397 |ho*na_____|hoina____________|ho.aina.org___|
398 |ho**na____|hoina____________|______________|
399 |__________|ho.aina.org______|______________|
400 |^hosta____|hosta____________|foo.hosta.org_|
401 |sda*______|/dev/sda1________|______________|
402 |__________|/dev/sda12_______|______________|
403 |/opt/_____|opt_(disk)_______|opt_(host)____|
404 |.opt._____|opt_(host)_______|opt_(disk)____|
405 |/_________|/________________|any_other_disk|
406 |/usr______|/usr_____________|______________|
407 |__________|/usr/opt_________|______________|
408 |/usr$_____|/usr_____________|/usr/opt______|
409
410
411 DATESTAMP EXPRESSION
412
413 A datestamp expression is a range expression where we only match the prefix.
414 Leading ^ is removed. Trailing $ forces an exact match.
415  _________________________________________________________________________
416 |20001212-14|match_all_dates_beginning_with_20001212,_20001213_or_20001214|
417 |20001212-4_|same_as_previous_____________________________________________|
418 |20001212-24|match_all_dates_between_20001212_and_20001224________________|
419 |2000121____|match_all_dates_that_start_with_2000121_(20001210-20001219)__|
420 |2__________|match_all_dates_that_start_with_2_(20000101-29991231)________|
421 |2000-10____|match_all_dates_between_20000101-20101231____________________|
422 |200010$____|match_only_200010____________________________________________|
423
424
425 AUTHOR
426
427 James da Silva, <jds@amanda.org> : Original text
428 Stefan G. Weichinger, <sgw@amanda.org>, maintainer of the AMANDA-documentation:
429 XML-conversion, major update
430
431 SEE ALSO
432
433 amadmin(8), amanda.conf(5), amcheck(8), amcheckdb(8), amcleanup(8), amdd(8),
434 amdump(8), amflush(8), amgetconf(8), amlabel(8), ammt(8), amoverview(8), amplot
435 (8), amrecover(8), amreport(8), amrestore(8), amrmtape(8), amstatus(8), amtape
436 (8), amtapetype(8), amtoc(8), amverify(8), amverifyrun(8)
437 -------------------------------------------------------------------------------
438
439 Prev      Up          Next
440 amadmin  Home  amanda.conf
441