(Full disclosure -- I'm the primary maintainer / author of Snebu) I would like to see how these compare against Snebu (https://www.snebu.com https://www.snebu.

(Full disclosure -- I'm the primary maintainer / author of Snebu) I would like to see how these compare against Snebu (https://www.snebu.com https://www.snebu.com), now that it supports encryption. The project has been around for a number of years, but had a bit of a code refactoring when encryption was added. The interesting approach that it take is it uses GNU tar to grab the files, optionally passes it through the included Tarcrypt (https://www.snebu.com/tarcrypt.html https://www.snebu.com/tarcrypt.html) filter, (which LZOP compresses then encrypts the file contents while keeping tar-compliant headers within the tar file). The tar file is then ingested by the Snebu backend, each backed up file is written to the data store (vault) and compressed (if it arrived in plain text, instead of processed via tarcrypt). The metadata (filenames, size, owner, permissions... etc, client name, backupdate, retention schedule) is stored in an SQLite DB (the backup catalog). The encryption (handled exclusively by tarcrypt so the audit footprint is small) uses public key encryption (in the usual manner -- the RSA public key encrypts a randomly generated key, which in turn is used with AES-256). You can specify multiple RSA key files, so you can have a backup key (or keys) if you want. You can also change keys any time. Since backupsets are snapshot/deduplicated, you may (most likely will) have files in a restore set that are encrypted with different RSA keys. Not a problem, you will be prompted for the passphrase for each one at the beginning of the restore (and if you use the same passphrase when changing out keys, you only have to enter it once). (BTW, tarcrypt can be used outside of Snebu -- it may eventually get spun off as its own project). Other unique features that others lack: * Key files are for a backup set, not tied to the repository * Both push and pull backups are supported -- pull backups (initiated by the server) don't need any agent or client software installed (except tarcrypt if encryption is used) * Granular user access permissions -- you can grant a user access to backup, but not delete, or access to restore specific hosts, etc. * Multiple-client support. You can have dozens of clients on the same backend repository (I have about 75 or so in a development lab environment). * Low dependency count -- doesn't require specific versions of python or other dependencies. Written in C, depends on lzo2, sqlite3, openssl. Main drawback compared to tools such as Restic is that it is server-based, in that a client can't back up to "dumb storage". Compared to Borg and Restic, only file-level deduplication is performed. Compression is a bit weaker (but fast), so size is a bit bigger than Borg (but smaller than Restic). Snebu has a smaller developer base. This should be easier to fix when the internal code structure documentation is finished. Automated end-to-end tests aren't included in the repository. This is being addressed.