Our great sponsors
-
This one is quite unclear:
> We have added checksums for various backends so data uploaded to a backend can be checked there.
What do you mean checksums? All data is already stored in files with as filename the sha256sum of the contents, so clearly it's all already checksummed and can be verified right?
Looking into the changelog entry[1], this is about verifying the integrity upon uploading:
> The verification works by informing the backend about the expected hash of the uploaded file. The backend then verifies the upload and thereby rules out any data corruption during upload. \n\n [...] besides integrity checking for uploads [this] also means that restic can now be used to store backups in S3 buckets which have Object Lock enabled.
Object lock is mentioned in passing (and only in this more detailed info) but this is a big one. S3 docs:
> Object Lock can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
i.e. ransomware protection. Good luck wiping backups if your backup host refuses to overwrite or delete the files. And you know the files are good because they match their hash.
Extortion is still a thing, but if people would use this, it more-or-less wipes out the attack vector of ransomware. The only risk is if the attacker is in your systems long enough to outlast your retention period. Did anyone say "test your backups"?
For self-hosting, restic has a custom back-end called rest-server[2] for that which supports a so-called "append-only mode" (no overwriting or deleting). I worked on the docs for this[3] together with rawtaz and MichaelEischer to make this more secure, because eventually, of course, your disks are full or you want to stop paying for legacy data on S3, and an attacker could have added dummy backups to fool your automatic removal script into thinking it needs to leave only the dummy backups. Using the right retention options, this attack cannot happen.
Others are doing some pretty cool stuff in the backup sphere as well, e.g. bupstash[4] has public key encryption so you don't need to have the decryption keys as a backup client.
[1] https://github.com/restic/restic/releases/v0.13.0
[2] https://github.com/restic/rest-server/
[3] https://restic.readthedocs.io/en/latest/060_forget.html#secu...
-
Restic and BorgBackup really seem to be the favored solutions out there. Restic for encryption, Borg for deduplication. Or maybe bacula if you want pull based backups instead of push based.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
rest-server
Rest Server is a high performance HTTP server that implements restic's REST backend API.
This one is quite unclear:
> We have added checksums for various backends so data uploaded to a backend can be checked there.
What do you mean checksums? All data is already stored in files with as filename the sha256sum of the contents, so clearly it's all already checksummed and can be verified right?
Looking into the changelog entry[1], this is about verifying the integrity upon uploading:
> The verification works by informing the backend about the expected hash of the uploaded file. The backend then verifies the upload and thereby rules out any data corruption during upload. \n\n [...] besides integrity checking for uploads [this] also means that restic can now be used to store backups in S3 buckets which have Object Lock enabled.
Object lock is mentioned in passing (and only in this more detailed info) but this is a big one. S3 docs:
> Object Lock can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
i.e. ransomware protection. Good luck wiping backups if your backup host refuses to overwrite or delete the files. And you know the files are good because they match their hash.
Extortion is still a thing, but if people would use this, it more-or-less wipes out the attack vector of ransomware. The only risk is if the attacker is in your systems long enough to outlast your retention period. Did anyone say "test your backups"?
For self-hosting, restic has a custom back-end called rest-server[2] for that which supports a so-called "append-only mode" (no overwriting or deleting). I worked on the docs for this[3] together with rawtaz and MichaelEischer to make this more secure, because eventually, of course, your disks are full or you want to stop paying for legacy data on S3, and an attacker could have added dummy backups to fool your automatic removal script into thinking it needs to leave only the dummy backups. Using the right retention options, this attack cannot happen.
Others are doing some pretty cool stuff in the backup sphere as well, e.g. bupstash[4] has public key encryption so you don't need to have the decryption keys as a backup client.
[1] https://github.com/restic/restic/releases/v0.13.0
[2] https://github.com/restic/rest-server/
[3] https://restic.readthedocs.io/en/latest/060_forget.html#secu...
-
There is also https://github.com/restic/others which has some keywords (e.g. is it encrypted, does it do compression) for most FOSS backup solutions. It can be outdated or incomplete for some entries, though.
