faq

一套客户/服务器模式的备份系统代码,跨平台,支持linux,AIX, IRIX, FreeBSD, Digital Unix (OSF1), Solaris and HP-UX.

exit 0

# End of eject_check_10


Q7: Can ordinary users restore their own files and directories ?

A7: Yes, they can, but this feature must be enabled. The restore-
    utility must be installed executable for all users and setuid
    root. Also some more stuff must be readable. This all can be
    achieved entering as administrator root:

    rm -f $BASEDIR/client/bin/afrestore
    cp $BASEDIR/client/bin/full_backup $BASEDIR/client/bin/afrestore
    chmod 4755 $BASEDIR/client/bin/afrestore
    chmod 755 $BASEDIR/client/lib $BASEDIR/client/bin
    chmod 755 $BASEDIR/client/bin/__packpats
    chmod 644 $BASEDIR/client/lib/aftcllib.tcl

    Also the configuration file (wherever this resides) must be
    readable for the user who wants to restore stuff.
    Thus ordinary users can run this program. Built-in safety checks
    provide, that they can only restore or list their own files and
    directories. Changing the restore-directory using the option -C
    allows them only to restore to directories owned by themselves.


Q8: Why does afbackup not have a GUI ?

A8: My ideal imagination of a backup system is, that i do not have
    to care about it at all, once it is installed and configured
    properly. It should do it's job in the background, only noticing
    me, if something goes wrong. Thus i would not want any icons,
    clocks or meters pop up on my workspace plugging me up with
    unnecessary and unimportant stuff. The installation procedure
    is simple enough and would not get better having a graphical
    frontend. My opinion.
     BTW there is a GUI frontend for the restore utility. Don't
    use it, it's terrible.


Q9: What does the warning mean: "Filelist without user-ID information ..." ?

A9: You are running restore with the list-option as non-root and
    the filelists are of the pre-version-2.9-format. Thus they do
    not contain the user-ID of the owners of the files. The program
    does not know, whether it is permittable to show you the names
    of the files. For security reasons it is hardcoded not to show
    them. With the new format containing the user-IDs, you will see
    the matching names of the files owned by you.


Q10: The whole backup systems hangs in the middle of a backup, what's up ?

A10: This phenomenon has been reported only on Linux, Kernel Version
     2.0.30 and seems to be the result of a bug in this kernel. I
     never experienced this problem on my 2.0.29 Kernel or on other
     platforms.
      Rumors told me, that the 2.0.30 kicks out about every 10000th
     to 20000th Process, i.e. the process is started, appears in the
     process list, but does not do anything and never terminates.
     Thus parent processes wait forever, when this happens. Afbackup
     compresses each saved file separately i.e. starts the
     configured compression program for each file. When the problem
     described above arises, this compression program hangs and
     thus the whole chain up to the server process, that waits for
     requests until eternity.

     Solutions: (i'm aware, these are no real solutions)
      - switch off compression for the saved files or
      - change your Linux Kernel


Q11: Tape reels back and forth, mail sent "tape not ready ...", what's up ?

A11: The current state of investigations is, that this is probably
     a problem of a dirty read-write head. This may sound weird,
     but i'll try to explain.
      I experienced this problem without any warning. One day when
     starting a new backup i watched the tape reeling back and forth,
     later sending an email to the person in charge telling, that
     the device is not ready for use, and requesting to correct this
     problem. Compiling everything with debugging turned on i caught
     the server process during the initiliazation phase and found
     the Set-File-Command (mt -f ... fsf ...) failing. Then i found
     out, that there were fewer files on tape than the backup system
     expected (1 too few) and thus the mt failed. I had no idea, how
     this could happen. I corrected everything manually by decrementing
     the writing position on tape. The next backup, that i started,
     worked fine and another one immediately following, too. A verify
     also succeeded. So i took out the tape and decided to ignore the
     fault for the moment. Before i ran the next backup, i started a
     verify to see, what has changed within the meantime, but now
     again: tape reels back and forth endlessly. Looking onto the
     tape manually using mt and dd once again: too few files on tape.
     Seemed like some file (not the last one on tape !) was lost.
     Strange. The only thing i could imagine causing all the trouble
     was an error of the tape drive, e.g. a dirty read-write-head.
     So i put in the next tape and started all over at the beginning
     of the new tape. Everything worked perfectly from now on. The
     phenomenon has been reported to me on Linux with DAT-streamers
     from HP. This could mean a correlation and/or a problem of a
     Linux driver, but the reported number of 2 is in my opinion too
     small for a conclusion like this. Furthermore i guess, the com-
     bination Linux + HP-DAT-drive is very common, so the probability,
     that problems might arise in such an environment is quite high
     simply due to the number of installations of this kind.
     Admittedly i had been too lazy for a notable while to use any
     cleaning cartridge, so i guess this had been the problem.
     A similar phenomenon has been reported to me on Solaris on a
     Sun with a 'Sun' DLT drive (AFAIK the drives labeled as Sun
     products are often Quantum), but there the cause was a damaged
     read/write head.

     Solution (to get out of the temporary inconvenience):
      - Use a new cartridge and tell the backup system to use it with
        the serverside command
                    /path/to/cartis -i <nexttape> 1
        where <nexttape> is the number of the next cartridge

     Conclusion:
      - Feel urged to use cleaning cartridges regularly

     Reportedly another problem may be heat. When the device and/or
     the media temperature is too high, it seems the streamer can't
     read/write the tape correctly anymore. In the reported case
     cooling down all the stuff recovered proper operation, but i
     wouldn't expect this generally.
     In any case: if the tape temperature gets too high, the magnetic
     patterns on the media might weaken irreversably and thus data
     can't be read anymore. Avoid to let your cartridges to become
     too hot !!!

     See also Q25


Q12: The server seems to have a wrong tape file count, what's wrong ?

A12: Probably you experienced the following: The last filename in
     the filename log is preceded by a different pair of cartridge
     number / tape file number than the pair named in the report
     email, written to the tape-position file on the server or
     queried with the client-program option -Q.
      This is perfectly possible. The last saved file can make the
     tape file exceed the configured maximum length. Then one or
     more further tape files are opened appropriately.


Q13: When using crond, the client seems not to start correctly ... ?

A13: You probably get the message "Connection to client lost ..."
     in the clientside logfile. This is a weird problem i only
     experienced on IRIX. The program gets a SIGPIPE and i have no
     clue, why. You might start full_backup or incr_backup with the
     option -d, which causes the program to detach from the terminal
     and to wait for 30 Seconds before continuing. Maybe this solves
     your problem.


Q14: What does AF mean ?

A14: Another F......


Q15: Though client backup works, remote start does not. Why ?

A15: The problem is in most cases, that during the remote start
     the configured (un)compression programs, usually gzip and the
     corresponding gunzip, are not found in the search path. Cause
     the remotely started backup is some child of the inetd, it
     gets of course the inetd's command search path. If this does
     not contain the path to gzip, the start fails.


Q16: My server does not work, tape operates, but nothing seems to be written ?

A16: There seems to be a problem on some platforms. Try to start the
     server with the -b option: Edit /etc/inetd.conf and add -b before
     the last argument of afserver in the line starting with afbackup.
     Then send a hangup signal to the inetd (ps ... |grep inetd -> PID,
     kill -HUP <PID>). Then try again. If it works, be happy, but be
     aware, that the performance is reduced in this mode. This problem
     is worked on.


Q17: I have a ADIC 1200G autoloading DAT and no docs. Can I use it with HPUX ?

A17: Thanks to Gian-Piero Puccioni ([e-mail]) you can. You will find
     the mtx.c program he wrote helpful. Check out this file how to
     build and use his mtx command. It enables you to load/unload/handle
     certain cartridges.


Q18: What is a storage unit and how and why should i use it ?

A18: See in the HOWTO, Q9


Q19: Why should i limit the number of bytes per tape ?

A19: This is particularly useful, if you first write the backup into a
     filesystem and then copy that `disk cartridge' to a real tape with
     the copy_tape command or the autocptapes script. In this case the
     space used in the filesystem must be limited to the capacity of the
     appropriate tape, otherwise loss of data may occur as the data is
     copied 1:1 to tape and auto-continuation to the next tape does not
     make sense. Also see FAQ Q1, how to determine the capacity of a
     tape.


Q20: What are backup levels and why should i use them ?

A20: Backup levels allow backups, that store more than an incremental
     backup, but fewer than a full backup. How is this achieved ?
     More than one timestamp is used, each associated with a certain
     "level". A good way to explain levels is to explain a certain
     scenario. A level is first of all just a number. When an incre-
     mental backup is started with a given level (option -Q), all
     files will be saved, that have not been saved since the most
     previous backup with the same or higher associated level. The
     highest level is owned by the full backup. A "picture" for
     clarifying:

      T full backup
      |
      |
      | - - - - - - - - - - -T level 3
      | - - - - -T level 2   | - - - - -T level 2 - T level 2
      |          |           |          |           |
      |          |           |          |           |
     -+----------+-----------+----------+-----------+---------> time
      T1         T2          T3         T4          T5

     At the date T2 anything not saved since T1 is saved. This is
     basically an incremental backup compared to the full backup.
     At date T3 also anything not saved since T1 is saved, because
     the associated backup level is higher. At date T4 anything
     not saved since T3 is saved again, cause now the level is
     lower then at T3. At T5 everything not saved since T4 is
     again saved. If only one backup level is used, this has the
     same effect as simply incremental backups. Note, that not
     every level must really be used, the numbers are only compared
     with each other to decide, what timestamp will apply.
     With afbackup the incremental backup without a certain level
     has the implicit level 0, the full backup has level MAXINT
     (the value of this macro depends on the machine, where it has
     been compiled, on most Unix-machines MAXINT has a value of
     2147483647). With option -Q any value inbetween can be used.
     The timestamps are stored in the file
     /path/to/client/var/level_timestamps and can be read as clear
     text (just in case you used that many levels, that you get
     confused and don't know any more, what levels you used and
     which are still unused ... ;-) )


Q21: What do all the files in the var-directories mean ?

A21: Serverside:

     status        This file is updated, whenever a notable server
                   status change occurs. The file is always removed
                   and created again as status changes occur often
                   and they are not worth keeping. This file only
                   serves the purpose to get an information about
                   what is currently going on. While reading or
                   writing the current throughput is reported here
                   about every 5 seconds. Logging of errors or
                   warnings goes to the configured logfile.

     pref_client   This file is maintained to prevent colliding
                   client accesses. The clients should have
                   a chance to get the server always again, when
                   querying several times within a certain interval.
                   The previously served client and a timestamp is
                   saved here to grant this client preferred service
                   within a certain interval. Actually since version
                   3.3.5 this file is obsolete

     bytes_on_tape The persistent counters of the server side. A
                   maximum number of bytes per tape can be configured
                   and the server must remember, how much he had
                   written to all of the tapes. It makes no sense to
                   count them all each time a cartridge is loaded.
                   The format of each line is (backslash indicates
                   a continuation line and is no syntax element):
                    <cartridge-number>: <number-of-bytes-on-tape> \
                            <number-of-files-on-tape> <tape-full-flag> \
                            <last-writing-timestamp>

     tapepos       The name of this file can be configured in the