1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Chapter 24. Amanda Internals
Prev Part V. Technical Background Next
-------------------------------------------------------------------------------
Chapter 24. Amanda Internals
George Scott
Original text<George.Scott@cc.monash.edu.au>
Stefan G. Weichinger
XML-conversion
AMANDA Core Team
<sgw@amanda.org>
Table of Contents
Protocols
server_and_amandad_on_client
planner_and_driver
driver_and_dumper
taper(read)_and_taper(write)
This is an attempt to document Amanda's internals. Please feel free to make
comments and suggest changes. Text for new sections gratefully accepted!
Protocols
Note
The following was an ASCII-illustration in the original docs, I managed to
transfer it at last. Maybe someone will convert this to the first image in the
Amanda-docs ;-) . sgw.
Client I Server +-planner-+
I | |
I | |
I | | ______
+-amandad-+ I | | (______)
| | I | | |amdump|
| | I | | all ::::>| |
| | I | | stderr | |
| | I | | | |
| | I | so | +------+
| | I +---------+
| | I :: ______
| | I \/ (______)
| | I +-driver--+ | log |
+---------+ I | si | all ::::>| |
I | | log | |
I | | | |
+-sendback+ I | | +------+
| | I | |
| | I ::::::::| |<::::::
| | I :: | | ::
| | I :: ::::>| |:::: ::
| | I :: :: | | :: ::
| | I :: :: +---------+ :: ::
| | I :: :: :: ::
| | I :: :: :: ::
| | I :: :: ______ :: ::
+---------+ I :: :: (______) :: ::
I :: :: | /tmp | :: ::
I \/ :: :>| | \/ ::
+-dump----+ I +-dumper--+ :: +------+ +-taper/r-+ +-taper/w-+
| | I | si so | :: | si so | | |
| | I | | :: ______ | | | |
| | I |mesgfd | :: (______) | | | |
| se|::::>|::::::::>|:: | hold | | | | |
| | I | errf| | disk | | p2c|:::>|p2c |
| | I | | | | | c2p|<:::|c2p |
____
| | I |datafd | ::>| |::: |fd | | | / \
| so|::::>|::::::::>|:: +------+ :>|::::::::>SHDMEM::::::::>|::
>|tape|
| | I | outfd| :: :: | | | tapefd| \ _ /
+---------+ I +---------+ :::::::::::: +---------+ +---------+
I
server and amandad on client
XXX - still to be done
planner and driver
planner interrogates all clients and generates a plan of which disks to backup
and what dump level to do them at. The plan is plain text with one line per
disk to be dumped. It is piped from planners stdout to drivers stdin. Plan
lines come in two flavours:
For total dumps: <host> <disk> <pri> <lev> <size> <time> <deg lev> <deg size>
<deg time>
For incremental dumps: <host> <disk> <pri> <lev> <size> <time>
Where: <host> Host name of client (from disklist file) <disk> Name of disk
(from disklist file) <pri> Priority of backup (pri from disklist and
amanda.conf + days overdue for total) <lev> Dump level for dump (0 for total,
1-9 for incremental) <size> Estimated size (in Kb after compression if
requested) <time> Estimated time for backup (in seconds) <deg lev> <lev> to use
if in degraded mode <deg size> <size> to use if in degraded mode <deg time>
<time> to use if in degraded mode
driver and dumper
dumper talks via two pipes connected to each dumper's stdin and stdout. The
commands and responses are plain text.
driver can ask dumper to do a dump to a file on the holding disk: FILE-DUMP
<handle> <filename> <host> <disk> <level> <dumpdate> <chunksize> <prog>
<options> or directly to taper: PORT-DUMP <handle> <port> <host> <disk> <level>
<dumpdate> <prog> <options> or exit at the end of the run: QUIT
If the dump finishes correctly dumper replies with: DONE <handle> [<message>]
If something goes wrong with the dump, dumper can request that the dump be
retried at a later time with: TRY-AGAIN <handle> [<message>] or, for fatal
errors, be abandoned with: FAILED <handle> [<message>]
If the holding disk runs out of space, dumper will give: NO-ROOM <handle> and
wait for driver to either fix the problem and say: CONTINUE or just say: ABORT
in which case dumper kills the dump and replies with: ABORT-FINISHED <handle>
If driver says something that dumper doesn't recognise it responds with: BAD-
COMMAND <message>
Where: <handle> Request ID <filename> Name of file (on holding disk) to write
dump <port> Port (of taper) to send dump directly <host> Hostname of client
<disk> Disk to backup <level> Dump level to do backup at <prog> Dump program to
use <options> Options to pass to sendbackup <message> Error or status message
*driver and taper
driver talks via two pipes connected to taper's stdin and stdout. The commands
and responses are plain text.
driver initialises taper with: START-TAPER <datestamp> to which taper replies
with: TAPER-OK or, for fatal errors, with: TAPER-ERROR [<message>]
driver can ask taper to to copy a file from the holding disk to tape: FILE-
WRITE <handle> <filename> <host> <disk> <level> or directly from a dumper:
PORT-WRITE <handle> <host> <disk> <level> or exit at the end of the run: QUIT
taper responds to the PORT-WRITE command with: PORT <port> which driver should
then hand on to dumper in a PORT-DUMP command.
taper responds to the QUIT command with: QUITING
If the copy to tape finishes correctly taper replies with: DONE <handle>
[<message>]
If something goes wrong with the tape, taper can request that the dump be
retried at a later time with: TRY-AGAIN <handle> [<message>] or, for fatal
errors, be abandoned with: TAPE-ERROR <handle> [<message>]
If driver says something that taper doesn't recognise it responds with: BAD-
COMMAND <message>
Where: <datestamp> Todays date as "yymmdd" <handle> Request ID <filename> Name
of file (on holding disk) to write dump <port> Port (of taper) to send dump
directly <host> Hostname of client <disk> Disk to backup <level> Dump level to
do backup at <message> Error or status message
taper(read) and taper(write)
There are two parts to taper: the file reader and the tape writer.
Communication between the two sides is via a bit of shared memory for data
transfer and two pipes (one in each direction) for synchronisation.
The shared memory area is made up of NBUFS (=20) buffers each of which contains
a status word and a BUFFER_SIZE (=32*1024) byte data buffer.
The sync pipes are used to transfer a simplistic command sequence:
reader writer ------ ------
Startup S<datestamp> ---> <--- S Start OK <--- E<messge> Error
Open tape O<datestamp><hostname><diskname><level> ---> <--- O Opening
Write buffer W<bufnum> ---> <--- R<bufnum> Buffer empty <--- E<message> Error
<--- T<message> Error, try again E ack e ---> Protocol error X ---> <--- x X
ack
Close tape C ---> <--- C<label><filenum><stats> Closing
Quit Q --->
Note
Refer to http://www.amanda.org/docs/internals.html for the current version of
this document.
-------------------------------------------------------------------------------
Prev Up Next
Chapter 23. Amanda dumper API Home Chapter 25. Amanda Event API
|
