[
https://issues.apache.org/jira/browse/HBASE-28882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved HBASE-28882.
----------------------------------
Fix Version/s: 3.0.0-beta-2
2.6.2
Resolution: Fixed
Pushed to branch-2.6+. Thanks [~rmdmattingly] for the fix and [~dieterdp_ng]
for the reviews.
> Backup restores are broken if the backup has moved locations
> ------------------------------------------------------------
>
> Key: HBASE-28882
> URL: https://issues.apache.org/jira/browse/HBASE-28882
> Project: HBase
> Issue Type: Bug
> Components: backup&restore
> Affects Versions: 3.0.0-beta-1, 4.0.0-alpha-1, 2.7.0, 2.6.1
> Reporter: Ray Mattingly
> Assignee: Ray Mattingly
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0-beta-2, 2.6.2
>
>
> My company runs a few hundred HBase clusters. We want to take backups
> everyday in one public cloud region, and then use said cloud's native
> replication solution to "backup our backups" in a secondary region. This is
> how we plan for region-wide disaster recovery.
> This system should work, but doesn't because of the way that BackupManifests
> are constructed.
> Backing up a bit (no pun intended): when we replicate backups verbatim, the
> manifest file continues to point to the original backup root. This shouldn't
> matter, because when taking a restore one passes a RestoreRequest to the
> RestoreTablesClient — and this RestoreRequest includes a BackupRootDir field.
> This works as you would expect initially, but eventually we build a
> BackupManifest that fails to interpolate this provided root directory and,
> instead, falls back to what it finds on disk in the backup (which would point
> back to the primary backup location, even if reading a replicated backup).
> To fix this, I'm proposing that we properly interpolate the request's root
> directory field when building BackupManifests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
