Vertica Analytics Platform Version 9.2.x Documentation
Restoring a Database from a Full Backup
You can restore a full database backup to the database that was backed up or to an alternate cluster with the same architecture. One reason to restore to an alternate cluster is to set up a test cluster on which to investigate a problem in production.
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 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 nodes 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.
You can also restore a full backup to a different database than the one you backed up. See Restoring a Database to an Alternate Cluster.
When you restore 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 can cause data corruption.
Restoring the Most Recent Backup
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 vbr restore task with the configuration file. If your password configuration file does not contain the database superuser password,
vbr prompts you to enter it.
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!
If you saved multiple backups, you can specify an archive to restore. To list the archives that exist to choose one to restore, use the
vbr --listbackup task, with a specific configuration file. See Viewing Backups.
To restore from an archive, add the
--archive parameter to the command line. The value is the date_timestamp suffix of the directory name that identifies the archive to restore. For example:
$ vbr --task restore --config-file fullbak.ini --archive=20121111_205841
--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.
Was this topic helpful?