Restoring Full Database Backups
To restore a full database backup, you must verify that:
- The database is DOWN. You cannot restore a full backup when the database is running.
- All of the backup hosts are UP and available.
- The backup directory exists and contains the backups from which to restore the data.
- The cluster to which you are restoring the backup has:
- The same number of hosts as the one used to create the backup
- The same architecture (Enterprise Mode or Eon Mode) as the one used to create the backup
- Identical node names
-
The target database must already exist on the cluster to which you are restoring data.
-
Database can be completely empty, without any data or schema.
-
The database name must match the name in the backup
-
All of the node names in the database must match the names of the nodes in the configuration file.
-
- The user performing the restore is the database administrator.
- If you are restoring an Eon Mode database, you have met the Requirements for Eon Mode Databases.
You can use only a full database backup to restore a complete database. If you have saved multiple backup archives, you can restore from either the last backup or a specific archive.
Restoring from a full database backup injects the OIDs from each backup into the restored catalog of the full database backup. The catalog also receives all archives. Additionally, the OID generator and current epoch are set to the current epoch.
Important: When restoring an Eon Mode database, the communal storage remains in its original location even if you restore into a new database. Do not restart the original database; running two databases against the same communal storage is an error.
Restoring the Most-Recent Backup
To perform a full database restore, the cluster must be DOWN. Usually, when a node or cluster is DOWN, you want to return the cluster to its most-recent state. Doing so requires restoring a full database backup. You can restore any full database backup from the archive by identifying the name in the configuration file.
To restore from the most recent backup, use the configuration file used to create the backup, specifying vbr with the --task restore. If your password configuration file does not contain the database superuser password, the utility prompts you to enter it at run time.
The following example shows how you can use the db.ini configuration file for restoration:
> vbr --task restore --config-file db.ini
Copying...
1871652633 out of 1871652633, 100%
All child processes terminated successfully.
restore done!
You can restore a backup only to the database from which it was taken.
Restoring an Archive
If you saved multiple backups, you can specify a specific archive to restore. To list the archives that exist to choose one to restore, use the vbr --listbackup task, with a specific configuration file.
To restore from one of several archives:
Log in using the database administrator's account.
Invoke the utility with the --task restore command:
- Include the configuration file with which you created the backup.
- Next, add the file name with the
--archiveparameter with the date_timestamp suffix of the directory name, which identifies the archive to restore.
For example:
> vbr --task restore --config-file fullbak.ini --archive=20121111_205841The vbr utility restores the backup.
The --archive parameter identifies the archive created on 11-11-2012 (_archive20121111), at time 205841 (20:58:41). You need specify only the _archive suffix, because the configuration file identifies the backup name of the subdirectory, and the OID identifier indicates the backup is an archive.
Restore Failures in Eon Mode
When a restore operation fails, vbr can leave extra files in the communal storage location. Because communal storage is in S3, those extra files cost you money. To remove them, restart the database and call CLEAN_COMMUNAL_STORAGE with an argument of true.
