Skip to content
This repository has been archived by the owner on Nov 14, 2024. It is now read-only.

ABR3: Backup persistence #5771

Merged
merged 10 commits into from
Nov 17, 2021
Merged

ABR3: Backup persistence #5771

merged 10 commits into from
Nov 17, 2021

Conversation

gsheasby
Copy link
Contributor

Goals (and why): Persist backup metadata in the same way as in the internal backup product.

Implementation Description (bullets):

  • Add ExternalBackupPersister
  • Wiring to AtlasBackupService

Testing (What was existing testing like? What have you done to improve it?): Added ExternalBackupPersisterTest

Concerns (what feedback would you like?): Storing the immutable timestamp seems a little janky - it appears to be used during the restore process though, so it would be needed at least for back-compatibility.

Where should we start reviewing?: ExternalBackupPersister

Priority (whenever / two weeks / yesterday): today 🙏

@changelog-app
Copy link

changelog-app bot commented Nov 17, 2021

Generate changelog in changelog/@unreleased

Type

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

The AtlasBackupService will now persist backup metadata in the same way as in the internal backup product.

Check the box to generate changelog(s)

  • Generate changelog entry

Copy link
Contributor

@gmaretic gmaretic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, haven't double-checked that it matches internal logic. If it's not difficult, we could smoke test it (I guess this is the task you mentioned in standup?), but it's also ok to go ahead with this and do an integration test down the line

@@ -91,6 +89,7 @@ public static AtlasBackupService create(

private void storeBackupToken(InProgressBackupToken backupToken) {
inProgressBackups.put(backupToken.getNamespace(), backupToken);
backupPersister.storeImmutableTimestamp(backupToken);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add a todo to eventually stop doing this. We want it now for backwards compatibility, but if there is not a valid use case for it (maybe it's used to repair targeted sweep tables, haven't checked?), we should get rid of it when reasonable.

@bulldozer-bot bulldozer-bot bot merged commit 05b48e1 into develop Nov 17, 2021
@bulldozer-bot bulldozer-bot bot deleted the gs/ext-backup-persister branch November 17, 2021 16:38
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants