Server requirements are a server with ssh access, and the snebu binary installed (optionally suid to a non-privileged backup user account, so that granular permissions can be employed for other accounts). I plan to make the encrypted key storage optional, but that would require that you manage the key file backup separately, and doesn't get you much more security (assuming you have an adequately strong passphrase). This way you can restore a client even if the keyfile is destroyed. On restore, you will be prompted (client-side) for the passphrase. And the RSA private key is passphrase encrypted, and sent along with the tar header to the server. That way you can have encrypted backups without needing to have a password sitting in plain text on the client. The idea is that the encryption itself is AES-256-GCM, with a random key, which is encrypted with RSA public key. What tarcrypt does is it takes a standard tar file input, compresses/encrypts the file data, and outputs a tar file with some extended headers that contain info about the compression/encryption, including the RSA public key fingerprint used to encrypt the data, an HMAC, and the encrypted (passphrase-protected) private key (this can be made optional). Metadata gets put in the SQLite DB.įor data encryption (the main part is completed, but need to expand the backend to recognize encrypted data, should be finished shortly) - the output of "tar" is piped through "tarcrypt". ![]() Tar, in this case, is used to serialize the data, which gets extracted on the remote end (compressed and stored as sha1-named files ). The client then tar's this smaller file list to stream to the remote server. A full manifest (list of file names and metadata ) is sent over the wire, and a return list of files that are needed to complete the snapshot (essentially changed / new files) is returned to the client. The communications is handled via ssh, so yes I would use it over the internet as the transfers are streaming. ![]() Can help with thwarting crypto viruses that try to delete backups. Or have an administrative user that can expire old backups but not read backups, for example. Oh, and the most recent release supports granular user permissions, so you can grant a host (via an SSH account on the backup server) permissions to create backups, but not delete them. My next project is a Web based GUI (maybe an Electron based client-side GUI too, depending on what makes sense). ![]() ![]() The client-side encryption module is already in the Git repository, but there is no documentation for it yet. Backend side compresses, deduplicates, snapshots, handles a number of systems easily, and is fairly fast due to using SQLite for the metadata catalog.Ī couple weeks ago I finished a client-side encryption module, got another weekend's worth of work to integrate encryption support into the back end. What's different from Restic or Borg/Attic, is that the main "smarts" lives on the backup server (the Snebu binary), whereas the client side just uses find / tar to serialize the data. I wrote this about 8 years ago for my personal needs, because rsync / snapshot backups were running out of steam for me. There is also Snebu (Github repo at /derekp7/snebu).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |