Software architecture: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
Line 1: Line 1:


== Protocols ==
== Backup process ==


[[Image:AmandaSWArchitecture.png]]
[[Image:AmandaSWArchitecture.png]]

Revision as of 13:38, 10 April 2006

Backup process

Amand Server-amandad(client) protocol

XXX - still to be done

Planner-Driver protocol

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>

For incremental dumps: <host> <disk> <pri> <lev> <size>

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)

Driver-Dumper protocol

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-Taper protocol

Taper(read)-Taper(write) protocol

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 --->