2021-11-20 15:48:22 +00:00
|
|
|
Enhancement: Stricter repository lock handling
|
2021-11-14 16:52:41 +00:00
|
|
|
|
2023-01-08 14:34:30 +00:00
|
|
|
Previously, restic commands kept running even if they failed to refresh their
|
|
|
|
|
locks in time. This could be a problem e.g. in case the client system running
|
|
|
|
|
a backup entered the standby power mode while the backup was still in progress
|
|
|
|
|
(which would prevent the client from refreshing its lock), and after a short
|
|
|
|
|
delay another host successfully runs `unlock` and `prune` on the repository,
|
|
|
|
|
which would remove all data added by the in-progress backup. If the backup
|
|
|
|
|
client later continues its backup, even though its lock had expired in the
|
|
|
|
|
meantime, this would lead to an incomplete snapshot.
|
2021-11-14 16:52:41 +00:00
|
|
|
|
2023-01-08 14:34:30 +00:00
|
|
|
To address this, lock handling is now much stricter. Commands requiring a lock
|
|
|
|
|
are canceled if the lock is not refreshed successfully in time. In addition,
|
|
|
|
|
if a lock file is not readable restic will not allow starting a command. It may
|
|
|
|
|
be necessary to remove invalid lock files manually or use `unlock --remove-all`.
|
|
|
|
|
Please make sure that no other restic processes are running concurrently before
|
|
|
|
|
doing this, however.
|
2021-11-20 15:48:22 +00:00
|
|
|
|
2021-11-14 16:52:41 +00:00
|
|
|
https://github.com/restic/restic/issues/2715
|
|
|
|
|
https://github.com/restic/restic/pull/3569
|
