Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bup – towards the perfect backup

wrouesnel.github.io

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Bup – towards the perfect backup

#61

Post by rsync »

kijin wrote: post #32
mappu wrote: post #14

A shoutout for attic https://attic-backup.org/ Attic is one of the new-generation hash-backup tools (like obnam, zbackup, Vembu Hive etc). It provides encrypted incremental-forever (unlike duplicity, duplicati, rsnapshot, rdiff-backup, Ahsay etc) with no server-side processing and a convenient CLI interface, and it does let you prune old backups. All other common tools seem to fail on one of the following points - In…

Sorry, but "Untrusted remote storage" and "No server-side processing" are exactly the opposite of what I need. If the original box is ever compromised, I don't want the attacker to gain any access to the backup. If you use a dumb storage like S3 as your backup server, you need to store your keys on the original box, and anyone who gains control of the original box can destroy your S3 bucket as well. Ditto for any SSH…

I really try to restrain myself when a backup article pops up on HN, but there are two things you raise here that I'd like to address ... first:

"Ditto for any SSH-based backup scheme that requires keys to be stored on the original box. A compromised box could also lie about checksums, silently corrupting your backups."

This is a good thought - you should indeed be thinking about an attacker compromising your system and then using the SSH keys they find and wiping out the offsite backup. All they need to do is look into cron and find the jobs that point to the servers that ...

So how do we[1] solve this ? All of our accounts have ZFS snapshots enabled by default. You may not be aware of it, but ZFS snapshots are immutable. Completely. Even root can't write or delete in a snapshot. The snapshot has to be deliberately destroyed with ZFS commands run by root - which of course, the attacker would not have access to. It's a nice safety net - even if your current copy is wiped out, you have your ZFS snapshots in place.[2]

"Backups should be pulled from the backup box, not pushed from the original box."

This was the tipping point - I had to comment. Since day one, we have, free of charge, set up "pull jobs" for any customer that asks for it. Works just like you'd like it to on whatever schedule they can cram into a cron format. It's a value add we've always been happy to provide.

[1] You know who we are.

[2] Yes, if you don't notice for 7 days and 4 weeks that the attacker has wiped you out, at that point your snapshots will all rotate into nothingness as well. Nothing's perfect.

Re: Bup – towards the perfect backup

#62

Post by dunham »

kijin wrote: post #32
mappu wrote: post #14

A shoutout for attic https://attic-backup.org/ Attic is one of the new-generation hash-backup tools (like obnam, zbackup, Vembu Hive etc). It provides encrypted incremental-forever (unlike duplicity, duplicati, rsnapshot, rdiff-backup, Ahsay etc) with no server-side processing and a convenient CLI interface, and it does let you prune old backups. All other common tools seem to fail on one of the following points - In…

Sorry, but "Untrusted remote storage" and "No server-side processing" are exactly the opposite of what I need. If the original box is ever compromised, I don't want the attacker to gain any access to the backup. If you use a dumb storage like S3 as your backup server, you need to store your keys on the original box, and anyone who gains control of the original box can destroy your S3 bucket as well. Ditto for any SSH…

If you use a dumb storage like S3 as your backup server, you need to store your keys on the original box

I believe this isn't strictly necessary if you use asymmetric cryptography (e.g. curve25519). For a file, generate a temporary key pair, use it and the backup's public key to encrypt the file, then throw out the private key and send the encrypted file + public key to the server.

Apple uses this technique to move files to the "Accessible while unlocked" state without having the key for that state (i.e. while the device is locked).

Re: Bup – towards the perfect backup

#63

Post by mappu »

witten wrote: post #52
mappu wrote: post #14

A shoutout for attic https://attic-backup.org/ Attic is one of the new-generation hash-backup tools (like obnam, zbackup, Vembu Hive etc). It provides encrypted incremental-forever (unlike duplicity, duplicati, rsnapshot, rdiff-backup, Ahsay etc) with no server-side processing and a convenient CLI interface, and it does let you prune old backups. All other common tools seem to fail on one of the following points - In…

If someone is looking at trying attic and wants something a little nicer to configure and run than the very basic shell script from attic's Quick Start[1], check out the wrapper script I wrote to make this a little easier[2]. It's still somewhat "1.0" right now, but it does the basics for me. See the included sample config files for an idea of how the configuration works.[3] [1] https://attic-backup.org/quickstart.ht…

I made my own wrapper as well: http://code.ivysaur.me/atticinst.html

Although upon reading yours, it looks they perform somewhat different tasks.

Re: Bup – towards the perfect backup

#64

Post by rsync »

corford wrote: post #42
kijin wrote: post #32

Earlier quoted context omitted.

Sorry, but "Untrusted remote storage" and "No server-side processing" are exactly the opposite of what I need. If the original box is ever compromised, I don't want the attacker to gain any access to the backup. If you use a dumb storage like S3 as your backup server, you need to store your keys on the original box, and anyone who gains control of the original box can destroy your S3 bucket as well. Ditto for any SSH…

I use duplicity + rsync.net and have wondered about this attack vector. My solution (which admittedly only protects against remote backups being deleted by an attacker, not read) is: 1. Use sub accounts on rsync.net so backups from different parts of the system are isolated from each other. 2. Use a different GPG keypair and passphrase for each host being backed up. 3. Have an isolated machine out on the internet som…

Your rsync.net account has ZFS snapshots enabled - at the very least, the smallest default is 7 daily snapshots.

The ZFS snapshots are immutable. Completely. Even root can't write or delete in a snapshot. The snapshot has to be deliberately destroyed with ZFS commands run by root - which of course, the attacker would not have access to.

Also, thanks for your business :)

Re: Bup – towards the perfect backup

#65

Post by rsync »

uint32 wrote: post #54

Like any good hacker I got tired of other solutions that didn't quite match my needs and made my own dropbox-like backup/sync using only rsync, ssh and encfs. https://github.com/avdd/rsyncsync Not polished, but it's working for me. - only runs on machines I control - server requirement is only rsync, ssh and coreutils - basic conflict detection - encfs --reverse to encrypt locally, store remotely - history is rsnapsh…

How does that compare to this:

https://raymii.org/s/articles/Set_up_your_own_truly_secure_e...

Re: Bup – towards the perfect backup

#66

Post by mappu »

kijin wrote: post #48
mappu wrote: post #41

Earlier quoted context omitted.

By pulling backups, you're giving the backup box full control over your computer, meaning that yes it must be more trustworthy. Push backups can indeed allow the initiator to wreck the remote state. But in the modern commercial market, who are you going to trust as your backup box provider? A USA company subject to NSLs? Run your own in a rack somewhere? Having an untrusted server greatly decreases cost and increases…

> By pulling backups, you're giving the backup box full control over your computer Not really. On my production boxes, I usually set up a "backup" account and give it read-only access to paths that need to be backed up. Nothing fancy, just standard POSIX filesystem permissions. The backup box uses this account to ssh in, so it can only read what it needs to read, and it can never write anything to the production box.…

I guess it depends on your security model. With one single pull backup,

- if your backup box is on another network then it can be coerced into malicious reads (leaking private information, trade secrets, your competitive advantage etc).

- if it's on the same network then it's subject to your same failure patterns.

Push backup has some disadvantages, but there's a lot of peace-of-mind in never (intentionally) granting additional users access to the unencrypted data.

Two-tier is one approach. There's another comment in this thread about snapshotting filesystems (ZFS, or i suppose LVM snapshots might be easier) which would be another method of addressing concerns about the client tampering with the backed up data.

Re: Bup – towards the perfect backup

#67

Post by jlebar »

cperciva wrote: post #43
ars wrote: post #39

Earlier quoted context omitted.

At present I need backup software, not a backup service. How are you calculating a diff of an encrypted file? I looked through the technical documentation but if it explains it I missed it.

Tarsnap splits data into context-dependent chunks, then compares them via their hashes to figure out what new data needs to be uploaded.

This is interesting, because the size of a file's encrypted chunks now leaks information about the file's plaintext. I suppose you have some minimum chunk size, and that's one way to keep from leaking too much information as a fraction of the overall file size. But if a file is modified many times, it seems to me that you'd have to be very careful not to leak a substantial amount of data to a clever attacker.

Have you thought about how to quantify this tradeoff?

I suppose you could pad each encrypted chunk so they're all the same size, but then if you don't want to waste a ton of space you'd have to restrict your chunking algorithm to output chunks with relatively similar sizes, at which point you lose some of the benefits of chunking.

Re: Bup – towards the perfect backup

#68

Post by jlebar »

Adding a plug for git-annex. https://git-annex.branchable.com/

git annex is for more than just backups. In particular, it lets you store files on multiple machines and retrieve them at will. This lets you do backups to e.g. S3, but it also lets you e.g. store your mp3 collection on your NAS and then easily copy some files to your laptop before leaving on a trip. Any changes you make while you're offline can be sync'ed back up when you come back online.

You can prune old files in git-annex [1], and it also supports encryption. git-annex deduplicates identical files, but unlike Attic &co, it does not have special handling of incremental changes to files; if you change a file, you have to re-upload it to the remote server.

git-annex is actively developed, and I've found the developer to be really friendly and helpful.

[1] You can prune the old files, but because the metadata history -- basically, the filename to hash mapping -- is stored in git, you can't prune that. In practice you'd need to have a pretty big repository with a high rate of change for this to matter.

Edited for formatting.

Re: Bup – towards the perfect backup

#69

Post by anarcat »

mappu wrote: post #14

A shoutout for attic https://attic-backup.org/ Attic is one of the new-generation hash-backup tools (like obnam, zbackup, Vembu Hive etc). It provides encrypted incremental-forever (unlike duplicity, duplicati, rsnapshot, rdiff-backup, Ahsay etc) with no server-side processing and a convenient CLI interface, and it does let you prune old backups. All other common tools seem to fail on one of the following points - In…

i was wondering how this would compare with bup. so i did a very quick benchmark: http://anarcat.koumbit.org/2014-11-18-bup-vs-attic-silly-ben...

take it with a grain of salt, but i am surprised to say that attic is at least as fast as bup.

Re: Bup – towards the perfect backup

#70

Post by beagle3 »

Haven't seen this mentioned - but, since bup de-duplicates chunks (and thus may take very little space - e.g., when you backup a 40GB virtual machine, each snapshots takes little more than the actual changes inside the virtual machine), every byte of the backup is actually very important and fragile, as it may be referenced from thousands of files and of snapshots. This is of course true for all dedupping and incremental backups.

However, bup goes one step farther and has builtin support for "par2" which adds error correction - in a way, it efficiently re-duplicates chunks so that whichever one (or two, or however many you decide) break, you can still recover the complete backup.

Post reply on HN