Non‑JADE Backups

It is never valid to backup a JADE database that is not closed, quiesced, or conditioned for external third‑party snapshot, by using non‑JADE backup software.

When a third‑party tool is used to backup a JADE database, the backup must be taken when the database is closed, quiesced, or conditioned for an external third‑party snapshot.

The preferred option is that the backup should be taken when the database is closed, as this allows use of the batch JADE Database utility (jdbutilb) custom backup support convertToBackup feature.

This verifies the files and creates the restoreinfo file that contains MD5 file checksums, and an operational log in the database directory. If the convertToBackup operation is successful, you can then perform the required action with the database image; for example, copy the files to tape.

If ever the files are copied to a new disk location, they can be verified using the JADE Database utility verifyChecksums function, which will recalculate and compare the file checksums with those that were originally written to the restoreinfo file.

If the backup is to be taken while the database is quiesced, call the JadeDatabaseAdmin class changeDbAccessMode method, specifying Mode_Archive and Usage_ReadOnly. To return the database to operational state when the backup is complete, call the changeDbAccessMode method, specifying Mode_Default (the usage parameter value is not used when the mode is specified as Mode_Default). For details, see the JadeDatabaseAdmin class in the JADE Encyclopaedia of Classes.

You can also do this externally, by using the jomChangeAccessMode Application Programming Interface (API) call. For details, see "Changing the Database Access Mode", in Chapter 3 of the JADE Object Manager Guide. This process results in a consistent image of the database being backed up, but the database was not verified during the backup and the resultant image does not contain the checksum information necessary to check the integrity of the image when it is restored.

When a primary changes to archive mode, the SDS service, if active, is stopped. The service is restarted as necessary when exiting from archive mode.

If the backup is to be taken while the database is being updated, call the JadeDatabaseAdmin class changeDbAccessMode method, specifying Mode_Snapshot and Usage_Update. This conditions the database for snapshot recovery, as follows.

To exit from snapshot mode when the backup is complete, call the JadeDatabaseAdmin class changeDbAccessMode method, specifying Mode_Default. This transitions the database out of snapshot mode, as follows.

It is essential that the backup processing occurs entirely while the database is in snapshot mode, and that as a minimum, journals from the start snapshot checkpoint to the END_SNAPSHOT record will be available for snapshot recovery.

If the database is accidentally closed while it is in snapshot mode, do not restart the database until the backup has completed. When restarted, the database will perform a snapshot recovery.

To recover from a third‑party backup taken while in snapshot mode, perform the following actions.

Snapshot recovery is performed when database recovery (from database open, or JADE Database utility‑initiated recovery) detects the database is in snapshot mode. The _control.dat file is replaced with the _control.snap file and a roll‑forward recovery is performed. If the recovery was JADE Database utility‑initiated, the roll‑forward termination condition is that specified by you; otherwise the roll‑forward recovery is to end‑of‑last‑journal.

Roll‑forward recovery logic looks for the END_SNAPSHOT audit record. This indicates the point at which file integrity is known to be restored, assuming that the snapshot completed and the recovery is not due to restart.

Recovery due to restart will encounter the LOG_TRAILER or a header discontinuity, set snapshot state to incomplete, and then continue recovery as normal.

If a roll‑forward termination condition was specified and that condition is met before the database can establish an end‑snapshot condition, the recovery will fail with a 3192 error (Snapshot recovery terminated before end-snapshot condition established).

The end‑snapshot condition is satisfied when an END_SNAPSHOT record is encountered, or in its absence, a DATABASE_CLOSE or DATABASE_OPEN record is encountered. Snapshot state is set to recovered, and recovery then continues as normal.

If the third‑party backup tool is file‑based rather than block‑based, it will not be able to copy _control.dat, which is opened in exclusive mode by the database. This file can be excluded from the backup and when the database is restored, the _control.dat file can be recreated by copying _control.snap as _control.dat.

It is usual for third‑party block‑based backup tools to copy blocks changed since the last backup, and blocks that change during the backup. Therefore at the end of the backup, the image will contain all updates to journals in the journals\current directory.

Restoring such a backup and initiating the system without otherwise restoring journals will behave as a snapshot recovery due to restart.

To achieve the same behavior when the third‑party backup tool is file‑based, however, requires that the backup tool copies the journals after the data files have been copied.