faq

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

                   serverside configuration file, but i think, noone
                   will ever change it. This file contains entries,
                   that specify tape positions in different contexts.
                   Lines starting with a number followed by a colon
                   specify the writing position for the cartridge set
                   specified by the leading number. Lines starting
                   with a device name field indicate, what tape in
                   which position is currently in that drive. Each
                   pair of numbers specifying a position consists of
                   a cartridge number and a file number.

     precious_tapes  This file contains a line for each client, listing
                     which cartridges the client needs for restoring
                    everything it saved and it wants access to. All
                   cartridges listed here are considered read-only, if
                   they have no more space on tape to write to. If they
                   have free space, new data is appended at the end of
                   the last file on tape during write

     readonly_tapes  This file contains lists of cartridge numbers,
                     that should not be written to anymore. This file
                    can be edited or modified sending an appropriate
                   server message (See: afclient, option -M). The
                   format of this file is simply numbers, ranges or
                   comma-separated numbers of cartridges. A range can
                   be given as [<start-number>]-[<end-number>], e.g.
                   2-4, -2 or 8-. In the last example the number of
                   cartridges configured in the server configuration
                   file will apply for the end of the list.

     cartridge_order  The server must remind, what tape follows which
                      other one, because their order no longer follows
                     the number of the cartridge and the server no
                    longer starts writing the first one after the last
                   one is full. Tapes can be set read-only or marked
                   crucial for restoring some client. So it may occur,
                   that the server must skip one or more tapes to find
                   a writable one. Also in full append mode it might
                   happen, that it is not the first file on tape, who
                   follows the last one on a full tape. In this file
                   the order is saved, what file on which tape must be
                   read, when a certain tape is exhausted. Behind the
                   number of the cartridge in the first column and the
                   arrow characters -> the following numbers name the
                   tape and file to be read next. This file should be
                   saved to some other location, because it is crucial
                   for restore.

     tape_uses     This file contains a list of cartridge numbers in
                   the first column, followed by a colon : . The second
                   column contains a number indicating, how often this
                   tape has become full up to now. This number is supplied
                   to the configured Tape-Full-Command , whenever a tape
                   becomes full.

     cartridge_locations  This file contains the database, where the
                          cartridges currently can be found. The first
                         column is the cartridge number, followed by a
                        colon. A space follows and the rest of the
                       line either contains three fields: the device
                      name of the media changer, a word to specify the
                     location class (drive, slot or loadport), and a
                    number counting instances of location classes, e.g.
                     /dev/rmt/stctl0 slot 6
                   If the rest of the line is not of this form, it is
                   considered to be a freetext description.

     ever_used_blocksizes  This file contains a list of all the tape
                          blocksizes, that have ever been used on the
                         the server. The list is used to quickly find
                        the correct blocksize for reading, when the
                       tape cannot be read with the configured one. If
                      tapes are used, that come from another server and
                     have a tape blocksize, that this server has never
                    seen, the unknown blocksize should be added to this
                   file manually, one per line.


     Clientside:

     num           Here the current total number of backups is stored.
                   The total number of backups is incremented each time
                   a full backup finishes successfully, if not the append
                   mode (option -a) is selected or files and directories
                   are explicitly supplied as arguments. This case is
                   considered an exceptional storing of files, that should
                   not affect counters or timestamps

     part          If present, it contains the number of the backup part
                   that has recently started. Full backups can be split
                   in pieces if a complete run would take too much time.
                   This can be configured with the parameters
                   NumBackupParts, DirsToBackup1, ...

     oldmark       The Modification time of this empty file serves as
                   memory for the timestamp, when any full or incremental
                   backup has started before. This should be handled in
                   the file explained next, but due to backward compati-
                   bility issues i will not change this (historical error
                   coming from the earlier used scripts for backup and
                   the use of the find-command with option -newer)

     newmark       During backup a file holding the timestamp of the
                   backup starting time. The reason, why this timestamp
                   is kept in the filesystem is safety against program
                   crashes

     level_timestamps  This file contains the timestamps for the backup
                       levels. Each line has the following format:
                    <backup-level>: <incr-backup-starting-time>
                   For each used backup level and the full backup a line
                   will be maintained in this file

     save_entries  This file holds the patterns of all configuration
                   entries in DirsToBackup, DirsToBackup1, ...
                   for use in subsequent backups. If new entries will be
                   configured, this file allows to automatically switch
                   to full backup from incremental backup, when a new
                   entry in the configuration file is found

     needed_tapes  This file contains a list of tapes needed for full
                   restore of all files listed in existing filename list
                   files (i.e. index). The number of these files depends
                   on the clientside parameter NumIndexesToStore. After
                   each backup (full or incremental or level-N) a line
                   is added to this file or an existing one is extended
                   to contain the current backup counter and a list of
                   backup levels, each associated with the cartridge
                   numbers used during write to the server with the
                   named ID. The format is:
                    <backup-counter>: <backup-level>><tape-list>@<serverid> \
                           [ <backup-level>><tape-list>@<serverid> ... ]
                   When running an incremental or differential backup
                   supplying the option -H, entries with a level lower
                   than the current one (or in differential mode equal
                   to the previous) are removed from this list. Thus the
                   tapes from these entries are permitted to be written
                   again (often called "recycled"). After each update of
                   this file, the list of all required tapes residing at
                   the current server is sent to this server and there
                   stored in the file precious_tapes (see above). When
                   tapes are removed from the file precious_tapes on the
                   server, the client updates his needed_tapes file and
                   the index contents accordingly.

     start_positions  Here for each full or incremental backup within the
                      range required by the parameter NumIndexesToStore
                    the information to retrieve all the data is stored.
                   Each line has the format
                    <backup-counter>: <backup-server> <backup-service> \
                               <cartridge-number> <file-number>
                   Having this information everything can be restored in
                   case all other data is lost

     server_ids    The information, which server network address has which
                   server-ID assiciated. The first two columns contain the
                   hostname and port number, the third the server-ID

     index_ages    For each existing index file, this file contains a
                   line with the index number in the beginning, followed
                   by a colon and the timestamp of the last modification
                   of that index in seconds since epoch (1.1.1970 0:00).
                   This file is evaluated, if the client side parameter
                   DaysToStoreIndexes is set.


Q22: Help ! My (multi stream server's) client receives no data, why ?

A22: Most likely the client's official hostname has changed. The server
     does not recognize any more, what data on tape should be dispatched
     to this client. Use option -W to supply the client's old official
     hostname or configure that name using the configuration parameter
     ClientIdentifier in the client side configuration file.


Q23: My DLT writes terribly slowly and changes cartridge too early, why ?

A23: The reasons for the too early rewind are admittedly unknown.
     It has been reported, that EIO is returned during a write without
     any obvious reason. It seems, that this can be avoided and a much
     better throughput be achieved configuring a relatively large tape
     blocksize. For a DLT 32768 seems to be a good value.


Q24: When should i use the multi stream server and when not ?

A24: Basically for restore or verify you don't have to choose. The same
     port (what finally means: the same server) like during backup is
     set automatically. You do not have to care about that. For backups
     i'd suggest the following:

     Use multi stream server

      * For incremental backup of several machines in parallel. In this
        situation the multi stream feature can be a real time saver

      * For full and/or incremental backup of several machines connected
        to the backup server over slow links, where the machines must
        have separate lines each. The following scheme shows a configu-
        ration, where exploiting the multi-stream feature makes sense
        also for full backups:

                   --------
                  | server |
                   --------
                       |
                       | (fast link(s))
                       |
               --------------------------
              | switch/bridge/hub/router |
               --------------------------
                 /         |          \
                /          |           \     (slow links)
            --------    --------    --------
           | client |  | client |  | client |
            --------    --------    --------

     Use single stream server

      * For full backups over fast lines, where the streamer device is
        the bottleneck. Here the additional overhead of the multiplexing
        server might become the bottleneck on slower machines

      * For messages to the server (option -M of the afclient program)
        (mandatory !)

      * For trivial operations in combination with the afclient program
        (e.g. options -q, -Q, -w)

      * For copying tapes (copy_tape)

      * For emergency recovery with option -E

     Summarizing it i'd suggest to configure the single stream server as
     default and override the default with the appropriate options, when
     desired. The option for the afclient program is -p, for the others
     (full_backup, incr_backup, restore, verify, copy_tape) -P .


Q25: Why is my 2 GB capacity DAT tape full having written about 1.5 GB ?

A25: The following statements i collected as experience from different
     users. I pass them on here without any comment.

     Thanks to Mr. Andreas Wehler at CAD/CAM Straessle GmbH in D黶seldorf/
     Germany the following statements have been collected from HP and
     others:

      - With not compressable data DAT tapes have a real capacity of
        between 75 and 84 % of the capacity specified on the cover

      - The capacity decreases during lifetime cause of increasing
        defect density as a result of wearing out

      - No user will get notified of the current media capacity status

     DAT specs say:

        60m      DDS,    1.3GB uncompressed
        90m      DDS,    2.0GB uncompressed
       120mm     DDS-2,  4.0GB uncompressed

     Capacities achieved with new tapes in reality:

      Experience of User A:

        60m:  1.1GB
        90m:  1.6GB
       200m:  3.3GB

      Experience of User B:

        60m:  1.1GB
        90m:  1.5GB
       200m:  3.3GB

     Technical aspects:

      HP writes data in 22 frames of 128 KB each to a 90 m tape,
      what should make a capacity of 2.8 GB

      Tapes are not written completely, trailers remain free for
      possible later error correction

      The specified capacity is a theoretical value for advertising.
      They assume raw/unformatted writing to tape and do not take
      the normal format overhead into account. It is known, that the
      named values can never be reached. The discrepancy of 25 % to
      the specifications is relatively high, but "tape experts" are
      considering this to be normal.