Restic 0.13.0
restic.net
Restic 0.13.0
1–10 of 68 posts
Re: Restic 0.13.0
#2Besides Homebrew, restic is also available via MacPorts: https://ports.macports.org/port/restic/
Re: Restic 0.13.0
#3Unless it's for experimenting, I've stopped caring for backup solutions other than borg and zfs as the only way to prove their stability is to have them exist for a while without big complaints and new ones all seem to have complaints.
Just having no data loss isn't enough which is the absolute base point but huge memory consumption and other operational issues are also showstoppers.
Re: Restic 0.13.0
#4I'm so glad to finally see the --dry-run option in Restic.
Re: Restic 0.13.0
#5Still no compression?
Re: Restic 0.13.0
#6Where can I read about the best solutions for backups? For nerdy people
Re: Restic 0.13.0
#7Where can I read about the best solutions for backups? For nerdy people
Restic and BorgBackup really seem to be the favored solutions out there. Restic for encryption, Borg for deduplication and compression. Or maybe bacula if you want pull based backups instead of push based.
Re: Restic 0.13.0
#8Still no compression?
I'm afraid not: https://github.com/restic/restic/issues/21
Re: Restic 0.13.0
#9Where can I read about the best solutions for backups? For nerdy people
When talking about backups for nerds, https://www.rsync.net/ always deserves a mention.
Re: Restic 0.13.0
#10This point hides a lot of goodness in something that I didn't even understand on the first read:
> - We have added checksums for various backends so data uploaded to a backend can be checked there.
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 somewhere down the changelog, but it's a big feature. 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 file hoster refuses to overwrite or delete the files. And you know Amazon didn't mess with the files because they're authenticated.
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 and creates useless backups in the meantime so you're not tipped off. Did anyone say "test your backups"?
For self-hosting, restic has a custom back-end called rest-server[2] 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 outdated snapshots 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...