Avoid choosing parent snapshot newer than time of current snapshot #3619
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aneeshusa
force-pushed
the
avoid-time-travel-paradoxes-when-finding-parents
branch
from
78a1a29
to
879d563
Compare
|
A few other notes:
|
MichaelEischer
requested changes
Jan 22, 2022
Document this code review feedback I got for other contributors.
Currently, `restic backup` (if a `--parent` is not provided) will choose the most recent matching snapshot as the parent snapshot. This makes sense in the usual case, where we tag the snapshot-being-created with the current time. However, this doesn't make sense if the user has passed `--time` and is currently creating a snapshot older than the latest snapshot. Instead, choose the most recent snapshot which is not newer than the snapshot-being-created's timestamp, to avoid any time travel. Impetus for this change: I'm using restic for the first time! I have a number of existing BTRFS snapshots I am backing up via restic to serve as my initial set of backups. I initially `restic backup`'d the most recent snapshot to test, then started backing up each of the other snapshots. I noticed in `restic cat snapshot <id>` output that all the remaining snapshots have the most recent as the parent.
aneeshusa
force-pushed
the
avoid-time-travel-paradoxes-when-finding-parents
branch
from
879d563
to
058dfc2
Compare
|
Thank you for the review! |
MichaelEischer
approved these changes
Feb 5, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 does this PR change? What problem does it solve?
Currently,
restic backup(if a--parentis not provided)will choose the most recent matching snapshot as the parent snapshot.
This makes sense in the usual case,
where we tag the snapshot-being-created with the current time.
However, this doesn't make sense if the user has passed
--timeand is currently creating a snapshot older than the latest snapshot.
Instead, choose the most recent snapshot
which is not newer than the snapshot-being-created's timestamp,
to avoid any time travel.
Impetus for this change:
I'm using restic for the first time!
I have a number of existing BTRFS snapshots
I am backing up via restic to serve as my initial set of backups.
I initially
restic backup'd the most recent snapshot to test,then started backing up each of the other snapshots.
I noticed in
restic cat snapshot <id>outputthat all the remaining snapshots have the most recent as the parent.
Was the change previously discussed in an issue or on the forum?
Not AFAIK. I looked through previous issues on GitHub and the forum,
and there are a number of issues which discuss making parent selection smarter in general,
but I did not see any that are specifically about the interaction of parent selection with time.
Since it was a fairly straightforward fix, opted to open a PR directly
but happy to defer to an issue if discussion is needed.
Checklist
changelog/unreleased/that describes the changes for our users (see template).gofmton the code in all commits.