[
https://issues.apache.org/jira/browse/HBASE-28882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17932901#comment-17932901
]
Vinayak Hegde commented on HBASE-28882:
---------------------------------------
[~rmdmattingly] I believe we're facing the same issue with how the backup
delete command currently works. Right now, the command takes a list of backup
IDs to delete and retrieves the backup root directory from the backup
information stored in the system. If the backup location changes, we'll
encounter the same problem.
To avoid this, shouldn't we modify the command to explicitly take the backup
root directory as an argument and use it to locate the backups, rather than
relying on backup history to determine the root directory?
Does this approach make sense, or am I overlooking something?
> 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)
