Revive from a restore point

After you've saved a full-database restore point to an archive, you can use that restore point to revive a terminated or down database on a cluster with the same number of nodes as the database had when the restore point was saved. Full-database restore to a database with a different node count is not supported. The revived database is restored to the state at which the restore point was saved. You cannot revive a database from an object-level restore point. To restore objects from an object-level restore point, use RESTORE FROM ARCHIVE.

To revive your database from a restore point, you use the revive_db admintools command. This command requires that you specify the restore point's archive name and either its index in the archive or its object ID. If the database is down and you need to confirm the restore point details, you can use the show_restore_points admintools command to list all restore points and their attributes. You must provide the database name and the communal storage location's address and credentials, and optionally specify the archive from which to list restore points and whether the output is in text or JSON format:

$ admintools -t show_restore_points --database = vertica_db \\
    --communal-storage-location = s3://mybucket \\
    --communal-storage-params = auth_params.conf \\
    --output-format = text

    archive     | timestamp                  | index | id                                   | includes_database | objects_rules
-----------------+----------------------------+-------+--------------------------------------+-------------------+----------------------
 vertica-restore | 2026-08-30 14:10:31.038289 | 1     | 4ee4119b-802c-4bb4-94b0-061c8748b602 | t                 |
 object_backup   | 2026-08-10 14:10:28.717667 | 2     | bdaa4764-d8aa-4979-89e5-e642cc58d972 | f                 | INCLUDE SCHEMA store

Revive a database from a restore point

The revive_db admintools command lets you revive a database to either the last synced state of the database in communal storage or the state at which a restore point was saved. When using the revive_db command to revive from a restore point, you must specify the following arguments:

-s HOSTS, --hosts=HOSTS

Comma-separated list of hosts to which the database is revived. The number of hosts must match the number of nodes that were in the database when the restore point was saved.

--communal-storage-location=COMMUNAL_STORAGE_LOCATION

Location of the communal storage that holds the restore points.

-x COMMUNAL_STORAGE_PARAMS, --communal-storage-params=COMMUNAL_STORAGE_PARAMS

Location of the communal storage parameter file.

-d DBNAME, --database=DBNAME

Name of the database to be revived.

--restore-point-archive=RESTORE_POINT_ARCHIVE

Name of the archive that holds the restore point from which to revive.

[ --restore-point-id=RESTORE_POINT_ID | --restore-point-index=RESTORE_POINT_INDEX ]

A unique identifier of the restore point from which to revive, either the restore point's object ID or its index in the archive.

For example, the following revive_db command revives the vertica_db database using the restore point with index 1 in the vertica-restore archive:

$ admintools -t revive_db -s host-list \\
    --communal-storage-location = s3://mybucket \\
    --communal-storage-params = auth_params.conf \\
    -d vertica_db
    --restore-point-archive = `vertica-restore`
    --restore-point-index = 1

The Vertica version of the revived database must be the same as or newer than the version of the database when the restore point was saved. After a database is revived, any restore point that was saved using a Vertica version newer than the version of the revived database will be invalidated. You can remove the invalidated restore points from the database using the REMOVE RESTORE POINT FROM ARCHIVE statement.

The revive operation preserves existing archives, but their configuration, including restore point limits, are rolled back to their state when the restore point was saved. If an archive didn't exist at the time of the restore point to which the database was revived, that archive is revived with default configuration settings—no restore point limit and dbadmin as owner.