Backup and restore strategy.
Backup and restore strategy.There are four ways of backing up your database, summarized as :
| Method | Description |
|---|---|
| ACCOUNT-SAVE | This should only be used to transfer your data to a non-jBASE system. The indexing information will be lost. |
| Unix 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. tar and cpio will not respect the locks on a file that jBASE normally uses. |
| NT Backup | This Windows NT supplied utility 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 NT Backup 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. These programs will now be discussed with the impact of secondary indexes. |
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. Following a restore therefore your index data would not be in-sync with your file data and so would require a rebuild-index to complete. The restore is defaulted in this manner so that the restore completes as quickly as possible.
So the full scenario, by default, would be :
(i) Backup your database:
Unix
% cd $HOME
% find . -print | jbackup -v -f/dev/rmt/0NT
jsh -> cd %HOME%
jsh -> jfind . -print |jbackup -v -f \\.\TAPE0
(ii) Restore your database :
Unix
% cd $HOME
% rm -rf *
% jrestore -v -f /dev/rmt/0NT
jsh -> cd %HOME%
jsh -> del *.*
jsh -> jrestore -v -f \\.\TAPE0
(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 :
% cd $HOME
% 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 the 'rebuild-index' program. 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 satisfy the request. During the restore a warning message will be shown against each file that needs re-building. Once the 'rebuild-index' program has completed, the index will become available again to the jQL programs and 'query-index' and 'key-select'.
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'.
http://807199.827977/r5/knowledgebase/manuals/3.0/SecondaryIndexes/html/backup.htm last modified on 06/19/09 05:29 AM