Database Restore

A database restore is the procedure of restoring the database to its state at a certain point in time by using the backup files, active logs and archive logs which have been created in an environment of the same CUBRID version. To perform a database restore, use the cubrid restoredb utility or the CUBRID Manager.

The cubrid restoredb utility (restordb.exe in Windows) recovers the database from the database backup by using the information written to all the active and archive logs since the execution of the last backup.

Syntax

cubrid restoredb [ options ] database_name

[ options ]

-d | -B | -l | -p | -o | -u |

--up-to-date | --backup-file-path | --level | --partial-recovery | --output-file | --use-database-location-path | --list

• cubrid : An integrated utility for the CUBRID service and database management.
• restoredb : A command for recovery of the specified database. For a successful recovery, you must prepare backup files, active log files and archive log files. This command can be performed only in standalone mode.
• options : A short name option starts with a single dash (-) while a full name option starts with a double dash (--). This option is case sensitive.
• database_name : Specifies the name of the database to be recovered.

Return Value

•  0 : Success
•  Non-zero : Failure

Option

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

Option	Description
-d --up-to-date	Directly sets the time to backup the database or specifies the backuptime keyword.
-B --backup-file-path	Specifies the directory pathname or device name where backup files are to be located.
-l --level	Sets the recovery level to 0, 1 or 2. The default value is a full recovery (0).
-p --partial-recovery	Performs a partial recovery.
-o --output-file	Specifies the name of the file where recovery information is to be displayed.
-u --use-database-location-path	Recovers the database to the path specified in the database location file (databases.txt).
--list	Displays information on backup volumes of the database on the screen.

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.

cubrid restoredb demodb

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-2008: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.

cubrid restoredb -d 14-10-2008:14:10:00 demodb

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.

cubrid restoredb -d backuptime demodb

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.

cubrid restoredb -B /home/cubrid/backup demodb

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.

cubrid restoredb -B . demodb

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. For more information on backup levels, see Increment Backup.

cubrid restoredb -l 1 demodb

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.

cubrid restoredb -p demodb

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

***********************************************************

Log Archive /home/cubrid/test/log/demodb_lgar002

 is needed to continue normal execution.

   Type

   -  0 to quit.

   -  1 to continue without present archive. (Partial recovery)

   -  2 to continue after the archive is mounted/loaded. 

   -  3 to continue after changing location/name of archive.

***********************************************************

• Option 0 : An administrator enters 0 to stop the recovery.
• Option 1 : An administrator enters 1 to perform a partial recovery without log files.
• Option 2 : An administrator enters 2 to perform a recovery after moving archive logs to the current device.
• Option 3 : An administrator enters 3 after changing a log location to resume a restoration.

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.

cubrid restoredb -o info_restore demodb

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.

cubrid restoredb -u demodb

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

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

cubrid restoredb --list demodb

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.

*** BACKUP HEADER INFORMATION ***

Database Name: /local1/testing/demodb

 DB Creation Time: Mon Oct 1 17:27:40 2008

         Pagesize: 4096

Backup Level: 1 (INCREMENTAL LEVEL 1)

        Start_lsa: 513|3688

         Last_lsa: 513|3688

Backup Time: Mon Oct 1 17:32:50 2008

 Backup Unit Num: 0

Release: 8.1.0

     Disk Version: 8

Backup Pagesize: 4096

Zip Method: 0 (NONE)

        Zip Level: 0 (NONE)

Previous Backup level: 0 Time: Mon Oct 1 17:31:40 2008

(start_lsa was -1|-1)

Database Volume name: /local1/testing/demodb_vinf

     Volume Identifier: -5, Size: 308 bytes (1 pages)

Database Volume name: /local1/testing/demodb

     Volume Identifier: 0, Size: 2048000 bytes (500 pages)

Database Volume name: /local1/testing/demodb_lginf

     Volume Identifier: -4, Size: 165 bytes (1 pages)

Database Volume name: /local1/testing/demodb_bkvinf

     Volume Identifier: -3, Size: 132 bytes (1 pages)

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. Therefore, to recover the database in the example, you must prepare backup files for backup levels 0 and 1.