The release of the restic 0.15 backup system has been published, providing storage of backup copies in encrypted form in a versioned repository. The system was initially designed to ensure that backup copies are stored in untrustworthy environments, and that if a backup copy falls into the wrong hands, it should not compromise the system. It is possible to define flexible rules to include and exclude files and directories when creating a backup (the format of the rules is similar to rsync or gitignore). Supports work on Linux, macOS, Windows, FreeBSD and OpenBSD. The project code is written in Go and distributed under the BSD license.
Backups can be stored in a local file system, on an external server with SFTP/SSH or HTTP REST access, in Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage and Google Cloud Storage clouds, as well as in any storage for which there are backends rclone. A special rest server can also be used to organize storage, which provides higher performance compared to other backends and can work in add-only mode, which will not allow you to delete or change backups in case the source server is compromised and access to encryption keys.
Snapshots are supported, reflecting the state of a particular directory with all files and subdirectories at a certain point in time. Each time a new backup is created, a snapshot associated with it is created, allowing you to restore the current state. It is possible to copy snapshots between different repositories. To save traffic, only changed data is copied during the backup process. To visually assess the contents of the repository and simplify recovery, a snapshot with a backup can be mounted in the form of a virtual partition (mounted using FUSE). It also provides commands for analyzing changes and extracting files selectively.
The system does not manipulate entire files, but floating-size blocks selected using the Rabin signature. Information is stored in relation to content, not file names (data-associated names and objects are defined at the block metadata level). Based on the SHA-256 hash of the content, deduplication is performed and unnecessary data copying is eliminated. On external servers, information is stored in encrypted form (SHA-256 is used for checksums, AES-256-CTR is used for encryption, and Poly1305-AES-based authentication codes are used to guarantee integrity). It is possible to verify the backup copy using checksums and authentication codes to confirm that the integrity of the files is not compromised.
In the new version:
- A new rewrite command has been implemented that allows you to remove unnecessary data from a snapshot when files that were not originally intended for backup (for example, files with confidential information or very large logs of no value) got into the backup due to an oversight.
- The β--read-concurrencyβ option has been added to the backup command to set the level of parallelization when reading files, allowing you to speed up copying on fast drives such as NVMe.
- The "--no-scan" option has been added to the backup command to disable the scanning stage of the file tree.
- The prune command has significantly reduced memory consumption (up to 30%).
- Added "--sparse" option to the restore command to efficiently restore files with large empty areas.
- For the Windows platform, support for restoring symbolic links has been implemented.
- macOS has added the ability to mount a repository with backups using macFUSE.
Source: opennet.ru