Man Page Index
There are three ways of backing up your database.
This should only be used to transfer your data to a non-jBASE system. The indexing information will be lost.
tar and cpio
These Unix supplied backup utilities will backup ALL jBASE files and not care if they are hashed files, index files, dictionary items and so on. These should be used with caution, and only against databases where there is no update activity. The tar and cpio programs will not respect the locks on a file that jBASE normally uses.
jbackup and jrestore
These are the jBASE supplied backup and restore programs and are the preferred way of backing up your data. They respect all locks and will keep the tapes free from any soft format errors that would otherwise occur if using tar and cpio on an active database.
By default , when you use jbackup to save a database, any indexing information will be saved as just the index definition, not the actual index data. Conversely during a restore using jrestore, the index definition will be restored, but not the index data, whether it exists on tape or not.
So the full scenario, by default
(i) Backup your database:
find . -print | jbackup -v -f/dev/rmt/0
(ii) Restore your database:
rm -rf *
jrestore -v -f /dev/rmt/0
(iii) Rebuild indexes. The stage (ii) will have restored the database and the index
definitions, but not the index data. Now to rebuild the index data for all the files you
have just restored:
rebuild-index -r $HOME
If you have restored files into sub-directories you could use the following Unix command to rebuild the indexes for all files in all sub-directories
find . -print | xargs rebuild-index
When you backup a database with jbackup, you can use the "-c" option and this will backup the actual index data as well as the data files. The index data will be dumped as a normal Unix binary file , and so during the restore phase will be restored exactly as-is.
When you restore a database using jrestore, by default it will restore the index information, but will NOT rebuild the index data. This is quite time-consuming and so by default the jrestore works in the quickest mode. The index will need to be re-built at a later stage using rebuild-index. In the meantime, any attempts to use query-index or key-select will fail, and the jQL programs such as COUNT and SELECT will not use the index in order to satisfy the request. During the restore a warning message will be shown against each file that needs re-building. Once the rebuild-index has completed, the index will become available again to the jQL programs and query-index.
You can optionally use the -N option to jrestore and this will result in the indexes being built as the data is restored. This will slow down the restore time, but means the index is immediately available for use without the need to re-build the indexes with rebuild-index.