Introduction to AF's Backup system
Intro

This file gives a short introduction into AF's backup system, it's architecture (wow !), the ideas behind it and how it can be used to serve the individual needs.

Client-Server

Yes, it's a client-server system. The server is a machine, that has access to some kind of storage media, usually a tape drive. This server side knows, how to handle this device, how many cartridges are in use and what to do, when a cartridge gets full or other special cases occur. What the serverside does not know is anything, that has to do with directory structures, files, attributes of the stored files or even their names. This is all handled on the client side. The server only knows data streams. The client demands from the server the functionality to pass him e.g. the next bunch of data from the tape, to write a packet to tape or to put in a certain cartridge and the server performs the actions (hopefully) as he can. The client knows, how to pack and unpack the files and directories and on which cartridges and files they are written and can be found. For this purpose he maintains file lists containing the names of all stored filesystem entries in a local directory. These filelists are not saved to the backup if not explicitely configured. Compression is done on the client side to reduce network traffic and to get more safety. If the packed stream would be compressed, a single wrong bit in the stream would make the whole rest of the backup useless. Thus the files are compressed individually on the client side.

Server ...

Client ...

How to use it

Here a typical case is described. Individual needs can be satisfied reading the rest of the documentation.

We assume, you have a DAT-cartridge handler with 12 tapes connected to some machine without the possibility to set a cartridge directly via commandline interface. So the first thing to do is set the robot to sequential mode. It is no bad idea to make this machine "fetch" the backup from the clients using a small script, that is started via crond. Thus the first step is to setup this backup server. Unpack the distribution, run the Install script and select installation option number 1 for installing and configuring the server side. The last question to be answered is, whether to run the serverside configuration program. Answer with yes, cause we should do this now. The most entries can be accepted as they are by default. Which device should be used, you must know yourself, you have for sure already done some archiving with tar to the connected streamer. The blocksize can be looked up usually in the man-pages of rmt or tar. Set the parameter "CartridgeHandler" to 1 and the number of cartridges to 12. Cause you must use the sequential mode of the robot, clear the "SetCartridgeCommand", if not already done entering the parameter number and a single space for the value. Set the "ChangeCartridgeCommand" to a command, that ejects a tape from the drive (usually mt -f %d rewoffl - the %d stands for the configured devicename, just for convenience, that it needs not to be typed in several times). The UserToInform-parameter should be set to some administrator or group of administrators, that should receive important informations. The rest of the para- meters is quite self-explanatory. Use the online-help, the CONFIG and the HOWTO.FAQ.DO-DONT, if you don't know, what they mean. Especially the CONFIG should give valuable hints. Finish the server configuration entering "ok". Now make the robot to have cartridge number 1 present inside the streamer. If you do not want to do this or can't convince the device to do, what you desire, run the following command: /the/path/to/server/bin/cartis where should be the integer number specifying the cartridge actually present in the drive.

Now install the client side on each client, that should do backups to the server. Again, unpack the distribution and run the Install script, choosing the installation option number 3 for client with remote start possibility. Again, all defaults should be ok, so the last question, whether to run the clientside configuration program can be confirmed. Reasonable defaults are present for each parameter. What you have to configure in any case are the files and directories, that are to be stored. Furthermore, the startup information program should be configured to a reasonable command (see above under "Minimum restore information" for details). If you are upgrading to a newer version and some of the parameters are not set, see the client.config (or server.config, respec- tively) of the actual distribution for defaults, that i consider sufficient for normal cases. This also might give you better ideas, what the parameters are good for.

Finally write small scripts starting the backup one after the other on the clients (the server may off course also be a client). An example script is provided in the HOWTO.FAQ.DO-DONT under 2, just replace the list of hosts in the shell-variable BACKUPCLIENTS. Now add entries to root's crontab-file. Entering crontab -l > my_crontab as root writes the actual crontab to the file my_crontab. To run e.g. a full backup each friday evening and incremental backups each evening from monday to thursday (all at 8 pm), add these two lines:

0 20 * * 5 /usr/backup/client/bin/full_backup_cycle 0 20 * * 1-4 /usr/backup/client/bin/incr_backup_cycle

assumed the named programs are the scripts you wrote according to the above description. Then run the command crontab my_crontab to install the modified crontab file.

That's it. Maybe, you want to start the first full backup manually to see, whether everything is correctly installed and working. In this case just start the script yourself and watch, what happens. Especially watch the client- and serverside logfiles in /path/to/client/var/backup.log and /path/to/server/var/backup.log. If something goes wrong, also the clientside command /path/to/client/bin/print_errors tells more details.


If this introduction together with the rest of the documentation is not sufficient, please let me know, but PLEASE give me instructive hints, what you are missing or what should be clarified. Albert Fluegel Aug 23 2000