845.txt
=====================================================================
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
AUTOCHK
IF verror <> 0 THEN
ABORT ON
PAUSE 2 USING +
'Errors found. Contact database administrator'
ENDIF
RETURN
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
found.
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
database.
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.