Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backupccl: disallow restore of backups older than the minimum supported binary version #98597

Merged
merged 1 commit into from
Mar 17, 2023

Conversation

adityamaru
Copy link
Contributor

@adityamaru adityamaru commented Mar 14, 2023

As outlined in https://www.cockroachlabs.com/docs/v22.2/restoring-backups-across-versions.html,
we do not support restoring backups outside our versioning policy window. This
patch enforces the policy by ensuring that the manifest's version is greater
than equal to the minimum supported binary version that the current binary
can interoperate with.

Additionally, this patch introduces an UNSAFE_RESTORE_INCOMPATIBLE_VERSION option
that can be used to skip compatability checks and forcefully restore backups taken
outside our compatability window. This has primarily been added to allow development
branches to restore backups taken on release branches, but can be used as a break
glass option where restoring a backup is absolutely necessary. No guarantees are
made about the correctness of the restore when using this option.

Release note (sql change): Disallow the restore of backups taken on a cluster version
that is older than the minimum binary version the current cluster can interoperate with.
This will be described in an updated version of the policy
outlined in https://www.cockroachlabs.com/docs/v22.2/restoring-backups-across-versions.html.

Fixes: #94295

@adityamaru adityamaru requested review from dt and msbutler March 14, 2023 17:21
@adityamaru adityamaru requested a review from a team as a code owner March 14, 2023 17:21
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Copy link
Collaborator

@msbutler msbutler left a comment

Choose a reason for hiding this comment

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

looks good! left mostly nits/clarification qs

pkg/ccl/backupccl/backup_test.go Show resolved Hide resolved
pkg/ccl/backupccl/backup_test.go Outdated Show resolved Hide resolved
pkg/ccl/backupccl/backup_test.go Show resolved Hide resolved
pkg/ccl/backupccl/restore_planning.go Outdated Show resolved Hide resolved
return errors.AssertionFailedf("minimum restoreable version %s is less than the dev offset",
minimumRestorableVersion)
}
minimumRestorableVersion.Major -= clusterversion.DevOffset
Copy link
Collaborator

Choose a reason for hiding this comment

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

could you clarify in a comment why this decrement is necessary? my read of the code is that BinaryMinSupportedVersion() always returns v22_2, but maybe i misread things?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When running in a development branch as defined by this bool -

var developmentBranch = !envutil.EnvOrDefaultBool("COCKROACH_TESTING_FORCE_RELEASE_BRANCH", false) ||
, all versions including the BinaryMinSupportedVersion are offset by DevOffset. If we didn't decrement the MinimumBinaryVersion by the dev offset then a backup taken on say 22.2 would not be restoreable into our branch because our MinimumBinaryVersion is 1000022.2. Since 22.2 is far less than this number we would reject the restore.

This has however got me thinking that the condition we decrement the BinaryMinSupportedVersion should not be IsRelease() but instead the developmentBranch bool linked above.

Copy link
Collaborator

Choose a reason for hiding this comment

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

let me know if you want company in the "why do we have both a IsRelease() and developmentBranch" rabbit hole :)

Copy link
Contributor Author

@adityamaru adityamaru Mar 16, 2023

Choose a reason for hiding this comment

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

The code has changed so that we don't need to perform this DevOffset math. But to answer your question when we're on a 'development branch" all versions including BinaryMinSupportedVersion are offset by a million. You can read up more here, it explains it much better than I will be able to -

// If this is a dev branch, we offset every version +1M major versions into

@adityamaru adityamaru force-pushed the enforce-restore-version branch from a8fd5a7 to 6f9fecc Compare March 16, 2023 19:26
@adityamaru adityamaru requested a review from a team as a code owner March 16, 2023 19:26
@adityamaru adityamaru requested a review from msbutler March 16, 2023 19:29
// This is the "cluster" version that does not change between patch releases
// but rather just tracks migrations run. If the backup is more migrated
// than this cluster, then this cluster isn't ready to restore this backup.
if currentActiveVersion.Less(v) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

note, we don't skip this check even if unsafeRestoreIncompatibleVersion is true. That seemed correct to me because we have always been rejecting more migrated backups even before we enforced our new policy.

…ed binary version

As outlined in https://www.cockroachlabs.com/docs/v22.2/restoring-backups-across-versions.html,
we do not support restoring backups outside our versioning policy window. This
patch enforces the policy by ensuring that the manifest's version is greater
than equal to the minimum supported binary version that the current binary
can interoperate with.

Additionally, this patch introduces an `UNSAFE_RESTORE_INCOMPATIBLE_VERSION` option
that can be used to skip compatability checks and forcefully restore backups taken
outside our compatability window. This has primarily been added to allow development
branches to restore backups taken on release branches, but can be used as a break
glass option where restoring a backup is absolutely necessary. No guarantees are
made about the correctness of the restore when using this option.

Release note (sql change): Disallow the restore of backups taken on a cluster version
that is older than the minimum binary version the current cluster can interoperate with.
This will be described in an updated version of the policy
outlined in https://www.cockroachlabs.com/docs/v22.2/restoring-backups-across-versions.html.

Fixes: cockroachdb#94295
@adityamaru adityamaru force-pushed the enforce-restore-version branch from 6f9fecc to c39e5e4 Compare March 16, 2023 20:41
# More investigation required.


new-cluster name=s4 share-io-dir=s1 allow-implicit-access beforeVersion=Start22_2 disable-tenant
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The test relied on a cluster not having run 22.2 migrations. This is no longer relevant as our min binary version is 22.2 which means all 22.2 migrations have indeed run.

Copy link
Collaborator

Choose a reason for hiding this comment

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

sad to see this noble subtest go :'(

but it's for the better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was a 💯 test, it will live on in release-22.2 for eternity

ForceTenantID Expr
SchemaOnly bool
VerifyData bool
EncryptionPassphrase Expr
Copy link
Member

Choose a reason for hiding this comment

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

sometimes I question gofmt's insistence on vertical alignment.

@adityamaru
Copy link
Contributor Author

TFTR!

bors r=msbutler,dt

@craig
Copy link
Contributor

craig bot commented Mar 17, 2023

Build succeeded:

@cucaroach
Copy link
Contributor

Is it possible this breaking a bunch of roachtests? See #98918

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

backupccl: reject restores of backups greater than the clusters minimum supported binary version
5 participants