What does HackerNews think of rest-server?

Rest Server is a high performance HTTP server that implements restic's REST backend API.

Language: Go

Similar here. Termux with restic, so it does deduplication and encryption and such (also compression since a few months but haven't turned it on yet). I also enjoy having the same backup mechanism for my phone, laptop, and server.

On local laptop: run https://github.com/restic/rest-server/ to accept the incoming data, then (if 1234 is the port that rest-server runs on):

    user@laptop:~$ ssh -R 1234:localhost:1234 root@phone
    root@phone:~# restic backup /data/ -r rest:http://user:password@localhost:1234 -x --exclude /data/media/0/Android/data/com.spotify.music/
Can also do this without root and just sync pictures, but this way you actually get all your data.

Or set up a rest-server on a remote system somewhere, since it's encrypted it doesn't matter where you run it so long as you trust the remote end not to delete your files on the same day as your phone crashes.

Rsync is simpler if you don't need features like encryption (at least to get started: any backup mechanism today is better than a perfect backup mechanism tomorrow).

This 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...

[4] https://github.com/andrewchambers/bupstash/

The append-only mode can be implemented using https://github.com/restic/rest-server or services like rsync.net that offer read-only zfs snapshots. Doesn’t solve the asymmetric crypto of course.
You can do it with the restic server ( https://github.com/restic/rest-server ). Don't know if it is implemented in the S3 backend.