Restore
Steps to restore a single-node Tamr Core deployment from a source instance to a destination instance.
Source instance: The instance that you backed up, and that you use to restore.
Destination instance: The instance that you intend to replace with a backup file by restoring.
Important: Do not try to use a server snapshot as a substitute for a Tamr Core application backup. Server snapshots do not provide the correct backups of Tamr Core configuration during a restore. In addition, if Tamr Core is running when you take a server snapshot a corrupt HBase configuration can result if you restore from the snapshot. Instead, take Tamr Core application backups before introducing any changes.
Before You Begin
Important: Before you can restore Tamr Core, you must verify that your destination instance is first factory reset. For more information, consult the Tamr Help Center.
- Verify that you have an existing Tamr Core installation running identical major and minor version. See Installation. The patch version does not need to match exactly. For information about patches, see Upgrading Tamr Core.
- Verify that you have a backup file created on the source instance. See Backup and Get all backups.
- Verify that the destination instance can read the backup files, either on the localdisk or in a location that is a subdirectory of
TAMR_UNIFY_BACKUP_URI
. - Verify that the Tamr Core functional user, such as
tamr
, has read and write permissions on theTAMR_UNIFY_BACKUP_URI
for the destination instance. - If the source of the backup file is a single-node instance and the destination is a scale-out instance on GCP, you must set
TAMR_STORAGE_DRIVER_DATA_STORE_BACKUP_ENABLED
totrue
before you run the backup. After you restore, set this parameter tofalse
. See Selecting a Backup and Restore Approach and Migrating to a Scale-out GCP Instance.
Notes:
- During the restore operation, Tamr Core is in a read-only state; no other user actions or changes can be performed.
- Restoring Tamr Core from a backup deletes all data in the destination instance and automatically restarts Tamr Core.
- Restoring Tamr Core from a backup resets the password for the "system" user to its default value. Be sure to follow the additional steps required for changing the password of the "system" user. See Editing User Passwords. The "admin" password is restored.
Restoring from a Backup
Before you begin, ensure that you have met the requirements listed above.
To restore an instance from a backup
- On the destination instance, restore Tamr Core from a backup by reading a backup specified in the
POST
body. Run:
POST /v1/instance/restore
Tamr Core is unavailable during a restore process. See About the restore process. - Poll for the status of the restore operation until
status.state=SUCCEEDED
is returned. Run
GET /v1/instance/restore. - Change the password for the "system" user. See Editing User Passwords.
Restoring from Backup on Another Instance
Once you create a backup on the source instance and then restore from it on one destination instance, you can also restore from the same backup file on another destination instance. Two situations are possible and they depend on the location in which the backup files are stored.
- If you are using a distributed filesystem to store the backup files, you can restore from the backup to any destination instance without having to physically transfer backup files.
- If you are using a server filesystem, create a TAR of the backup so you only have to transfer one file, copy this backup file to the destination instance inside of the
TAMR_UNIFY_BACKUP_URI
, extract the TAR file to the correct location, and trigger a restore process.
Restoring from Backup without Elastic Search
If backup of Elastic Search was disabled (TAMR_UNIFY_BACKUP_ES=false) for the target of the restore, Elastic Search must be reindexed after the steps listed above. The following cURL commands can be run to initiate the required reindexing tasks.
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: BasicCreds <creds>' '<host>:<port>/api/reindex/all-datascale'
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: BasicCreds <creds>' '<host>:<port>/api/reindex/all-humanscale'
These reindex commands create a number of jobs which you can track on the Jobs page in the UI. When those jobs all complete successfully, the restoration is complete.
Updated almost 2 years ago