We're very pleased to announce restic 0.9.0! restic is distributed as a standalone binary: download the correct file for your operating system and architecture, extract the file and just run it. If you run into any issues, please report them at the GitHub issue tracker or visit the forum.

The binaries released with each restic version are reproducible, which means that you can easily reproduce a byte identical version from the source code for that release. Instructions on how to do that are contained in the builder repository.

Changelog for restic 0.9.0 (2018-05-21)

The following sections list the changes in restic 0.9.0 relevant to restic users. The changes are ordered by importance.

Summary

• Fix #1608: Respect time stamp for new backup when reading from stdin
• Fix #1652: Ignore/remove invalid lock files
• Fix #1730: Ignore sockets for restore
• Fix #1684: Fix backend tests for rest-server
• Fix #1745: Correctly parse the argument to --tls-client-cert
• Enh #1433: Support UTF-16 encoding and process Byte Order Mark
• Enh #1561: Allow using rclone to access other services
• Enh #1665: Improve cache handling for restic check
• Enh #1721: Add cache command to list cache dirs
• Enh #1758: Allow saving OneDrive folders in Windows
• Enh #549: Rework archiver code
• Enh #1552: Use Google Application Default credentials
• Enh #1477: Accept AWS_SESSION_TOKEN for the s3 backend
• Enh #1648: Ignore AWS permission denied error when creating a repository
• Enh #1649: Add illumos/Solaris support
• Enh #1709: Improve messages restic check prints
• Enh #827: Add --new-password-file flag for non-interactive password changes
• Enh #1735: Allow keeping a time range of snaphots
• Enh #1782: Use default AWS credentials chain for S3 backend

Details

• Bugfix #1608: Respect time stamp for new backup when reading from stdin

  When reading backups from stdin (via restic backup --stdin), restic now uses the time stamp for the new backup passed in --time.

  #1608 #1703

• Bugfix #1652: Ignore/remove invalid lock files

  This corrects a bug introduced recently: When an invalid lock file in the repo is encountered (e.g. if the file is empty), the code used to ignore that, but now returns the error. Now, invalid files are ignored for the normal lock check, and removed when restic unlock --remove-all is run.

  #1652 #1653

• Bugfix #1730: Ignore sockets for restore

  We've received a report and correct the behavior in which the restore code aborted restoring a directory when a socket was encountered. Unix domain socket files cannot be restored (they are created on the fly once a process starts listening). The error handling was corrected, and in addition we're now ignoring sockets during restore.

  #1730 #1731

• Bugfix #1684: Fix backend tests for rest-server

  The REST server for restic now requires an explicit parameter (--no-auth) if no authentication should be allowed. This is fixed in the tests.

  #1684

• Bugfix #1745: Correctly parse the argument to --tls-client-cert

  Previously, the --tls-client-cert method attempt to read ARGV[1] (hardcoded) instead of the argument that was passed to it. This has been corrected.

  #1745 #1746

• Enhancement #1433: Support UTF-16 encoding and process Byte Order Mark

  On Windows, text editors commonly leave a Byte Order Mark at the beginning of the file to define which encoding is used (oftentimes UTF-16). We've added code to support processing the BOMs in text files, like the exclude files, the password file and the file passed via --files-from. This does not apply to any file being saved in a backup, those are not touched and archived as they are.

  #1433 #1738 #1748

• Enhancement #1561: Allow using rclone to access other services

  We've added the ability to use rclone to store backup data on all backends that it supports. This was done in collaboration with Nick, the author of rclone. You can now use it to first configure a service, then restic manages the rest (starting and stopping rclone). For details, please see the manual.

  #1561 #1657 https://rclone.org

• Enhancement #1665: Improve cache handling for restic check

  For safety reasons, restic does not use a local metadata cache for the restic check command, so that data is loaded from the repository and restic can check it's in good condition. When the cache is disabled, restic will fetch each tiny blob needed for checking the integrity using a separate backend request. For non-local backends, that will take a long time, and depending on the backend (e.g. B2) may also be much more expensive.

  This PR adds a few commits which will change the behavior as follows:

  • When restic check is called without any additional parameters, it will build a new cache in a temporary directory, which is removed at the end of the check. This way, we'll get readahead for metadata files (so restic will fetch the whole file when the first blob from the file is requested), but all data is freshly fetched from the storage backend. This is the default behavior and will work for almost all users.

  • When restic check is called with --with-cache, the default on-disc cache is used. This behavior hasn't changed since the cache was introduced.

  • When --no-cache is specified, restic falls back to the old behavior, and read all tiny blobs in separate requests.

  #1665 #1694 #1696

• Enhancement #1721: Add cache command to list cache dirs

  The command cache was added, it allows listing restic's cache directoriers together with the last usage. It also allows removing old cache dirs without having to access a repo, via restic cache --cleanup

  #1721 #1749

• Enhancement #1758: Allow saving OneDrive folders in Windows

  Restic now contains a bugfix to two libraries, which allows saving OneDrive folders in Windows. In order to use the newer versions of the libraries, the minimal version required to compile restic is now Go 1.9.

  #1758 #1765

• Enhancement #549: Rework archiver code

  The core archiver code and the complementary code for the backup command was rewritten completely. This resolves very annoying issues such as 549. The first backup with this release of restic will likely result in all files being re-read locally, so it will take a lot longer. The next backup after that will be fast again.

  Basically, with the old code, restic took the last path component of each to-be-saved file or directory as the top-level file/directory within the snapshot. This meant that when called as restic backup /home/user/foo, the snapshot would contain the files in the directory /home/user/foo as /foo.

  This is not the case any more with the new archiver code. Now, restic works very similar to what tar does: When restic is called with an absolute path to save, then it'll preserve the directory structure within the snapshot. For the example above, the snapshot would contain the files in the directory within /home/user/foo in the snapshot. For relative directories, it only preserves the relative path components. So restic backup user/foo will save the files as /user/foo in the snapshot.

  While we were at it, the status display and notification system was completely rewritten. By default, restic now shows which files are currently read (unless --quiet is specified) in a multi-line status display.

  The backup command also gained a new option: --verbose. It can be specified once (which prints a bit more detail what restic is doing) or twice (which prints a line for each file/directory restic encountered, together with some statistics).

  Another issue that was resolved is the new code only reads two files at most. The old code would read way too many files in parallel, thereby slowing down the backup process on spinning discs a lot.

  #549 #1286 #446 #1344 #1416 #1456 #1145 #1160 #1494

• Enhancement #1552: Use Google Application Default credentials

  Google provide libraries to generate appropriate credentials with various fallback sources. This change uses the library to generate our GCS client, which allows us to make use of these extra methods.

  This should be backward compatible with previous restic behaviour while adding the additional capabilities to auth from Google's internal metadata endpoints. For users running restic in GCP this can make authentication far easier than it was before.

  #1552 https://developers.google.com/identity/protocols/application-default-credentials

• Enhancement #1477: Accept AWS_SESSION_TOKEN for the s3 backend

  Before, it was not possible to use s3 backend with AWS temporary security credentials(with AWS_SESSION_TOKEN). This change gives higher priority to credentials.EnvAWS credentials provider.

  #1477 #1479 #1647

• Enhancement #1648: Ignore AWS permission denied error when creating a repository

  It's not possible to use s3 backend scoped to a subdirectory(with specific permissions). Restic doesn't try to create repository in a subdirectory, when 'bucket exists' of parent directory check fails due to permission issues.

  #1648

• Enhancement #1649: Add illumos/Solaris support

  #1649

• Enhancement #1709: Improve messages restic check prints

  Some messages restic check prints are not really errors, so from now on restic does not treat them as errors any more and exits cleanly.

  #1709 https://forum.restic.net/t/what-is-the-standard-procedure-to-follow-if-a-backup-or-restore-is-interrupted/571/2

• Enhancement #827: Add --new-password-file flag for non-interactive password changes

  This makes it possible to change a repository password without being prompted.

  #827 #1720 https://forum.restic.net/t/changing-repo-password-without-prompt/591

• Enhancement #1735: Allow keeping a time range of snaphots

  We've added the --keep-within option to the forget command. It instructs restic to keep all snapshots within the given duration since the newest snapshot. For example, running restic forget --keep-within 5m7d will keep all snapshots which have been made in the five months and seven days since the latest snapshot.

  #1735

• Enhancement #1782: Use default AWS credentials chain for S3 backend

  Adds support for file credentials to the S3 backend (e.g. ~/.aws/credentials), and reorders the credentials chain for the S3 backend to match AWS's standard, which is static credentials, env vars, credentials file, and finally remote.

  #1782