AF's backup system ------------------ This is a client-server backup system offering several workstations a centralized backup to specialized backup servers. The backup on the clients can be started auto- matically using cron-jobs on the clients, but the more intelligent solution would be to start them remotely from a central administrative host. To be independent of tricks like rsh, rcp and so on, that are in fact security holes, this remote start option is internally realized. This is done because normally the backup has to be run with root authorization, otherwise files that are read protected by users would not be saved. Any streaming device can be used for writing the data. The tape device must be able to is to distinguish between unique files on tape so it can be positioned directly. Autochangers can be used, if an appropriate auxiliary program, such as mtx or stctl, is available and working. Writing backups is normally done sequentially, the next file writing to tape at the end of the previous write no matter where you have restored from in the meantime. A special utility is supplied to allow the administrator to change the next writing position, but this over-ride should be performed only in emergency cases (See: PROGRAMS, "cartis"). Another way to be more flexible here is to configure variable append mode. A more thorough introduction can be found in the file INTRO, all changes in comparison with earlier releases are listed in the file Changes. afbackup has been tested on Linux, AIX, IRIX, FreeBSD, Digital Unix (OSF1), Solaris and HP-UX. The clientside has also been tested on SunOS and OpenBSD. Using Solaris < 2.6 as server is discouraged. DISCLAIMER ---------- These programs come without warranty. Everybody using this software does so on his or her very own risk. The C- code has nonetheless been running over a year without problems and should have no bugs - at least if there are, they didn't hurt any backup or restore. The installation and configuration scripts have been added recently and might have bugs (but some testing has been done of course). PLEASE ------ Can someone (-: PLEASE :-) do me a favour and: - tell me, if she or he finds unusual, strange or simply wrong English in my texts. (This is a permanent request due to ongoing development of this software and thus the documentation) FEATURES -------- - Client-/Server-System - Authentication of the client is performed before it can take over control (see INSTALL) -> security - Several servers for one client can be configured for each client, actual server is chosen by availability - Multi stream server, several clients can store to one server at the same time - Remote start option -> centralized administration - Access restriction for the streamer device -> security - Client-side per-file processing -> reliability. If the files and directories were first packed and then processed, by the server a single faulty bit in the processed stream would make the rest of the backup unaccessible for restore - Builtin compression (requires libz) - Data stream is written to tape in configurable pieces -> fast finding of files during restore - Tape position logging for each file -> fast finding of files during restore - Tape capacity is fully used - Flexible tape handling and configurable append mode - Full / incremental backups and verify - Raw partitions can be saved - Ordinary users can run the restore for their own files and directories, but only for these - Emergency recovery on different catastrophy levels - Command output saving feature: useful e.g for databases - Cartridge locations database maintained - Support for media changers - Client access to cartridge sets can be restricted WHAT YOU NEED ------------- GNU make. Others may not work, but all should (thanks to autoconfig). Using gcc is recommended. A streaming device. This can be either a cartridge handling system or a simple drive. In the latter case you might want to maintain several cartridges nonetheless. Just buy them and write numbers to them starting with 1. The backup server will supply you with email when a tape must be put in and which it should be. The number of cartridges is configurable. E.g. a compression program on the client side, if you want to use the processing feature and no builtin compression, which is not mandatory. Some space for the logfiles. All the names of the saved files and directories are written to log files, which could grow to a notable size if a lot of files are saved. For media changer support an appropriate driver command is necessary, e.g. mtx or stctl. They can be obtained from the same place, where afbackup had been downloaded. INSTALLATION ------------ See: INSTALL UPGRADE ------- See: UPGRADE Updates can be obtained from the following places: ftp://ftp.zn-gmbh.com/pub/linux ftp://ftp.sbs.de/pub/tools/afbackup ftp://ftp.vic.com/af ftp://www.man.torun.pl/pub/backup/afbackup ftp://ftp.iphil.net:/pub/mirror/afbackup CONFIGURATION ------------- See: CONFIG, INTRO and HOWTO.FAQ.DO-DONT BEFORE YOU START ---------------- ... Your first backup! Put your tape cartridge number 1 into the drive or make your cartridge handling system do so. If you don't want this or can't persuade your cartridge handler to do so, find out the number of the cartridge which is actually inside the drive. Then enter the following commands on the backup server (the host, the drive is connected to) replacing with the real cartridge number: $BASEDIR/server/bin/cartis $BASEDIR/server/bin/cartis -i 1 The first command tells the server the number of the cartridge, that actually is in the drive. The second one says: Write the next backup to the named cartridge, file 1 (the data stream is written in pieces==files to tape). See: PROGRAMS. $BASEDIR always stands for your chosen installation directory, corresponding to the particular tape device. WHAT CAN BE STARTED: PROGRAMS ----------------------------- See: PROGRAMS LIMITATIONS AND KNOWN BUGS -------------------------- - Directories should be traversed in parallel, when on different filesystems - A real index should be maintained, not only the probably compressed filelist, preferred implementation design: a special index server not bound to the client or server host - It should be possible, that several devices share a pool of tapes like in most jukeboxes - There are too many warnings written to the logs, that can be safely ignored - There is a strange problem with the multi-stream server on Digital Unix and probably others, that is not understood yet. There the multi-stream server should be started to run as daemon (see: FAQ Q37) No other bugs known. At release time there are never known bugs. Please report bugs and suggestions for new features to: af@muc.de If you have problems, please add the last lines of the file(s) .../client/var/backup.log and .../server/var/backup.log to your posting, if present. Please add everything, too, what you think might be important. If you want to be informed about important changes or bugfixes, send an email to af@muc.de with the subject line containing: subscribe backup-news TO DO ----- Reduce the limitations. Port the client side to other platforms. Enhance jukebox support THANKS TO --------- (in chronolocigal order) - The people at "Zentrum fuer Neuroinformatik" for being so kind letting me put this into the PD. - Rick Macdougall at Axess Communications for reviewing my bad English. (A lot of text has been added up to now, he had no chance to review it - so it's my fault, if there is a lot of nonsense) - Lars Koeller at the University of Bielefeld, Germany, for doing the FreeBSD-port and giving me some important hints. - Christian Meder at the University of Stuttgart, Germany, for bug reports, fixes, making the whole package autoconfig- -urable and Debian-ready, extracting the man-pages and a lot more - Ivan N. Kokshaysky at the Moscow State University for making afbackup libc-6 (ie. glibc) - ready - Katharina Hoffman at Infomedia GmbH for doing a lot of tests - GianPiero Puccioni (gip@ino.it) at "Istituto Nazionale di Ottica" in Firenze for doing a lot of testing and problem determination, furthermore contributing the mtx.c program for using DAT autochangers, all on HP-UX. - Tuomo Soini (tis@foobar.fi) for 'feature' fixing - Andreas Wehler at CAD/CAM Straessle GmbH in Düsseldorf/Germany for intensive testing and helpful suggestions - Scott C. Ostrander for proof-reading and correcting the documentation texts - Piotr Klaban in Torun, Poland for numerous hints, suggestions and bug fixes (sometimes i have the suspicion he knows my software better than me) - Jerome Lovy helping to track the truncated files problem down (to different behaviour or zlib-s) making zlib use more robust - Toivo Pedaste for several helpful hints - Many thanks for "Lele Gaifax" for implementing the I18N/L10N gettext stuff and translating some messages to Italian