Software architecture

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)

Jump to: navigation, search


Backup process

dia source file for editing above diagram

amdump(8) command starts the backup process. It is usually run from crontab. The amdump command performs backup for an Amanda configuration. The amdump(8) command starts the planner process on the Amanda server.

Planner sends a request to each client in the disklist file to estimate the size of the backups. The backup size estimate request is sent to the amandad(8) process running on the Amanda client. It then generates a plan, consisting of a list of hosts and DLE's and dumplevel for each. Included in the plan is also a "plan B", that driver can use in case not all fits on tape (e.g. because the tape is missing).

This plan is a series of text lines, which are printed on the stdout into the pipe which is connected to the stdin of driver.

Driver interprets the plan, and starts a taper and several dumpers. The number of dumpers started depends on the configuration parameters in amanda.conf(5) and the number of Amanda clients in the disklist. These dumper and taper programs each get their instructions from driver, and communicate the result to driver process too.

For example: Each dumper will start one backup and when finished tells driver of the good news. The driver will instruct taper to put that dump on tape, and instruct the dumper to start another dump.

amandad(8) is the Amanda client process that executes various requests from the Amanda server by forking a process and executing another command. The commands that are executed in the client are:

Returns the estimated backup size for each backup level requested for a DLE to the planner
Send backup data, indexes to the dumper
Amanda server and client program do not need to be the same version of have the same features.

In the amanda protocol, the server and client exchange a set of features, so that they can agree on a common set. When this was first implemented it needed to be compatible with previous versions too. So since then the server first sends a "noop" (No Operation) request to the client. A post 2.4.2 server will respond with an "ACK", and send a feature bitmask back. A pre-2.4.2 server will "ACK" without that feature bit mask (it did not exist at that time); the absence of the feature bitmask gives enough information so that the server can continue too. The implementors choose the "noop" request, because that could be handled by a pre-2.4.2 server too. A "feature-exch" request would be handled as an error by those old servers.

Performs client configuration checks. It is done as part of amcheck(8) comamnd.

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

Personal tools