mirror of
https://github.com/octoleo/restic.git
synced 2024-11-25 22:27:35 +00:00
rawtaz
GitHub
commit
e2bcfd68dd
@ -1,7 +1,7 @@
|
||||
Enhancement: Implement rewrite command
|
||||
Enhancement: Implement `rewrite` command
|
||||
|
||||
We've added a new command which allows to rewrite existing snapshots to remove
|
||||
unwanted files.
|
||||
Restic now has a `rewrite` command which allows to rewrite existing snapshots
|
||||
to remove unwanted files.
|
||||
|
||||
https://github.com/restic/restic/issues/14
|
||||
https://github.com/restic/restic/pull/2731
|
||||
|
||||
@ -1,16 +1,15 @@
|
||||
Enhancement: "Everything is ok" message after retrying
|
||||
Enhancement: Inform about successful retries after errors
|
||||
|
||||
When a recoverable error is encountered, restic displays a warning message
|
||||
saying it's retrying, like this one:
|
||||
When a recoverable error is encountered, restic shows a warning message saying
|
||||
that it's retrying, e.g.:
|
||||
|
||||
Save(<data/956b9ced99>) returned error, retrying after 357.131936ms: CreateBlockBlobFromReader: Put https://example.blob.core.windows.net/restic/data/95/956b9ced99...aac: write tcp 192.168.11.18:51620->1.2.3.4:443: write: connection reset by peer
|
||||
`Save(<data/956b9ced99>) returned error, retrying after 357.131936ms: ...`
|
||||
|
||||
This message can be a little confusing because it seems like there was an
|
||||
error, but we're not sure if it was actually fixed by retrying.
|
||||
This message can be confusing in that it never clearly states whether the retry
|
||||
is successful or not. This has now been fixed such that restic follows up with
|
||||
a message confirming a successful retry, e.g.:
|
||||
|
||||
restic is now displaying a confirmation that the action was successful after retrying:
|
||||
|
||||
Save(<data/956b9ced99>) operation successful after 1 retries
|
||||
`Save(<data/956b9ced99>) operation successful after 1 retries`
|
||||
|
||||
https://github.com/restic/restic/issues/1734
|
||||
https://github.com/restic/restic/pull/2661
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
Enhancement: Improve handling of directories with duplicate entries
|
||||
|
||||
If for some reason a directory contains a duplicate entry, this caused the
|
||||
backup command to fail with a `node "path/to/file" already present` or `nodes
|
||||
If for some reason a directory contains a duplicate entry, the `backup` command
|
||||
would previously fail with a `node "path/to/file" already present` or `nodes
|
||||
are not ordered got "path/to/file", last "path/to/file"` error.
|
||||
|
||||
The error handling has been changed to only report a warning in this case. Make
|
||||
sure to check that the filesystem in question is not damaged!
|
||||
The error handling has been improved to only report a warning in this case. Make
|
||||
sure to check that the filesystem in question is not damaged if you see this!
|
||||
|
||||
https://github.com/restic/restic/issues/1866
|
||||
https://github.com/restic/restic/issues/3937
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
Bugfix: Mount command should return exit code 0 after receiving Ctrl-C
|
||||
Bugfix: Make `mount` return exit code 0 after receiving Ctrl-C / SIGINT
|
||||
|
||||
To stop the mount command, a user has to press Ctrl-C or send a SIGINT to
|
||||
restic. This caused restic to exit with a non-zero exit code.
|
||||
To stop the `mount` command, a user has to press Ctrl-C or send a SIGINT
|
||||
signal to restic. This used to cause restic to exit with a non-zero exit code.
|
||||
|
||||
We have changed the exit code to zero as this is the expected way to stop the
|
||||
mount command.
|
||||
The exit code has now been changed to zero as the above is the expected way
|
||||
to stop the `mount` command and should therefore be considered successful.
|
||||
|
||||
https://github.com/restic/restic/issues/2015
|
||||
https://github.com/restic/restic/pull/3894
|
||||
|
||||
@ -3,13 +3,13 @@ Enhancement: Support B2 API keys restricted to hiding but not deleting files
|
||||
When the B2 backend does not have the necessary permissions to permanently
|
||||
delete files, it now automatically falls back to hiding files. This allows
|
||||
using restic with an application key which is not allowed to delete files.
|
||||
This prevents an attacker to delete backups with the API key used by restic.
|
||||
This can prevent an attacker from deleting backups with such an API key.
|
||||
|
||||
To use this feature create an application key without the deleteFiles
|
||||
To use this feature create an application key without the `deleteFiles`
|
||||
capability. It is recommended to restrict the key to just one bucket.
|
||||
For example using the b2 command line tool:
|
||||
For example using the `b2` command line tool:
|
||||
|
||||
b2 create-key --bucket <bucketName> <keyName> listBuckets,readFiles,writeFiles,listFiles
|
||||
`b2 create-key --bucket <bucketName> <keyName> listBuckets,readFiles,writeFiles,listFiles`
|
||||
|
||||
Alternatively, you can use the S3 backend to access B2, as described
|
||||
in the documentation. In this mode, files are also only hidden instead
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
Enhancement: only open connection once for `init` command using sftp backend
|
||||
Enhancement: Make `init` open only one connection for the SFTP backend
|
||||
|
||||
The `init` command using the sftp backend used to connect twice to the
|
||||
repository. This can be inconvenient if the user must enter a password or cause
|
||||
`init` to fail if the server does not correctly close the first sftp
|
||||
The `init` command using the SFTP backend used to connect twice to the
|
||||
repository. This could be inconvenient if the user must enter a password,
|
||||
or cause `init` to fail if the server does not correctly close the first SFTP
|
||||
connection.
|
||||
|
||||
This has been fixed by reusing the initial sftp connection.
|
||||
This has now been fixed by reusing the first/initial SFTP connection opened.
|
||||
|
||||
https://github.com/restic/restic/issues/2152
|
||||
https://github.com/restic/restic/pull/3882
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
Enhancement: Redownload cached data if invalid
|
||||
Enhancement: Handle cache corruption on disk and in downloads
|
||||
|
||||
In rare situations, like for example after a system crash, the data stored
|
||||
in the cache might be corrupted. This could cause restic to fail and
|
||||
required manually deleting the cache.
|
||||
in the cache might be corrupted. This could cause restic to fail and required
|
||||
manually deleting the cache.
|
||||
|
||||
Restic now automatically removes broken data from the cache, allowing it
|
||||
to recover from such a situation without user intervention. In addition,
|
||||
restic retries downloads which return corrupt data in order to handle
|
||||
restic retries downloads which return corrupt data in order to also handle
|
||||
temporary download problems.
|
||||
|
||||
https://github.com/restic/restic/issues/2533
|
||||
|
||||
@ -1,22 +1,17 @@
|
||||
Bugfix: Don't read password from stdin for backup --stdin
|
||||
Bugfix: Don't read password from stdin for `backup --stdin`
|
||||
|
||||
Restic backup previously tried to read first the password, then the data
|
||||
to be backed up from standard input. This meant it would often confuse part
|
||||
of the data for the password.
|
||||
The `backup` command when used with `--stdin` previously tried to read first
|
||||
the password, then the data to be backed up from standard input. This meant
|
||||
it would often confuse part of the data for the password.
|
||||
|
||||
From now on, restic backup --stdin will exit with the message
|
||||
From now on, it will instead exit with the message `Fatal: cannot read both
|
||||
password and data from stdin` unless the password is passed in some other
|
||||
way (such as `--restic-password-file`, `RESTIC_PASSWORD`, etc).
|
||||
|
||||
Fatal: cannot read both password and data from stdin
|
||||
|
||||
unless the password is passed in some other way (--restic-password-file,
|
||||
RESTIC_PASSWORD, etc.). To enter the password interactively, a password
|
||||
command has to be used. For example, on Linux,
|
||||
|
||||
mysqldump somedatabase |
|
||||
restic backup --stdin \
|
||||
--password-command='sh -c "systemd-ask-password < /dev/tty"'
|
||||
|
||||
securely reads the password from the terminal.
|
||||
To enter the password interactively a password command has to be used. For
|
||||
example on Linux, `mysqldump somedatabase | restic backup --stdin
|
||||
--password-command='sh -c "systemd-ask-password < /dev/tty"'` securely reads
|
||||
the password from the terminal.
|
||||
|
||||
https://github.com/restic/restic/issues/2591
|
||||
https://github.com/restic/restic/pull/4011
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Bugfix: Restore symbolic links on windows
|
||||
Enhancement: Support restoring symbolic links on Windows
|
||||
|
||||
We've added support to restore symbolic links on windows.
|
||||
Because of windows specific restrictions this is only possible when running
|
||||
restic having SeCreateSymbolicLinkPrivilege privilege or when running as admin.
|
||||
The `restore` command now supports restoring symbolic links on Windows. Because
|
||||
of Windows specific restrictions this is only possible when running restic with
|
||||
the `SeCreateSymbolicLinkPrivilege` privilege or as an administrator.
|
||||
|
||||
https://github.com/restic/restic/issues/1078
|
||||
https://github.com/restic/restic/issues/2699
|
||||
|
||||
@ -1,17 +1,20 @@
|
||||
Enhancement: Stricter repository lock handling
|
||||
|
||||
Restic commands kept running even if they failed to refresh their locks in
|
||||
time. This can be a problem if a concurrent call to `unlock` and `prune`
|
||||
removes data from the repository. Not refreshing a lock in time can for example
|
||||
be caused by a client switching to standby while running a backup.
|
||||
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.
|
||||
|
||||
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 file manually or using
|
||||
`unlock --remove-all`. Please make sure that no other restic processes are
|
||||
running concurrently.
|
||||
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.
|
||||
|
||||
https://github.com/restic/restic/issues/2715
|
||||
https://github.com/restic/restic/pull/3569
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
Change: Include full snapshot ID in JSON output of the bacukp command
|
||||
Change: Include full snapshot ID in JSON output of `backup`
|
||||
|
||||
We have changed the JSON output of the backup command to include the full snapshot ID instead of just a shortened version.
|
||||
The latter can be ambiguous in rare cases.
|
||||
|
||||
To derive the short ID, truncate the full ID down to 8 characters.
|
||||
We have changed the JSON output of the backup command to include the full
|
||||
snapshot ID instead of just a shortened version, as the latter can be ambiguous
|
||||
in some rare cases. To derive the short ID, please truncate the full ID down to
|
||||
eight characters.
|
||||
|
||||
https://github.com/restic/restic/issues/2724
|
||||
https://github.com/restic/restic/pull/3993
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Enhancement: Add support for `credential_process` to S3 backend
|
||||
|
||||
We have updated the library used for the S3 backend. This adds support for the
|
||||
`credential_process` option in the aws credential configuration.
|
||||
Restic now uses a newer library for the S3 backend, which adds support for the
|
||||
`credential_process` option in the AWS credential configuration.
|
||||
|
||||
https://github.com/restic/restic/issues/3029
|
||||
https://github.com/restic/restic/issues/4034
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Enhancement: Support mount command on macOS using macFUSE 4.x
|
||||
Enhancement: Make `mount` command support macOS using macFUSE 4.x
|
||||
|
||||
We have switched to a different version of the fuse library used to mount
|
||||
snapshots. This adds support for macFUSE 4.x which is necessary for recent
|
||||
macOS versions.
|
||||
Restic now uses a different FUSE library for mounting snapshots and making them
|
||||
available as a FUSE filesystem using the `mount` command. This adds support for
|
||||
macFUSE 4.x which can be used to make this work on recent macOS versions.
|
||||
|
||||
https://github.com/restic/restic/issues/3096
|
||||
https://github.com/restic/restic/pull/4024
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Enhancement: Support json output for the `init` command
|
||||
Enhancement: Support JSON output for the `init` command
|
||||
|
||||
The `init` command ignored the `--json` flag. It now outputs a JSON message if
|
||||
the repository was created successfully.
|
||||
The `init` command used to ignore the `--json` option, but now outputs a JSON
|
||||
message if the repository was created successfully.
|
||||
|
||||
https://github.com/restic/restic/issues/3124
|
||||
https://github.com/restic/restic/pull/3132
|
||||
|
||||
@ -1,13 +1,14 @@
|
||||
Bugfix: Reliably delete files on Backblaze B2
|
||||
Bugfix: Delete files on Backblaze B2 more reliably
|
||||
|
||||
Restic used to only delete the latest version of files stored in B2. In most
|
||||
cases this works well as there is only a single version. However, due to
|
||||
retries while uploading it is possible for multiple file versions to be stored
|
||||
at B2. This can lead to various problems if files still exist that should have
|
||||
been deleted.
|
||||
cases this worked well as there was only a single version of the file. However,
|
||||
due to retries while uploading it is possible for multiple file versions to be
|
||||
stored at B2. This could lead to various problems for files that should have
|
||||
been deleted but still existed.
|
||||
|
||||
We have changed the implementation to delete all of them. This doubles the
|
||||
number of Class B transactions necessary to delete files.
|
||||
The implementation has now been changed to delete all versions of files, which
|
||||
doubles the amount of Class B transactions necessary to delete files, but
|
||||
assures that no file versions are left behind.
|
||||
|
||||
https://github.com/restic/restic/issues/3161
|
||||
https://github.com/restic/restic/pull/3885
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
Bugfix: SFTP backend now checks for disk space
|
||||
Bugfix: Make SFTP backend report no space left on device
|
||||
|
||||
A backup to an SFTP backend would spew repeated SSH_FX_FAILURE messages when
|
||||
the remote disk is full. Restic now reports "sftp: no space left on device"
|
||||
Backing up to an SFTP backend would spew repeated SSH_FX_FAILURE messages when
|
||||
the remote disk was full. Restic now reports "sftp: no space left on device"
|
||||
and exits immediately when it detects this condition.
|
||||
|
||||
A fix for this issue was promised in restic 0.12.1, but the fix itself
|
||||
contained a bug that prevented it from triggering.
|
||||
A fix for this issue was implemented in restic 0.12.1, but unfortunately the
|
||||
fix itself contained a bug that prevented it from taking effect.
|
||||
|
||||
https://github.com/restic/restic/issues/3336
|
||||
https://github.com/restic/restic/pull/3345
|
||||
|
||||
@ -1,10 +1,9 @@
|
||||
Bugfix: Improve handling of interrupted syscalls in `mount` command
|
||||
|
||||
Accessing restic's fuse mount could result in "input / output" errors when
|
||||
using programs in which syscalls can be interrupted. This is for example the
|
||||
case for go programs.
|
||||
|
||||
We have corrected the error handling for interrupted syscalls.
|
||||
Accessing restic's FUSE mount could result in "input/output" errors when using
|
||||
programs in which syscalls can be interrupted. This is for example the case for
|
||||
Go programs. This has now been fixed by improved error handling of interrupted
|
||||
syscalls.
|
||||
|
||||
https://github.com/restic/restic/issues/3567
|
||||
https://github.com/restic/restic/issues/3694
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Bugfix: Fix stuck `copy` command when setting backend connections to 1
|
||||
Bugfix: Fix stuck `copy` command when `-o <backend>.connections=1`
|
||||
|
||||
When calling the copy command using `copy -o <backend>.connections=1` this
|
||||
caused the command to be stuck permanently. This has been fixed.
|
||||
When running the `copy` command with `-o <backend>.connections=1` the
|
||||
command would be infinitely stuck. This has now been fixed.
|
||||
|
||||
https://github.com/restic/restic/issues/3897
|
||||
https://github.com/restic/restic/pull/3898
|
||||
|
||||
@ -1,12 +1,9 @@
|
||||
Bugfix: Correct prune statistics for partially compressed repositories
|
||||
|
||||
In a partially compressed repository, one data blob can exist both in an
|
||||
uncompressed and a compressed version. This caused the prune statistics to
|
||||
become inaccurate and for example report a too high value for the unused size:
|
||||
|
||||
> unused size after prune: 16777215.991 TiB
|
||||
|
||||
This has been fixed.
|
||||
uncompressed and a compressed version. This caused the `prune` statistics to
|
||||
become inaccurate and e.g. report a too high value for the unused size, such
|
||||
as "unused size after prune: 16777215.991 TiB". This has now been fixed.
|
||||
|
||||
https://github.com/restic/restic/issues/3918
|
||||
https://github.com/restic/restic/pull/3980
|
||||
|
||||
@ -1,7 +1,11 @@
|
||||
Enhancement: Only display the message if there were locks to be removed
|
||||
Change: Make `unlock` display message only when locks were actually removed
|
||||
|
||||
`restic unlock` now only shows `successfully removed locks` if there were locks to be removed.
|
||||
In addition, it also reports the number of the removed lock files.
|
||||
The `unlock` command used to print the "successfully removed locks" message
|
||||
whenever it was run, regardless of lock files having being removed or not.
|
||||
|
||||
This has now been changed such that it only prints the message if any lock
|
||||
files were actually removed. In addition, it also reports the number of
|
||||
removed lock files.
|
||||
|
||||
https://github.com/restic/restic/issues/3929
|
||||
https://github.com/restic/restic/pull/3935
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Enhancement: Improve handling of ErrDot errors in rclone and sftp backends
|
||||
|
||||
Since Go 1.19, restic can no longer implicitly run relative executables which
|
||||
are found in the current directory (e.g. `rclone` if it's found in `.`). This
|
||||
is a security feature of Go to prevent against running unintended and possibly
|
||||
are found in the current directory (e.g. `rclone` if found in `.`). This is a
|
||||
security feature of Go to prevent against running unintended and possibly
|
||||
harmful executables.
|
||||
|
||||
The error message for this was just "cannot run executable found relative to
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Bugfix: Backup no longer hangs on Solaris when seeing a FIFO file
|
||||
Bugfix: Make `backup` no longer hang on Solaris when seeing a FIFO file
|
||||
|
||||
Restic backup used to hang on Solaris whenever it encountered a FIFO file
|
||||
(named pipe), due to a bug in the extended attribute handling. This bug has
|
||||
been fixed.
|
||||
The `backup` command used to hang on Solaris whenever it encountered a FIFO
|
||||
file (named pipe), due to a bug in the handling of extended attributes. This
|
||||
bug has now been fixed.
|
||||
|
||||
https://github.com/restic/restic/issues/4003
|
||||
https://github.com/restic/restic/pull/4053
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Bugfix: Support ExFAT-formatted local backends on macOS Ventura
|
||||
|
||||
ExFAT-formatted disks could not be used as local backends starting from macOS
|
||||
Ventura. Restic commands would fail with "inappropriate ioctl for device". This
|
||||
has been fixed.
|
||||
Ventura. Restic commands would fail with an "inappropriate ioctl for device"
|
||||
error. This has now been fixed.
|
||||
|
||||
https://github.com/restic/restic/issues/4016
|
||||
https://github.com/restic/restic/pull/4021
|
||||
|
||||
@ -1,9 +1,11 @@
|
||||
Change: copy command no longer prints skipped existing snapshots by default
|
||||
Change: Don't print skipped snapshots by default in `copy` command
|
||||
|
||||
Restic copy always printed each skipped snapshot that existed on the remote and
|
||||
would bury the snapshots that were copied amongst the output. The new default
|
||||
only outputs new copies. Increase the verbose level to see skipped existing
|
||||
snapshots.
|
||||
The `copy` command used to print each snapshot that was skipped because it
|
||||
already existed in the target repository. The amount of this output could
|
||||
practically bury the list of snapshots that were actually copied.
|
||||
|
||||
From now on, the skipped snapshots are by default not printed at all, but
|
||||
this can be re-enabled by increasing the verbosity level of the command.
|
||||
|
||||
https://github.com/restic/restic/issues/4033
|
||||
https://github.com/restic/restic/pull/4066
|
||||
|
||||
@ -1,8 +1,10 @@
|
||||
Bugfix: Restic init ignores "Access Denied" errors when creating an S3 bucket
|
||||
Bugfix: Make `init` ignore "Access Denied" errors when creating S3 buckets
|
||||
|
||||
In restic 0.9.0 through 0.13.0, some permission errors from S3 backends where ignored
|
||||
when trying to check the bucket existence, so that manually created buckets with custom permissions
|
||||
could be used for backups. This feature was broken in 0.14.0, but is now restored.
|
||||
In restic 0.9.0 through 0.13.0, the `init` command ignored some permission
|
||||
errors from S3 backends when trying to check for bucket existence, so that
|
||||
manually created buckets with custom permissions could be used for backups.
|
||||
|
||||
This feature became broken in 0.14.0, but has now been restored again.
|
||||
|
||||
https://github.com/restic/restic/issues/4085
|
||||
https://github.com/restic/restic/pull/4086
|
||||
|
||||
@ -1,9 +1,10 @@
|
||||
Bugfix: fix restic dump of tar file with 32-bit binary
|
||||
Bugfix: Don't generate negative UIDs and GIDs in tar files from `dump`
|
||||
|
||||
When using a 32-bit build of restic, the `restic dump` command could in some
|
||||
cases create tar files containing negative uid and gid. These files cannot be
|
||||
read by gnu tar. This corner case especially applies to backups from stdin on Windows.
|
||||
We have changed the dump command to create valid tar files in this case.
|
||||
When using a 32-bit build of restic, the `dump` command could in some cases
|
||||
create tar files containing negative UIDs and GIDs, which cannot be read by
|
||||
GNU tar. This corner case especially applies to backups from stdin on Windows.
|
||||
|
||||
This is now fixed such that `dump` creates valid tar files in these cases too.
|
||||
|
||||
https://github.com/restic/restic/issues/4103
|
||||
https://github.com/restic/restic/pull/4104
|
||||
|
||||
@ -1,14 +1,14 @@
|
||||
Enhancement: Restore files with many zeros as sparse files
|
||||
Enhancement: Restore files with long runs of zeros as sparse files
|
||||
|
||||
When using `restore --sparse`, the restorer may now write files containing long
|
||||
runs of zeros as sparse files (also called files with holes): the zeros are not
|
||||
actually written to disk.
|
||||
runs of zeros as sparse files (also called files with holes), where the zeros
|
||||
are not actually written to disk.
|
||||
|
||||
How much space is saved by writing sparse files depends on the operating
|
||||
system, file system and the distribution of zeros in the file.
|
||||
|
||||
During backup restic still reads the whole file including sparse regions. We
|
||||
have optimized the processing speed of sparse regions.
|
||||
During backup restic still reads the whole file including sparse regions, but
|
||||
with optimized processing speed of sparse regions.
|
||||
|
||||
https://github.com/restic/restic/issues/79
|
||||
https://github.com/restic/restic/issues/3903
|
||||
|
||||
@ -1,6 +1,7 @@
|
||||
Enhancement: Make backup file read concurrency configurable
|
||||
|
||||
The `backup` command now supports a `--read-concurrency` flag to allowing
|
||||
tuning restic for very fast storage like NVME disks.
|
||||
The `backup` command now supports a `--read-concurrency` option which allows
|
||||
tuning restic for very fast storage like NVMe disks by controlling the number
|
||||
of concurrent file reads during the backup process.
|
||||
|
||||
https://github.com/restic/restic/pull/2750
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
Bugfix: Make sure that symlinks can be created during recovery
|
||||
Bugfix: Make `restore` replace existing symlinks
|
||||
|
||||
When restoring a symlink, restic reported an error if the target path already existed.
|
||||
With this change, the potentially existing target path is first removed before the symlink is recreated.
|
||||
When restoring a symlink, restic used to report an error if the target path
|
||||
already existed. This has now been fixed such that the potentially existing
|
||||
target path is first removed before the symlink is restored.
|
||||
|
||||
https://github.com/restic/restic/issues/2578
|
||||
https://github.com/restic/restic/pull/3780
|
||||
|
||||
@ -1,5 +1,6 @@
|
||||
Enhancement: Optimize prune memory usage
|
||||
|
||||
The prune command requires large amounts of memory to determine what to keep and what to remove. That step has been optimized to use up to 30% less memory.
|
||||
The `prune` command needs large amounts of memory in order to determine what to
|
||||
keep and what to remove. This is now optimized to use up to 30% less memory.
|
||||
|
||||
https://github.com/restic/restic/pull/3899
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Enhancement: Improve speed of parent snapshot searching for `backup` command
|
||||
Enhancement: Improve speed of parent snapshot detection in `backup` command
|
||||
|
||||
Backing up a large number of files using `--files-from-verbatim` or `--files-from-raw`
|
||||
options could require a long time to find the parent snapshot. This has been improved.
|
||||
|
||||
@ -1,9 +1,12 @@
|
||||
Enhancement: add compression statistics to the restic stats command
|
||||
Enhancement: Add compression statistics to the `stats` command
|
||||
|
||||
When executed in `raw-data` mode on a repository that supports compression, the `restic stats`
|
||||
command now calculates and displays, for the selected repository or snapshots, the uncompressed
|
||||
size of the data, the compression progress (percentage of data that has been compressed), the
|
||||
compression ratio of the compressed data and the total space saving, taking into account both
|
||||
the compressed and uncompressed data if the repository is only partially compressed.
|
||||
When executed with `--mode raw-data` on a repository that supports compression,
|
||||
the `stats` command now calculates and displays, for the selected repository or
|
||||
snapshots: the uncompressed size of the data; the compression progress
|
||||
(percentage of data that has been compressed); the compression ratio of the
|
||||
compressed data; the total space saving.
|
||||
|
||||
It also takes into account both the compressed and uncompressed data if the
|
||||
repository is only partially compressed.
|
||||
|
||||
https://github.com/restic/restic/pull/3915
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
Enhancement: Provide command completion for powershell
|
||||
Enhancement: Provide command completion for PowerShell
|
||||
|
||||
Restic allows generation of completion files for bash, fish and zsh. Now powershell
|
||||
is supported, too.
|
||||
Restic already provided generation of completion files for bash, fish and zsh.
|
||||
Now powershell is supported, too.
|
||||
|
||||
https://github.com/restic/restic/pull/3925/files
|
||||
https://github.com/restic/restic/pull/3925/files
|
||||
|
||||
@ -1,8 +1,10 @@
|
||||
Enhancement: Allow backup file tree scanner to be disabled
|
||||
Enhancement: Allow `backup` file tree scanner to be disabled
|
||||
|
||||
Restic walks the file tree in a separate scanner process to find the total size
|
||||
and file/directory count, and uses that to provide an ETA. This can slow down
|
||||
backups, especially of network filesystems. The new flag `--no-scan`
|
||||
can be used to speed up such backups.
|
||||
The `backup` command walks the file tree in a separate scanner process to find
|
||||
the total size and file/directory count, and uses this to provide an ETA. This
|
||||
can slow down backups, especially of network filesystems.
|
||||
|
||||
The command now has a new option `--no-scan` which can be used to disable this
|
||||
scanning in order to speed up backups when needed.
|
||||
|
||||
https://github.com/restic/restic/pull/3931
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
Enhancement: Ignore additional files in repository
|
||||
Enhancement: Ignore additional/unknown files in repository
|
||||
|
||||
Some commands like `find` and `restore` could become confused by additional
|
||||
files in the repository. This could cause restic to fail with an `multiple IDs
|
||||
with prefix "12345678" found` error. These commands now ignore additional
|
||||
files.
|
||||
If a restic repository had additional files in it (not created by restic),
|
||||
commands like `find` and `restore` could become confused and fail with an
|
||||
`multiple IDs with prefix "12345678" found` error. These commands now
|
||||
ignore such additional files.
|
||||
|
||||
https://github.com/restic/restic/pull/3943
|
||||
https://forum.restic.net/t/which-protocol-should-i-choose-for-remote-linux-backups/5446/17
|
||||
|
||||
@ -1,6 +1,7 @@
|
||||
Bugfix: `ls` returns exit code 1 if snapshot cannot be loaded
|
||||
Bugfix: Make `ls` return exit code 1 if snapshot cannot be loaded
|
||||
|
||||
If the `ls` command failed to load a snapshot, it only printed a warning and
|
||||
returned exit code 0. This has been changed to return exit code 1 instead.
|
||||
The `ls` command used to show a warning and return exit code 0 when failing
|
||||
to load a snapshot. This has now been fixed such that it instead returns exit
|
||||
code 1 (still showing a warning).
|
||||
|
||||
https://github.com/restic/restic/pull/3951
|
||||
|
||||
@ -1,9 +1,9 @@
|
||||
Enhancement: Improve backup performance for small files
|
||||
Enhancement: Improve `backup` performance for small files
|
||||
|
||||
When backing up small files restic was slower than it could be. In particular
|
||||
this affected backups using maximum compression.
|
||||
|
||||
This has been fixed by reworking the internal parallelism of the backup
|
||||
command.
|
||||
command, making it back up small files around two times faster.
|
||||
|
||||
https://github.com/restic/restic/issues/3955
|
||||
https://github.com/restic/restic/pull/3955
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Change: Update dependencies and require Go 1.18 or newer
|
||||
|
||||
We've updated most dependencies. Since some libraries require newer language
|
||||
features, we're dropping support for Go 1.15 - 1.17, which means that restic now
|
||||
Most dependencies have been updated. Since some libraries require newer language
|
||||
features, support for Go 1.15-1.17 has been dropped, which means that restic now
|
||||
requires at least Go 1.18 to build.
|
||||
|
||||
https://github.com/restic/restic/pull/4041
|
||||
|
||||
@ -1,9 +1,11 @@
|
||||
Bugfix: Restore self-update to disabled-by-default
|
||||
Bugfix: Make `self-update` enabled by default only in release builds
|
||||
|
||||
Due to a typo, the `self-update` feature was always compiled, even if the
|
||||
`selfupdate` tag was not explicitly enabled.
|
||||
The `self-update` command was previously included by default in all builds of
|
||||
restic as opposed to only in official release builds, even if the `selfupdate`
|
||||
tag was not explicitly enabled when building.
|
||||
|
||||
As intended, it is now disabled by default.
|
||||
Official builds using `build.go` continue to explicitly enable it.
|
||||
This has now been corrected, and the `self-update` command is only available
|
||||
if restic was built with `-tags selfupdate` (as done for official release
|
||||
builds by `build.go`).
|
||||
|
||||
https://github.com/restic/restic/pull/4100
|
||||
|
||||
Loading…
Reference in New Issue
Block a user