2
2
mirror of https://github.com/octoleo/restic.git synced 2024-11-25 14:17:42 +00:00

changelog: Correct and slightly polish some unreleased changelog files

This commit is contained in:
Leo R. Lundgren 2021-02-14 00:57:54 +01:00
parent 917f5b910a
commit 4b5ca1e914
32 changed files with 187 additions and 164 deletions

View File

@ -1,9 +1,10 @@
Bugfix: Make mount not create missing mount point
Bugfix: Make `mount` not create missing mount point directory
When specifying a non-existent directory as mount point for the mount
command, restic used to create the directory automatically. This has now
changed such that restic instead gives an error when the directory for the
mount point doesn't exist.
When specifying a non-existent directory as mount point for the `mount`
command, restic used to create the specified directory automatically.
This has now changed such that restic instead gives an error when the
specified directory for the mount point does not exist.
https://github.com/restic/restic/issues/1681
https://github.com/restic/restic/pull/3008

View File

@ -1,8 +1,8 @@
Bugfix: Ignore 'no data available' error during backup
Bugfix: Ignore `no data available` filesystem error during backup
restic failed to backup files on some filesystems, for example certain configurations
of CIFS on Linux, which return a "no data available" error when reading extended
attributes. These errors are now ignored.
Restic was unable to backup files on some filesystems, for example certain
configurations of CIFS on Linux which return a `no data available` error
when reading extended attributes. These errors are now ignored.
https://github.com/restic/restic/issues/1800
https://github.com/restic/restic/pull/3034

View File

@ -1,8 +1,8 @@
Enhancement: Allow specifying percentage in check's --read-data-subset
Enhancement: Allow specifying percentage in `check --read-data-subset`
We've enhanced the command-line option --read-data-subset to also accept a
percentage. This will check the given percentage of pack files which are
randomly selected on each run.
We've enhanced the `check` command's `--read-data-subset` option to also accept
a percentage (e.g. `2.5%` or `10%`). This will check the given percentage of
pack files (which are randomly selected on each run).
https://github.com/restic/restic/issues/2186
https://github.com/restic/restic/pull/3038

View File

@ -1,9 +1,9 @@
Enhancement: Improve handling of permanent backend errors
Enhancement: Report permanent/fatal backend errors earlier
When encountering errors in reading from or writing to storage backends,
restic retries the failing operation up to nine times (for a total of ten
attempts). It used to retry all backend operations, but now detects some
permanent error conditions so it can report fatal errors earlier.
permanent error conditions so that it can report fatal errors earlier.
Permanent failures include local disks being full, SSH connections
dropping and permission errors.

View File

@ -1,20 +1,21 @@
Enhancement: support Alibaba/Aliyun OSS with S3 backend
Enhancement: Add Alibaba/Aliyun OSS support in the `s3` backend
We've added a new flag to the s3 backend `s3.bucket-lookup` which can
be set to these 3 values:
A new extended option `s3.bucket-lookup` has been added to support
Alibaba/Aliyun OSS in the `s3` backend. The option can be set to one
of the following values:
- `auto` - existing behaviour
- `dns` - use DNS style bucket access
- `path` - use path style bucket access
- `auto` - Existing behaviour
- `dns` - Use DNS style bucket access
- `path` - Use path style bucket access
To make the s3 backend work with Alibaba/Aliyun OSS you must set
To make the `s3` backend work with Alibaba/Aliyun OSS you must set
`s3.bucket-lookup` to `dns` and set the `s3.region` parameter. For
example:
restic -o s3.bucket-lookup=dns -o s3.region=oss-eu-west-1 -r s3:https://oss-eu-west-1.aliyuncs.com/bucketname init
Note that s3.region must be set otherwise the minio SDK tries to look
it up and it seems that Alibaba doesn't support that properly.
Note that `s3.region` must be set, otherwise the MinIO SDK tries to
look it up and it seems that Alibaba doesn't support that properly.
https://github.com/restic/restic/issues/2528
https://github.com/restic/restic/pull/2535

View File

@ -1,8 +1,9 @@
Bugfix: Use correct directory owner in fuse mount
Bugfix: Report the correct owner of directories in FUSE mounts
Restic 0.10.0 changed the fuse mount to always report the current user
as the owner of directories within the fuse mount, which is incorrect.
We have changed this back to use the correct owner of a directory.
Restic 0.10.0 changed the FUSE mount to always report the current user
as the owner of directories within the FUSE mount, which is incorrect.
This is now changed back to reporting the correct owner of a directory.
https://github.com/restic/restic/issues/2563
https://github.com/restic/restic/pull/3141

View File

@ -1,26 +1,30 @@
Bugfix: Make backup and tag commands separate tags by comma
Bugfix: Make `backup` and `tag` commands separate tags by comma
Running `restic backup --tag foo,bar` previously created snapshots with one
single tag containing a comma ("foo,bar") instead of two tags ("foo", "bar").
Similarly, the `tag` command's --set, --add and --remove options would treat
"foo,bar" as one tag instead of two tags. This was inconsistent with other
commands and often unexpected when one intended "foo,bar" to mean two tags.
single tag containing a comma (`foo,bar`) instead of two tags (`foo`, `bar`).
To be consistent in all commands, restic now interprets "foo,bar" to mean two
separate tags ("foo" and "bar") instead of one tag ("foo,bar") everywhere,
Similarly, the `tag` command's `--set`, `--add` and `--remove` options would
treat `foo,bar` as one tag instead of two tags. This was inconsistent with
other commands and often unexpected when one intended `foo,bar` to mean two
tags.
To be consistent in all commands, restic now interprets `foo,bar` to mean two
separate tags (`foo` and `bar`) instead of one tag (`foo,bar`) everywhere,
including in the `backup` and `tag` commands.
NOTE: This change might result in unexpected behavior in cases where you use
the `forget` command and filter on tags like "foo,bar". Snapshots previously
the `forget` command and filter on tags like `foo,bar`. Snapshots previously
backed up with `--tag foo,bar` will still not match that filter, but snapshots
saved from now on will match that filter.
To replace "foo,bar" tags with "foo" and "bar" tags in old snapshots, you can
first generate a list of the relevant snapshots using a command like
`restic snapshots --json --quiet | jq '.[] | select(contains({tags: ["foo,bar"]})) | .id'`
, and then use `restic tag --set foo --set bar snapshotID [...]` to set the new
tags. Please adjust the commands to real tag names and any additional tags,
as well as the list of snapshots to process.
To replace `foo,bar` tags with `foo` and `bar` tags in old snapshots, you can
first generate a list of the relevant snapshots using a command like:
restic snapshots --json --quiet | jq '.[] | select(contains({tags: ["foo,bar"]})) | .id'
and then use `restic tag --set foo --set bar snapshotID [...]` to set the new
tags. Please adjust the commands to include real tag names and any additional
tags, as well as the list of snapshots to process.
https://github.com/restic/restic/issues/2688
https://github.com/restic/restic/pull/2690

View File

@ -3,7 +3,8 @@ Enhancement: Configurable progress reports for non-interactive terminals
The `backup`, `check` and `prune` commands never printed any progress
reports on non-interactive terminals. This behavior is now configurable
using the `RESTIC_PROGRESS_FPS` environment variable. Use for example a
value of `1` for an update per second or `0.01666` for an update per minute.
value of `1` for an update every second, or `0.01666` for an update every
minute.
The `backup` command now also prints the current progress when restic
receives a `SIGUSR1` signal.

View File

@ -1,5 +1,5 @@
Bugfix: Make cat command respect --no-lock
Bugfix: Make the `cat` command respect the `--no-lock` option
Restic cat would not respect the --no-lock flag, it now does.
The `cat` command would not respect the `--no-lock` flag. This is now fixed.
https://github.com/restic/restic/issues/2739

View File

@ -1,12 +1,13 @@
Enhancement: Backup options --files-from-verbatim and --files-from-raw
Enhancement: Add `backup` options `--files-from-{verbatim,raw}`
The new backup options `--files-from-verbatim` and `--files-from-raw`
read a list of files to back up from a file. Unlike the existing `--files-from`,
these options do not interpret the listed filenames as glob patterns;
whitespace in filenames is preserved as-is and no pattern expansion is done.
The new `backup` options `--files-from-verbatim` and `--files-from-raw` read a
list of files to back up from a file. Unlike the existing `--files-from`
option, these options do not interpret the listed filenames as glob patterns;
instead, whitespace in filenames is preserved as-is and no pattern expansion is
done. Please see the documentation for specifics.
These new options are recommended over `--files-from` when generating the
list of files to back up from a script. Please see the documentation for specifics.
These new options are highly recommended over `--files-from`, when using a
script to generate the list of files to back up.
https://github.com/restic/restic/issues/2944
https://github.com/restic/restic/issues/3013

View File

@ -1,8 +1,8 @@
Enhancement: Allow usage of deprecated S3 ListObjectsV1 API
Enhancement: Allow usage of deprecated S3 `ListObjects` API
Some S3 API implementations, e.g. Ceph before version 14.2.5, have a broken
`ListObjectsV2` implementation which cause problems for restic when using their
API endpoints. When a broken server implementation is used, restic prints
`ListObjectsV2` implementation which causes problems for restic when using
their API endpoints. When a broken server implementation is used, restic prints
errors similar to the following:
List() returned error: Truncated response should have continuation token set
@ -12,7 +12,7 @@ endpoint by setting the `s3.list-objects-v1` extended option, for instance:
restic -o s3.list-objects-v1=true snapshots
This option may be removed in future versions of restic.
Please note that this option may be removed in future versions of restic.
https://github.com/restic/restic/issues/3083
https://github.com/restic/restic/pull/3085

View File

@ -1,7 +1,10 @@
Bugfix: --use-fs-snapshot now works on windows/386
Bugfix: The `--use-fs-snapshot` option now works on windows/386
Restic failed to create VSS snapshots on windows/386 with the following error:
"GetSnapshotProperties() failed: E_INVALIDARG (0x80070057)". This is fixed now.
GetSnapshotProperties() failed: E_INVALIDARG (0x80070057)
This is now fixed.
https://github.com/restic/restic/issues/3087
https://github.com/restic/restic/pull/3090

View File

@ -1,17 +1,17 @@
Change: Deleting files on Google Drive now moves them to the trash
When deleting files on Google Drive via an rclone backend, restic used
to bypass the trash folder and required using the `-o rclone.args`
option to enable the trash folder. This ensured that deleted files in
Google Drive were not kept indefinitely in the trash folder. Since
Google Drive's trash retention policy changed to deleting trashed files
after 30 days, this is no longer needed.
When deleting files on Google Drive via the `rclone` backend, restic used to
bypass the trash folder required that one used the `-o rclone.args` option to
enable usage of the trash folder. This ensured that deleted files in Google
Drive were not kept indefinitely in the trash folder. However, since Google
Drive's trash retention policy changed to deleting trashed files after 30 days,
this is no longer needed.
Restic now leaves it up to rclone and its configuration to use or not
use the trash folder when deleting files. The default is to use the
trash folder, as of rclone 1.53.2. To re-enable the restic 0.11 behavior,
set the `RCLONE_DRIVE_USE_TRASH` environment variable or change the
rclone configuration. See the rclone documentation for details.
Restic now leaves it up to rclone and its configuration to use or not use the
trash folder when deleting files. The default is to use the trash folder, as
of rclone 1.53.2. To re-enable the restic 0.11 behavior, set the
`RCLONE_DRIVE_USE_TRASH` environment variable or change the rclone
configuration. See the rclone documentation for more details.
https://github.com/restic/restic/issues/3095
https://github.com/restic/restic/pull/3102

View File

@ -1,9 +1,9 @@
Bugfix: Do not require gs bucket permissions when running init
Bugfix: Do not require gs bucket permissions when running `init`
Restic used to require bucket level permissions for the gs backend
Restic used to require bucket level permissions for the `gs` backend
in order to initialize a restic repository.
It now allows a gs service account to initialize a repository if the
It now allows a `gs` service account to initialize a repository if the
bucket does exist and the service account has permissions to write/read
to that bucket.

View File

@ -1,11 +1,11 @@
Enhancement: Support further environment variables for swift authentication
Enhancement: Support additional environment variables for Swift authentication
The swift backend now supports the following additional environment variables
to pass authentication details to restic: `OS_USER_ID`, `OS_USER_DOMAIN_ID`,
`OS_PROJECT_DOMAIN_ID` and `OS_TRUST_ID`.
The `swift` backend now supports the following additional environment variables
for passing authentication details to restic:
`OS_USER_ID`, `OS_USER_DOMAIN_ID`, `OS_PROJECT_DOMAIN_ID` and `OS_TRUST_ID`
Depending on the openrc configuration file these might be required when the
user and project domains differ.
Depending on the `openrc` configuration file these might be required when the
user and project domains differ from one another.
https://github.com/restic/restic/issues/3147
https://github.com/restic/restic/pull/3158

View File

@ -1,9 +1,9 @@
Bugfix: Never create invalid snapshots on backup interruption
Bugfix: Don't create invalid snapshots when `backup` is interrupted
When canceling a backup run in the wrong moment it was possible that
When canceling a backup run at a certain moment it was possible that
restic created a snapshot with an invalid "null" tree. This caused
check and other operations to fail. The backup command now properly
handles interruptions and never saves a snapshot in that case.
`check` and other operations to fail. The `backup` command now properly
handles interruptions and never saves a snapshot when interrupted.
https://github.com/restic/restic/issues/3151
https://github.com/restic/restic/pull/3164

View File

@ -1,9 +1,9 @@
Bugfix: Improve error handling in restore
Bugfix: Improve error handling in the `restore` command
Restic restore used to not print errors while downloading file contents from
the repository. restore also incorrectly exited with a zero error code even
when there were errors during the restore process. Now, a non-zero code is
returned.
The `restore` command used to not print errors while downloading file contents
from the repository. It also incorrectly exited with a zero error code even
when there were errors during the restore process. This has all been fixed and
`restore` now returns with a non-zero exit code when there's an error.
https://github.com/restic/restic/issues/3166
https://github.com/restic/restic/pull/3207

View File

@ -1,9 +1,9 @@
Bugfix: Show correct statistics for overlapping targets
Bugfix: Correct statistics for overlapping targets
A user reported that restic's statistics and progress information during backup
is not correctly calculated when the backup targets (files/dirs to save)
was not correctly calculated when the backup targets (files/dirs to save)
overlap. For example, consider a directory `foo` which contains (among others)
a file `foo/bar`. When `restic backup foo foo/bar` is run, restic counted the
a file `foo/bar`. When `restic backup foo foo/bar` was run, restic counted the
size of the file `foo/bar` twice, so the completeness percentage as well as the
number of files was wrong. This is now corrected.

View File

@ -1,11 +1,11 @@
Enhancement: Keep mountpoints as empty directories
Enhancement: Back up mountpoints as empty directories
When the `--one-file-system` option is specified to `restic backup`, it
ignores all file systems mounted below one of the target directories. This
means that when a snapshot is restored, users needed to manually recreate the
mountpoint directories.
means that when a snapshot is restored, users needed to manually recreate
the mountpoint directories.
Restic now keeps mountpoints as empty directories and therefore implements
Restic now backs up mountpoints as empty directories and therefore implements
the same approach as `tar`.
https://github.com/restic/restic/issues/909

View File

@ -1,6 +1,6 @@
Enhancement: Add more error checks
Enhancement: Add several more error checks
We've added a lot more error checks in places where errors were ignored before
(as hinted by the static analysis programm `errcheck` via `golangci-lint`).
We've added a lot more error checks in places where errors were previously
ignored (as hinted by the static analysis program `errcheck` via `golangci-lint`).
https://github.com/restic/restic/pull/3250

View File

@ -1,29 +1,29 @@
Enhancement: Improve pruning performance and make pruning more customizable
Enhancement: Improve `prune` performance and make it more customizable
The `prune` command is now much faster. This is especially the case for remote
repositories or repositories with not much data to remove.
Also the memory usage of the `prune` command is now reduced.
repositories or repositories with not much data to remove. Also the memory
usage of the `prune` command is now reduced.
Restic used to rebuild the index from scratch after pruning. This could lead
to missing packs in the index in some cases for eventually consistent
backends, like e.g. AWS S3.
This behavior is now changed and the index rebuilding uses the information
already known by `prune`.
to missing packs in the index in some cases for eventually consistent backends
such as e.g. AWS S3. This behavior is now changed and the index rebuilding
uses the information already known by `prune`.
By default, the `prune` command no longer removes all unused data. This
behavior can be fine-tuned by new options, like the acceptable amount of unused space or
the maximum size of data to reorganize. For more details, see
https://restic.readthedocs.io/en/stable/060_forget.html
behavior can be fine-tuned by new options, like the acceptable amount of
unused space or the maximum size of data to reorganize. For more details,
please see https://restic.readthedocs.io/en/stable/060_forget.html .
Moreover, `prune` now accepts the `--dry-run` option and `forget --dry-run --prune`
also shows what `prune` would do.
Moreover, `prune` now accepts the `--dry-run` option and also running
`forget --dry-run --prune` will show what `prune` would do.
Fixes several open issues, e.g.:
https://github.com/restic/restic/issues/1140
https://github.com/restic/restic/issues/1599
https://github.com/restic/restic/issues/1985
https://github.com/restic/restic/issues/2112
https://github.com/restic/restic/issues/2227
https://github.com/restic/restic/issues/2305
This enhancement also fixes several open issues, e.g.:
- https://github.com/restic/restic/issues/1140
- https://github.com/restic/restic/issues/1599
- https://github.com/restic/restic/issues/1985
- https://github.com/restic/restic/issues/2112
- https://github.com/restic/restic/issues/2227
- https://github.com/restic/restic/issues/2305
https://github.com/restic/restic/pull/2718
https://github.com/restic/restic/pull/2842

View File

@ -1,21 +1,22 @@
Enhancement: Add option to let backup trust mtime without checking ctime
Enhancement: Add option to let `backup` trust mtime without checking ctime
The backup command used to require that both ctime and mtime of a file matched
with a previously backed up version to determine that the file was unchanged.
In other words, if either ctime or mtime of the file had changed, it would be
considered changed and restic would read the file's content again to back up
the relevant (changed) parts of it.
The `backup` command used to require that both `ctime` and `mtime` of a file
matched with a previously backed up version to determine that the file was
unchanged. In other words, if either `ctime` or `mtime` of the file had
changed, it would be considered changed and restic would read the file's
content again to back up the relevant (changed) parts of it.
The new option --ignore-ctime makes restic look at mtime only, such that ctime
changes for a file does not cause restic to read the file's contents again.
The new option `--ignore-ctime` makes restic look at `mtime` only, such that
`ctime` changes for a file does not cause restic to read the file's contents
again.
The check for both ctime and mtime was introduced in restic 0.9.6 to make
backups more reliable in the face of programs that reset mtime (some Unix
The check for both `ctime` and `mtime` was introduced in restic 0.9.6 to make
backups more reliable in the face of programs that reset `mtime` (some Unix
archivers do that), but it turned out to often be expensive because it made
restic read file contents even if only the metadata (owner, permissions) of
a file had changed. The new --ignore-ctime option lets the user restore the
0.9.5 behavior when needed. The existing --ignore-inode option already turned
off this behavior, but also removed a different check.
a file had changed. The new `--ignore-ctime` option lets the user restore the
0.9.5 behavior when needed. The existing `--ignore-inode` option already
turned off this behavior, but also removed a different check.
Please note that changes in files' metadata are still recorded, regardless of
the command line options provided to the backup command.

View File

@ -1,6 +1,6 @@
Enhancement: Speed up repacking step of prune command
Enhancement: Speed up the repacking step of the `prune` command
The repack step of the prune command, which moves still used file parts into
The repack step of the `prune` command, which moves still used file parts into
new pack files such that the old ones can be garbage collected later on, now
processes multiple pack files in parallel. This is especially beneficial for
high latency backends or when using a fast network connection.

View File

@ -1,9 +1,11 @@
Enhancement: Speed up rebuild-index
Enhancement: Speed up the `rebuild-index` command
We've optimized the command rebuild-index. Now, existing index entries are used
We've optimized the `rebuild-index` command. Now, existing index entries are used
to minimize the number of pack files that must be read. This speeds up the index
rebuild a lot.
Also the option --read-all-packs was added which implements the previous behavior.
Additionally, the option `--read-all-packs` has been added, implementing the
previous behavior.
https://github.com/restic/restic/issue/2547
https://github.com/restic/restic/pull/3006

View File

@ -1,12 +1,13 @@
Bugfix: Fix sporadic stream reset between rclone and restic
Sometimes when using restic with the rclone backend, an error message similar to the following is printed:
Sometimes when using restic with the `rclone` backend, an error message
similar to the following would be printed:
Didn't finish writing GET request (wrote 0/xxx): http2: stream closed
It was found that this is caused by restic closing the connection to rclone
when downloading data too fast. A workaround was added which waits for the end
of the download before closing the connection.
It was found that this was caused by restic closing the connection to rclone
to soon when downloading data. A workaround has been added which waits for
the end of the download before closing the connection.
https://github.com/restic/restic/pull/3014
https://github.com/rclone/rclone/issues/2598

View File

@ -1,17 +1,23 @@
Enhancement: Check now has more checks for consistency of index and pack files
Enhancement: Add more checks for index and pack files in the `check` command
Restic used to only verify the pack file content when calling `check --read-data` or
`check --read-data-subset` but did not check if the blobs within the pack are
correctly contained in the index.
This check is now added and may give an "Blob ID is not contained in index or position
is incorrect" error.
Also a new test is added which compares pack file sizes computed from the index and the
pack header with the actual file size. This test is able to detect truncated pack files.
The `check` command run with the `--read-data` or `--read-data-subset` options
used to only verify only the pack file content - it did not check if the blobs
within the pack are correctly contained in the index.
If the index is not correct, it can be rebuilt by using the `rebuild-index` command.
A check for the latter is now in place, which can print the following error:
Having added these tests, `restic check` is now able to detect non-existing blobs which
are wrongly referenced in the index. This situation could have lead to missing data.
Blob ID is not contained in index or position is incorrect
Another test is also added, which compares pack file sizes computed from the
index and the pack header with the actual file size. This test is able to
detect truncated pack files.
If the index is not correct, it can be rebuilt by using the `rebuild-index`
command.
Having added these tests, `restic check` is now able to detect non-existing
blobs which are wrongly referenced in the index. This situation could have
lead to missing data.
https://github.com/restic/restic/pull/3048
https://github.com/restic/restic/pull/3082

View File

@ -1,8 +1,8 @@
Enhancement: Add zip format support to dump
Enhancement: Make the `dump` command support `zip` format
Previously, restic could dump the contents of a whole folder structure only
in the tar format. The `dump` command now has a new flag to change output
format to zip. Just pass `--archive zip` as an option to `restic dump`.
in the `tar` format. The `dump` command now has a new flag to change output
format to `zip`. Just pass `--archive zip` as an option to `restic dump`.
https://github.com/restic/restic/pull/2433
https://github.com/restic/restic/pull/3081

View File

@ -1,6 +1,6 @@
Enhancement: Reduce memory usage of check command
Enhancement: Reduce memory usage of `check` command
The check command now requires less memory if it is run without the
The `check` command now requires less memory if it is run without the
`--check-unused` option.
https://github.com/restic/restic/pull/3099

View File

@ -1,10 +1,10 @@
Enhancement: Parallelize scan of snapshot content in copy and prune
Enhancement: Parallelize scan of snapshot content in `copy` and `prune`
The copy and the prune commands used to traverse the directories of
The `copy` and `prune` commands used to traverse the directories of
snapshots one by one to find used data. This snapshot traversal is
now parallized which can speed up this step several times.
In addition the check command now reports how many snapshots have
In addition the `check` command now reports how many snapshots have
already been processed.
https://github.com/restic/restic/pull/3106

View File

@ -2,6 +2,7 @@ Enhancement: Parallelize reading of locks and snapshots
Restic used to read snapshots sequentially. For repositories containing
many snapshots this slowed down commands which have to read all snapshots.
Now the reading of snapshots is parallelized. This speeds up for example
`prune`, `backup` and other commands that search for snapshots with certain
properties or which have to find the `latest` snapshot.

View File

@ -1,8 +1,8 @@
Bugfix: On Linux `backup` hangs during exit when run as a background job
Bugfix: Do not hang until foregrounded when completed in background
On Linux, when running in the background restic failed to stop the terminal
output of the `backup` command after it had completed. This caused restic to
hang until moved to the foreground. This has been fixed.
hang until moved to the foreground. This has now been fixed.
https://github.com/restic/restic/pull/3152
https://forum.restic.net/t/restic-alpine-container-cron-hangs-epoll-pwait/3334

View File

@ -1,7 +1,7 @@
Bugfix: Better error handling for gs backend
Bugfix: Improve error handling in `gs` backend
The gs backend did not notice when the last steep of completing a file upload
failed. Under rare circumstance, this might be able to cause missing files in
the backup repository. This has been fixed.
The `gs` backend did not notice when the last step of completing a
file upload failed. Under rare circumstances, this could cause
missing files in the backup repository. This has now been fixed.
https://github.com/restic/restic/pull/3249