The Zebra server supports updating of the index structures. That is, you can add, modify, or remove records from databases managed by Zebra without rebuilding the entire index. Since this process involves modifying structured files with various references between blocks of data in the files, the update process is inherently sensitive to system crashes, or to process interruptions: Anything but a successfully completed update process will leave the register files in an unknown state, and you will essentially have no recourse but to re-index everything, or to restore the register files from a backup medium. Further, while the update process is active, users cannot be allowed to access the system, as the contents of the register files may change unpredictably.
    You can solve these problems by enabling the shadow register system in
    Zebra.
    During the updating procedure, zebraidx will temporarily
    write changes to the involved files in a set of "shadow
    files", without modifying the files that are accessed by the
    active server processes. If the update procedure is interrupted by a
    system crash or a signal, you simply repeat the procedure - the
    register files have not been changed or damaged, and the partially
    written shadow files are automatically deleted before the new updating
    procedure commences.
   
At the end of the updating procedure (or in a separate operation, if you so desire), the system enters a "commit mode". First, any active server processes are forced to access those blocks that have been changed from the shadow files rather than from the main register files; the unmodified blocks are still accessed at their normal location (the shadow files are not a complete copy of the register files - they only contain those parts that have actually been modified). If the commit process is interrupted at any point during the commit process, the server processes will continue to access the shadow files until you can repeat the commit procedure and complete the writing of data to the main register files. You can perform multiple update operations to the registers before you commit the changes to the system files, or you can execute the commit operation at the end of each update operation. When the commit phase has completed successfully, any running server processes are instructed to switch their operations to the new, operational register, and the temporary shadow files are deleted.
    The first step is to allocate space on your system for the shadow
    files.
    You do this by adding a shadow entry to the
    zebra.cfg file.
    The syntax of the shadow entry is exactly the
    same as for the register entry
    (see Section 7, “Register Location”).
     The location of the shadow area should be
     different from the location of the main register
     area (if you have specified one - remember that if you provide no
     register setting, the default register area is the
     working directory of the server and indexing processes).
   
    The following excerpt from a zebra.cfg file shows
    one example of a setup that configures both the main register
    location and the shadow file area.
    Note that two directories or partitions have been set aside
    for the shadow file area. You can specify any number of directories
    for each of the file areas, but remember that there should be no
    overlaps between the directories used for the main registers and the
    shadow files, respectively.
   
     register: /d1:500M
     shadow: /scratch1:100M /scratch2:200M
    
    When shadow files are enabled, an extra command is available at the
    zebraidx command line.
    In order to make changes to the system take effect for the
    users, you'll have to submit a "commit" command after a
    (sequence of) update operation(s).
   
     $ zebraidx update /d1/records 
     $ zebraidx commit
    
Or you can execute multiple updates before committing the changes:
     $ zebraidx -g books update /d1/records  /d2/more-records
     $ zebraidx -g fun update /d3/fun-records
     $ zebraidx commit
    
    If one of the update operations above had been interrupted, the commit
    operation on the last line would fail: zebraidx
    will not let you commit changes that would destroy the running register.
    You'll have to rerun all of the update operations since your last
    commit operation, before you can commit the new changes.
   
    Similarly, if the commit operation fails, zebraidx
    will not let you start a new update operation before you have
    successfully repeated the commit operation.
    The server processes will keep accessing the shadow files rather
    than the (possibly damaged) blocks of the main register files
    until the commit operation has successfully completed.
   
    You should be aware that update operations may take slightly longer
    when the shadow register system is enabled, since more file access
    operations are involved. Further, while the disk space required for
    the shadow register data is modest for a small update operation, you
    may prefer to disable the system if you are adding a very large number
    of records to an already very large database (we use the terms
    large and modest
    very loosely here, since every application will have a
    different perception of size).
    To update the system without the use of the the shadow files,
    simply run zebraidx with the -n
    option (note that you do not have to execute the
    commit command of zebraidx
    when you temporarily disable the use of the shadow registers in
    this fashion.
    Note also that, just as when the shadow registers are not enabled,
    server processes will be barred from accessing the main register
    while the update procedure takes place.