The scope of this tutorial is to present the database backup & restore capabilities in CUBRID. This is the 2nd part of the tutorial, focusing on CUBRID Restore.

Database Restore

A database restore is the procedure of restoring the database to a previous state, by using the backup files, active logs and archive logs created by a database backup procedure.

To perform a database restore, you will use the cubrid restoredb utility or the CUBRID Manager client.

CUBRID restoredb utility

The cubrid restoredb utility restores the database from a database backup, by using the information written to all active and archive logs, since the execution of the last backup.

Syntax:

For a successful restore, you must prepare backup files, active log files and archive log files. This command can be performed only in standalone mode.

The following table shows options that can be used with cubrid restoredb. Note that the options are case sensitive.

Usage examples

In this section we will present various examples of using the restoredb utility.

Performing a recovery by specifying a recovery point (-d or --up-to-date)

The following command recovers demodb. If no option is specified, demodb is recovered to the point of the last commit by default. If no active/archive log files are required to recover to the point of the last commit, the database is recovered only to the point of the last backup.

Note: If the -D option is not specified, backup files are stored in the folder specified in the databases.txt file.

demodb can be recovered to the given point by using the -d option and the syntax which specifies the date and time of the recovery. The user can specify the recovery point manually in the dd-mm-yyyy:hh:mm:ss (e.g. 14-10-2010:14:10:00) format. If no active log/archive log files are required to recover to the point specified, the database is recovered only to the point of the last backup.

The following syntax specifies the recovery point by using the -d option and the backuptime keyword and recovers demodb to the point of the last backup.

Performing a recovery by specifying the directory path to the backup files (-B or --backup-file-path)

You can specify the directory where backup files are to be located by using the -B option. If this option is not specified, the system retrieves the backup information file (dbname_bkvinf) generated upon a database backup; the backup information file in located in the log_path directory specified in the database location information file (databases.txt). And then it searches the backup files in the directory path specified in the backup information file. However, if the backup information file has been damaged or the location information of the backup files has been deleted, the system will not be able to find the backup files. Therefore, the administrator must manually specify the directory where the backup files are located by using the -B option.

If the backup files of demodb is in the current directory, the administrator can specify the directory where the backup files are located by using the -B option.

Performing a recovery by specifying the backup level (-l or --level)

You can perform a restoration by specifying the backup level of the database to 0, 1, or 2.

Performing a partial recovery (-p or --partial-recovery)

The following command performs a partial recovery without requesting for the user's response, by using the -p option. If active or archive logs written after the backup point are not complete, by default the system displays a request message informing that log files are needed and prompting the user to enter an execution option. A partial recovery can be performed directly without such a request message by using the -p option. Therefore, if the -p option is used when performing a recovery, data is always recovered to the point of the last backup.

When the -p option is not specified, the message requesting the user is prompted to select the execution option:

Storing recovery progress information in the specified file (-o or --output-file)

The following command writes the recovery progress of the database to the info_restore file by using the -o option.

Recovering data to the directory specified in the database location file (-u or --use-database-location-path)

The following syntax recovers the database to the path specified in the database location file (databases.txt) by using the -u option. The -u option is useful when you perform a backup on server A and recover the backup files on server B.

Checking the backup information of the database (--list)

The following syntax displays the information about backup files of the database by using the --list option; it does not perform recovery.

The following is an example of backup information displayed as a result of using the --list option. You can identify the path to which backup files of the database are originally stored as well as backup levels:

With the backup information displayed by using the --list option, you can check that backup files have been created at the backup level 1, as well as the point where the full backup of backup level 0 has been performed. To recover the database in the example, you must prepare first backup files for backup levels 0 and 1.

Backup & Restore on different servers

The following section shows how to backup demodb on server A and restore it on server B.

Let’s suppose that demodb is backed up in the /home/cubrid/db/demodb folder on server A and we want to restore it into /home/cubrid/data/demodb on server B.

Here are operations we need to perform:

Backing up on server A

Back up demodb on server A. If a backup has been performed earlier, you can perform an incremental backup for data only that have changed since the last backup. The directory where the backup files are created, if not specified in the -D option, is created by default in the location where the log volume is stored. The following is a backup command with recommended options:

Editing the database location file on Server B

Unlike a general scenario where a backup and restore are performed on the same server, in a scenario where backup files are restored using a different server, you need to add the location information on database restore in the database location file (databases.txt) on server B. In the diagram above, it is supposed that demodb is restored in the /home/cubrid/data/demodb directory on server B (having hostname=pmlinux); edit the location information file accordingly and create the directory on server B.

Write the database location information in one single line. Separate each item with a space. The line should be written in [database name]. [data volume path] [host name] [log volume path] format:

demodb /home/cubrid/data/demodb pmlinux /home/cubrid/data/demodb

Transferring backup/log files to server B

For a restore, you must prepare a backup file (e.g. demodb_bk0v000) and a backup information file (e.g. demodb_bkvinf) of the database to be backed up. To restore the entire data up to the point of the last commit, you must prepare an active log (e.g. demodb_lgat) and an archive log (e.g. demodb_lgar000). Then, transfer the backup information, active log, and archive log files created on server A to server B - the backup information, active log and archive log files must be located in a directory (e.g. /home/cubrid/temp) on server B.

Restoring the database on server B

Perform database restore by calling the cubrid restoredb utility from the folder where the backup, backup information, active log and archive log files which were transferred to server B have been stored. With the -u option, demodb is restored in the directory path from the databases.txt file:

To call the cubrid restoredb utility from a different path, specify the directory path to the backup file by using the -B option as follows:

Backing up the restored database on server B

Once the restore of the target database is complete, run the database to check if it has been properly restored. It is also recommended to restore the database again on the server B environment, for safety reasons.

Restore Database from CUBRID Manager Client

To restore a database, perform one of the followings (after login to the database):

• Click Restore Database from the toolbar.
• Right-click the database and then select Restore Database.
• Select Action -> Restore Database on the menu.

Loading data to restore database can be performed only when the database server is not running; The Restore Database menu is disabled while the database is running.

These are the options you can configure:

If you click Show backup information, you will see information associated with the backup selected:

Restore Strategy

The followings must be considered before planning and executing a database restore:

• Preparing a backup file
• Identify the directory where the backup and log files are to be stored.
• If the database has been incrementally backed up, check whether an appropriate backup file for each backup level exists.
• Check whether the backed-up CUBRID database and the CUBRID database to be backed up are the same version.
• Choosing a restore method
• Determine whether to perform a partial or full restore.
• Determine whether or not to perform a restore using incremental backup files.
• Prepare restore tools and devices available.
• Determining restore time
• Identify the point in time when the database server was stopped.
• Identify the point in time when the last backup was performed before database failure.
• Identify the point in time when the last commit was made before database failure.

Example

The following is an example of a backup and restore process, described chronologically:

1. Performs a full backup of demodb, which stopped running at 2010/8/14 04:30.
2. Performs the first incremental backup of demodb running at 2010/8/14 10:00.
3. Performs the first incremental backup of demodb running at 2010/8/14 15:00. Overwrites the first incremental backup file in step 2.
4. A system failure occurs at 2010/8/14 15:30, and the system administrator prepares the restore of demodb. Sets the restore time as 15:25, which is the time when the last commit was made before the database failure.
5. The system administrator prepares the full backup file created in Step 1 and the first incremental backup file created in Step 3, restores the demodb database up to the 15:00 time, and then prepares the active and archive logs to restore the database up to 15:25.

See also

• CUBRID Backup & Restore – Part I (Backup)
• Online Resource for CUBRID Backup and Restore
• CUBRID Automated Scripts for DB Hosting Service
• CUBRID Replication
• CUBRID Architecture
• Restoring Emergency Database Logs
• CUBRID Tutorials
• CUBRID Manual

Getting Help

This concludes the CUBRID Database Backup & Restore tutorial. If you have any questions related to CUBRID Backup & Restore, you can tweet to @cubrid or post your message on the CUBRID Forum.