Solutions

MarkLogic Data Hub Service

Fast data integration + improved data governance and security, with no infrastructure to buy or manage.

Learn More

Learn

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Community

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

Company

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up

 
Knowledgebase:
Restoring from incremental backup taken on a different cluster
05 August 2019 05:35 PM

Introduction

When a database backup taken on Cluster A is restored (using incremental backup) on Cluster B, sometimes it fails with the message on the admin screen  -

The database restore has failed. Please check the server logs for details.

A quick look at the logs will show an error indicating that the backup directory does not exist, even though the backup was copied from Cluster A to Cluster B

Error: TaskManager::runTask: XDMP-FORESTRESTOREFAILED: Restore failed for forest Documents: SVC-DIROPEN: Directory open error: opendir '/tmp/backup/20180827-1607002170310/20180827/1609002389230/Forests/Documents': No such file or directory

Error: 1-forest database restore from /space/backup/20180827-1607002170310, jobid=472666486696782942 failed: XDMP-FORESTRESTOREFAILED: Restore failed for forest Documents: SVC-DIROPEN: Directory open error: opendir '/tmp/backup/20180827-1607002170310/20180827/1609002389230/Forests/Documents': No such file or directory

This happens when the backup directory structure is different between the clusters. For example, on Cluster A, the backup directory exists under /tmp/backup.

When copying the backup for restore on Cluster B, it was copied to /space/backup.

Even though the backup directory was moved to a different location, per the error logs, the restore job is looking to find it in the old location (/tmp/backup) and fails as it does not find it.

Resolution

Every incremental backup will store a reference to the location of the previous incremental backup and the very first one will store a reference to the location of the full backup. These are stored in a file by the name BackupTag.txt .It is from here that the restore job fetches the backup locations and if they still point to an older location, then incremental restore will fail.

To get past this, BackupTag.txt which is located under incremental-backup-directory/incremental-backup/Forests/forest-name/ should be edited such that the BasePath parameter reflects the current backup directory.

For example, on Cluster B, BasePath in BackupTag.txt(/space/backup/20180827-1607002170310/20180827/1609002389230/Forests/Documents) should be changed from


BasePath /tmp/backup/20180827-1607002170310  to 

BasePath /space/backup/20180827-1607002170310

This should be done on every incremental backup in the directory.

Note that the example presented in this article does not specify a separate location for incremental backups.

Further Reading

Backup Directory Structure

Notes about Backup and Restore Operations

Incremental Backup

Incremental Backup - RTO and RPO Considerations

Disaster Recovery

 

(0 vote(s))
Helpful
Not helpful

Comments (0)