Revive from a restore point

After you've saved restore point to an archive, you can use those restore points to revive a terminated or down database. The revived database is restored to the state at which the restore point was saved.

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
-----------------+----------------------------+-------+--------------------------------------
 vertica-restore | 2023-11-30 14:10:31.038289 | 1     | 4ee4119b-802c-4bb4-94b0-061c8748b602
 vertica-restore | 2023-11-10 14:10:28.717667 | 2     | bdaa4764-d8aa-4979-89e5-e642cc58d972

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-seperated list of hosts to which the database is revived. This can be a different number of hosts than the number of hosts 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.