--- /dev/null
+
+ Chapter 22. AMANDA Internals
+Prev Part V. Technical Background Next
+
+-------------------------------------------------------------------------------
+
+Chapter 22. 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)
+
+
+Note
+
+Refer to http://www.amanda.org/docs/internals.html for the current version of
+this document.
+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 --->
+-------------------------------------------------------------------------------
+
+Prev Up Next
+Chapter 21. AMANDA dumper API Home Chapter 23. AMANDA Event API
+
projects / debian / amanda / blobdiff