Protecting Your Data
     PRODUCT:  R:BASE                        VERSION: 6.0 or Higher
     CATALOG:  Database Integrity            AREA   : Integrity
     Not a week goes by in Technical Support that we don't talk to someone
     who has lost data or damaged their database files. The damage could
     have resulted from any number of causes, and often results from a
     problem external to the actual software. What can happen? Some things
     to think about are: power failures, hardware crashes, network
     problems, software problems, human error, computer virus, disgruntled
     employee, flood, fire, hurricane, earthquake, or "act of God." The
     unthinkable can happen. Who would ever have predicted that a freighter
     would ram a dock full of shops, many of whom have computer systems for
     sales accounting, or that we would see such tremendous and widespread
     damage this winter from snow and flooding? After the fact it is too
     late. You need to plan ahead and prepare for disaster, large and
     small. You can't foresee and protect against all possible causes of
     damage to your database, but you can take precautions to minimize the
     damage and the downtime involved in correcting the damage. Think
     ahead, plan, and then document the process.
     The most important step you can take to protect your database is to
     set up a regular backup procedure and stick to it. The procedure
     should include:
     * Daily backups
     * Checking the database before doing the backup
     * Storing one set of backups off site
     * Testing the backup procedure
     * Training more than one person in the backup procedure
     Daily Backups
     Customers call Technical Support for help because they do not have a
     current backup and need to retrieve data and repair the database. And,
     of course it is a mission critical application. Sometimes the
     database can be easily fixed, sometimes not. In all cases, a current
     database backup simplifies the situation.
     We have heard all the excuses for not having a backup or not having
     a usable backup. Some of the excuses we hear are:
     * The tape drive broke.
     * I ran out of floppy disks.
     * The person who does the backups is on vacation.
     * I formatted disk 1 of the backup set.
     * I didn't have time.
     * My backup has the same errors in it.
     * I'm new and no one showed me how to do a backup.
     * My backup is 2 months old.
     * My new tape drive won't read the old tapes.
     * We only use this database once a year.
     * We never enter that much data so we didn't think we needed a backup.
     These excuses come from people who then explain that their entire
     business is dependent on the database and the business is shut down
     until the database is fixed. It cannot be emphasized enough-if your
     data is important to you, then a backup should be even more important.
     With the technology and backup options available today, there is no
     excuse for not making daily backups of your database. You do not
     need to use the R:BASE backup menu option or BACKUP command to make
     a backup of your database. The R:BASE commands can be part of your
     regular backup procedure, but we recommend a file backup of the
     database files as well. The database files are the three or four
     (depending on which version of R:BASE you use) files named DBNAME.RB1,
     DBNAME.RB2, DBNAME.RB3, and DBNAME.RB4. And don't forget about your
     application files. The application will not need to be backed up as
     often as the database as it won't change every day, but make sure you
     do keep a backup copy or two, just in case.
     What options are there for making backup copies of your database
     files? There are inexpensive tape drives, large hard drives for
     copying the database, ZIP drives, removable hard drives, the options
     just go on and on. Backup procedures can be automated so that they run
     overnight and don't interrupt the daily business.
     We recommend using at least two different backup methods. This way,
     if one backup fails, you still have a chance of recovery. At
     Microrim, we make a tape backup each night of the network drive which
     includes the company database. A different tape is used for each day.
     In addition to the network tape backup, the database is copied to a
     local PC each night, and then reloaded back to the network. We always
     have at least two backup copies of the database.
     There are any number of backup procedures you can implement. What
     works for one company doesn't necessarily work for another. What's
     important is that you implement and follow through on a regular
     backup procedure for your database and application files. The cost
     and effort involved in setting up and implementing a backup procedure
     will pay for itself the first time you need to restore a backup.
     Don't think it can never happen to you, it will-the power goes out
     for three days due to a blizzard, a construction company cuts a cable,
     someone spills a cup of coffee or brings in a cute magnet to hold
     messages, the employee you fired for being late deletes files from
     the network file server.
     In addition to making daily backups, it is good practice to store at
     least one backup copy off site. A backup in the office isn't going to
     help if the roof caves in because of the snow, the gas main blows, or
     a burglar cleans out the office. Make sure at least two employees are
     familiar with the entire backup and restore process. That takes care
     of the "hit by a truck" and gone on vacation problems.
     Don't forget to verify the backup. We talk to many people who
     faithfully make backups every day. When they needed to restore a
     backup, however, they found out that the tapes were blank. It looked
     like the process was working but nothing was ever actually written to
     the tape. Make sure the restore process works and there are files
     there to restore.
     Check the Database Before a Backup
     You should always check the database before doing a backup to make
     sure there are no errors in the database. AUTOCHK has been included
     with R:BASE since version 3.1. AUTOCHK was designed specifically to
     run from an application to check the database before a backup or other
     maintenance procedure is run. If the AUOTCHK result shows errors, you
     don't want to perform the backup or other maintenance procedure such
     as PACK or RELOAD.
     Applications should include a menu choice or automatic procedure to
     check the database. In R:BASE 6.0, you have the ON CONNECT and ON PACK
     commands that can be used to check the database before packing or
     connecting the database. For example, you might add the ON PACK
     command to the startup block of your application,
     ON BEFORE PACK RUN autochk.cmd
     Then, before a PACK command in the application is executed, R:BASE
     runs the command file AUTOCHK.CMD. The command file checks the
     database for errors. If no errors, the PACK is executed; if there
     are errors, a message is displayed and the PACK command is aborted.
     The file might look like this:
     SET ERROR VAR verror
     IF verror <> 0 THEN
       ABORT ON
       PAUSE 2 USING +
     'Errors found. Contact database administrator'
     A similar routine could be run ON FIRST CONNECT, which would check the
     database when the first person connects each day. The ABORT ON command
     is used to not execute the CONNECT or PACK command if an error is
     One of the sample files included with R:BASE is called DBCHECK.CMD.
     This sample command file demonstrates code that can be used to check
     a database for errors. You can modify this code for use with your
     More Data Integrity Features
     R:BASE 6.0 includes a number of data integrity features in addition to
     ON CONNECT and ON PACK that can help you protect your data:
     * SET MIRROR-When MIRROR is set ON, a copy of the database is
     automatically maintained in another, specified location. Additions,
     changes, and deletions are simultaneously written to the working
     database and to the mirrored database.
     * SET WRITECHK-You can set WRITECHK to ON to have R:BASE automatically
     verify each write to disk. This guarantees that data is actually
     written to the disk and not cached in memory.
     * PACK INDEX-Use the PACK INDEX indexname command to rebuild just one
     index. This can save considerable time over having to rebuild all the
     indexes in the database.
     * AUTOFIX-The AUTOFIX command can be run from the operating system
     while users are still working in the database. Simple database errors
     can be corrected without taking the entire database off-line. After
     running AUTOFIX, use the PACK INDEX command to rebuild the indexes for
     the corrected table.
     Evaluating the Damage
     What happens when the database is damaged? The first thing to do is
     evaluate the damage and determine if you need to restore a backup
     copy or can fix the database. Sometimes the database can be fixed by
     just rebuilding indexes. If you are not familiar with AUTOCHK errors,
     you can call Technical Support and we will help you evaluate the
     errors. There is also documentation about AUTOCHK errors available on
     the Microrim Web site, http://www.microrim.com. Usually you need to
     look at all the errors in a database to determine the next step.
     Part of evaluating database damage is deciding if reentering data
     into a backup copy is quicker than trying to fix a database. That is
     often the case, particularly if you are not familiar with R:SCOPE
     yourself and would need to call in a consultant or mail the database
     to Microrim for repair. In addition, don't forget that whenever you
     correct a table with R:SCOPE or AUTOFIX, you need to rebuild the
     indexes for that table. R:BASE 6.0 has reduced possible downtime in
     that you can now run AUTOFIX or R:SCOPE and work on one table in a
     database while users are still entering data into other tables. Then,
     you can use the PACK INDEX indexname command to singly rebuild just
     the indexes in the affected table. After making corrections to a
     table, you must rebuild the indexes using PACK.
     Remember, damage to a database or computer system most often happens
     due to accident, oversight, or negligence. Document and have ready
     backups of all your database and application files. It is not an easy
     or quick process to plan for disasters happening to your database,
     and then to decide what to do when the unthinkable does happen, but
     being prepared can make all the difference between being down for
     four hours or for four days.