But then I got to thinking, if I'm going to do a clean Fedora install for the tripwire (it's best practice) I might as well try Fedora Silverblue[2]. Silverblue is an immutable system so it kinda makes a tripwire less useful because no one can change any system files. Only files in your home directory and /etc can be modified statefully.
https://github.com/Tripwire/tripwire-open-source/#open-sourc...
What that won't do is save you from malicious code inserted into 3rd party content (script libraries, etc.) that you load from a CDN. If you're worried about that, you should make a copy of a verified version and serve it yourself.
Also, it can be difficult in a lot of environments to sustain more than 100mbps write to a remote, off-site system - halving the stored data can be a much bigger win then.
All that said, it's interesting to see that a) duplicity seems slow, and b) very consistent in terms of speed. I wonder if there's some low-hanging fruit for optimization there.
Personally I've had some luck using backupninja[b] in combination with duplicity. It's one of the few Free alternatives that allow the backup-system to encrypt "one-way" - so that compromising the backup-system doesn't immediately give read access to encrypted backups. It's a bit complicated to set it up for separate encrypt-to and signing keys though :/
[s] Today I would probably recommend ZFS - but I've always wanted to give NILFS2 a real test, especially on solid-state disks: http://nilfs.osdn.jp/en/
[c] https://github.com/Tripwire/tripwire-open-source
https://github.com/integrit/integrit (Speaking of projects that might be fun/useful to redo in a safe language like rust or go - it would appear this would be a prime example, btw. On the whole moving integrity to the fs, as with zfs might be the better option, though).