Glad you asked. First, Snebu goes back about 8 years, although the encryption code was developed more recently. That also explains thy it the hash is sha1 (at

Glad you asked. First, Snebu goes back about 8 years, although the encryption code was developed more recently. That also explains thy it the hash is sha1 (at the time the thinking was "it is good enough for Git"). Right now it is kept for unencrypted backups for backward compatibility with previous versions. But it is something I would like to address -- possibly by using sha-256 (or truncated sha256) or make it user selectable on new repositories. This will be on the next version, didn't want to make too many changes at once. However encrypted backups do use a sha256 HMAC. Compared to Borg and Restic, by making the system server-based, it does limit things like being able to add direc-to-cloud backup, but a future capability may be added to efficiently replicate a Snebu server backup to cloud. However what it gains is better manageability, especially if you are backing up a number of hosts to one repository. In my instance I'm backing up about 50 hosts with 14 daily, 6 weekly, and 12 monthly snapshots. Compared to Restic and Borg, it uses public key encryption (so you don't need to leave a sensitive symmetric key on your clients), but with HMAC-256 based hashes. So an attacker would need both your public key and the HMAC secret (only a one-way hash of the secret is stored on the server). The client reconstructs the HMAC key using the public key and the passphrase for the private key. Oh, and you can use multiple keys -- a client specific key, and a backup key (or more). Deduplication will work across all clients that share the same set of keys (the HMAC of all keys is used for the file storage hash). But for this attack scenario (forged data), you will need to keep the client key file safe and stored with appropriate permissions, and you can use a different key (and lose cross-client deduplication) across clients that are in different trust zones. As for the SQLite DB size -- on one of my installs the DB is taking 50 GB, and is storing over 1500 backup snapshots, from 73 hosts (CensOS and RHEL some with Oracle DBs), with a total of 4.5 TB of disk storage used. The SQLite DB is critical as it stores which file belongs to which directory path on which host -- so it should be backed up independently (at the end of the backup script I use sqlite3 commands to do a dump of it once a week and run a vacuum command). Todo: add these maintenance commands to the Snebu binary to limit the need to run the Sqlite3 CLI. Other features unique to Snebu -- you can have the server "pull" backups without installing an agent on the clients (the "tarcrypt" will still need to be on the client if encryption is needed). You can have the clients "push" data to the server using a restricted user account that allows backups but not deletes or restores, and have a separate restore ID for example. You can give different administrators IDs on the the backup server access to different groups of hosts in a look-but-don't-touch, etc. Another item I like -- let's say you tell it to expire all monthly backups older than 6 weeks. But then if the host hasn't successfully backed up in more than that time (say it has been taken offline), there is a default to keep the most recent 3 backups in a retention schedule, so you won't accidentally lose all you backups in this case (the "preserve" number can be adjusted via command line parameters).