Dynamic Backup

DYNABACK has two completely different modes of operation. The first mode of operation creates a backup in the designated backup directory in the format used by DBRESTOR. The second mode of operation creates a copy of the DP4 database files, in exactly the exact format as regular database files, but with different file extensions. The second mode of operation has important benefits, but does require that you have space for at least two and preferably three copies of your database files on the machine at the same time.

DYNABACK does not directly support back up to tape. To back up to tape without interruption you can use the DYNABACK -COPY to create a copy of the database and then use DBBACKUP -TAPE, or a batch/script to back up that copy to tape.

Backup in DBRESTOR format

1. Make sure you have a supply of formatted diskettes (or use the −format command tail).

2. On the DP4 System menu, select the Backup/Recovery option. The Database Backup, Recovery and Check menu is displayed.

3. Select the DynaBack option.

4. Select the database, specify whether you want to verify the backup, add any comment to be displayed when restoring. Then, insert, remove and label the disks as requested. (The process is more or less to that for DBBACKUP, and is explained in greater detail in Backing up to Diskette.)

   If your system had a log file, it will have been deleted and the log session number incremented. The database session number has been incremented. A new log is created by carrying out a transaction on the database.

Backup in Native DP4 Database Format

1. On the DP4 System menu, select the Run Program option and enter the following command: DYNABACK −COPY. You may use the −DB database_name command tail to specify the name of the database.

2. If you did not enter the name from the DP4 menu enter the name of the database to be backed up. The backup process will start, and is completely automatic from now on. The following operations are performed:

   1. DYNABACK copies the database to a temporary database name ($$$0AC or something similar). This copy is written in the normal database directories (hence the need for space for at least one additional copy of the database). The copy is done using special internal functions from the database manager. This allows the database to be backed up while it is still open. The mechanism for doing this depends on DP4 rollback recovery. Please note that while DYNABACK is backing up the database the rollback file cannot be restarted, and it can therefore grow to quite a large size. It is advisable to run DYNABACK at periods of low activity.

   2. When the backup has completed DYNABACK immediately runs DBRECOV against the backed up database to apply the backed up rollback and transaction logs. The copy of the database is then identical to the original database immediately prior to the point the backup completed.

   3. Next DYNABACK runs DBCHECK against this database:

      • If no corruptions are found the backup is good. At this point the backup files are renamed to DBNAME.DB1 (renamed .dat file) and DBNAME.IB1 (renamed .ind file) or to DBNAME.DB2 and DBNAME.IB2. Simililarly, and if used the backed up .DCI and .PTR files are renamed to DBNAME.CBn and DBNAME.PBn. A marker is written to the original database to indicate that a successful backup has completed, and to indicate whether the B1 or B2 name has been used. The names are used alternately, because it is not safe to delete the previous backup until the current backup has completed, verified AND the database has been notified of this. Once this process is completed the previous backup is deleted if it is still present (if it was you must have had space for three copies of the database). If space permits it is advantageous to keep the current backup online, as it will permit a faster recovery if the database is lost (for example if DBRECOV fails following a system crash).
        
        

      • If the DBCHECK process discovers a problem on the backed up database the bad backup is renamed instead to .IBB and .DBB. (It is not deleted automatically, as you may wish to run DBCHECK or other utilities interactively to discover more about the problem). However, as the backup is corrupt, it is very likely that there is a problem with the original database. Therefore a special flag is set in the original database. When applications are run against the database they will display a warning message indicating that the database has a probable corruption, and that DBCHECK should be run. This message will continue to be displayed by each new application until such time as DBCHECK is run, and passes, the database is successfully reorganised with REORGDB, or a backup copy of the database is restored. Normal operation is not disabled, as sometimes it is preferable (from a user point of view) to risk continue operating with a database that is corrupt, rather than disrupting the system by immediately restoring a backup. This flag also gets set if the database manager encounters a problem which causes a system error 87 (database corruption).

After a successful backup the backed up database files should be copied to tape, or CD ROM, or a hard drive on another machine. As the files are are in the regular DP4 database format the restore process is a single step operation - there is no need to run DBRESTOR afterwards, except to apply a log file. Alternatively a CD ROM copy of the database can be accessed in the normal way by DP4 programs, which may be useful for archive purposes.

Other options (with -COPY option)

If your database is very large it may take too long or have an unacceptable impact on performance to run DBCHECK against the backup, though it is of course the backup and not the live database that is being checked. It is therefore possible to disable the automatic DBCHECK that takes place after a -COPY backup. You are recommended not to do this unless absolutely necessary. We have recently been able to run DBCHECK against a 3 Gigabyte database in only a few hours, (on a PC with only a 200MHz Pentium MMX) so do not assume that you cannot run DBCHECK. If you do use the option to disable DBCHECK then you should transfer the backed up database to another computer where you can run DBCHECK without impacting performance of the system. If you do not run DBCHECK at least once during the backup cycle you risk losing your database. It is best to run it after every backup, otherwise you may waste time restoring a backup that itself turns out to have a corruption.

If despite the above you want to disable automatic DBCHECK as part of the backup process then specify −NOVERIFY on the command line to DYNABACK.

Additional notes on -COPY option

• The backup process does not transfer database data across the network, so it may be run on a client. Note however that the DBCHECK phase does transfer data across the network, so it is best to run from the server unless the -NOVERIFY option is used. At the time of writing release 4.622 does not support running DBCHECK over a network, so in this case DYNABACK must be run with -NOVERIFY if run across the network.

• The backup process only prevents the rollback file from being flushed while the database is actually backing up. Therefore running DBCHECK as part of the backup will not adversely affect the size of the rollback file.

• From release 4.622 you can use DYNABACK to copy an open database to another name, rather than to backup the database, by specifying the command tail −NEWDB newname. When you use this option the original database will continue to use its existing log file rather than start a new session.