HEPDB has its own built-in backup mechanism which consists of writing all journal files which are processed by cdserv to the save subdirectory. Any slave node which for whatever reason misses part or all of an update can be brought up to speed by copying the relevant files from the save directory to the corresponding to_nodename directory on the master node and then running cdmove.
This procedure is useful but can quickly get cumbersome when there are many files in the save directory. To make the recovery process easier a SNODB procedure makes a time-stamped backup file consisting of the most recent set of files written to the save directory. During this procedure it is crucial that the cdserv process on the master node is not running to avoid the possibility that the database gets changed during the backup. This is taken care of automatically in the script which runs the backup. Once the backup is complete, the files in the save directory are deleted. In this way, each backup file will represent the full set of individual updates associated with each official database update set. These backups are an integral part of the procedure which the database czar uses to perform the official database update.
In addition to the above procedure, all files associated with the
database need to be backed up on a regular basis. It is imperative
that disk-resident, several-versions-deep backup copies are available
on the master node, and that a backup is made prior to any
procedure which necessitates a SNODB version number change. The
version number is incremented by changes in the SNODB scripts, an
update implementation, or a database cleaning, or other things we have
not yet thought of. It is also critical that regularly scheduled
backups are made on (say) a weekly basis during commissioning, and
thereafter on a monthly basis. The backup triggered by a change in
version number can be initiated by the associated checking or
maintenance code. The regularly scheduled backups can be done as part
of standard system procedure on the master node, or perhaps as a
standard SNODB procedure. It is assumed that tar will do the
trick on UNIX systems, and that backup will do the trick on VMS
systems.