I'm personally using restic[0] to create encrypted/de-duplicated backups. I use a local external drive and Backblaze B2 to push the snapshots to. There's no server to maintain.
The best thing about restic in my opinion is the ability to mount[1] the snapshots using FUSE to my machine without actually explicitly extracting the backup to a local directory.
Restic has some failure cases where it claims that backup was successful, when in fact some of your data was not backed up. This is just about the most horrifying failure case imaginable.
For example, if you take a backup of a bunch of files which includes TrueCrypt containers, and then you modify the containers and take a new backup, it will not back up the new data. Instead, it will look at file metadata to erroneously conclude that the container has not changed.
Now, some people argue that this is not an issue, because you can use non default configuration of TrueCrypt and/or Restic to prevent this problem. But how would a Restic user know that they need to do this?
I don't want to become an expert in the internals of the backup software I'm using. I just want it to work -- or at least fail in predictable ways.
For example, if you take a backup of a bunch of files which includes TrueCrypt containers, and then you modify the containers and take a new backup, it will not back up the new data. Instead, it will look at file metadata to erroneously conclude that the container has not changed.
Now, some people argue that this is not an issue, because you can use non default configuration of TrueCrypt and/or Restic to prevent this problem. But how would a Restic user know that they need to do this?
I don't want to become an expert in the internals of the backup software I'm using. I just want it to work -- or at least fail in predictable ways.