Save backup manifests for snapshot backup (#232) #6180
+28
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?
Closes #6179
What is changed and how does it work?
Saves cluster manifests to external storage as part of the snapshot backup process, similar to EBS volume snapshot backups.
While EBS backups perform this step after the init job and prior to each data-plane's individual backup job (in fact each data plane will upload manifest to the same location, so only last-write-wins manifest will be backed up). For logical snapshot backup, there is no init job and there is only a single backup job that orchestrates the entire backup -- we choose to add the manifest backup step prior to the overall backup job. Similarly, this will only backup the cluster manifests from a single AZ, the control-plane AZ that performs the backup job, but this is sufficient for our use-cases.
Code changes
Tests
Side effects
Adds additional external storage requirements for snapshot backup, additional step prior to the BR process that could fail.
Related changes
Release Notes
Please refer to Release Notes Language Style Guide before writing the release note.