Live data from Hacker News

Bup – An efficient backup system based on the git packfile format

bup.github.io

31–40 of 40 posts

Re: Bup – An efficient backup system based on the git packfile format

#32
post #12
post #5

Earlier quoted context omitted.

I've used rdiff-backup daily for years, but recently needed to store backups on machines I don't control, so I gave duplicity[1] a try. It encrypts, doesn't need to be installed on the target host and is simple to use if you're already familiar with rdiff-backup and gpg. Test restores were simple, but were all first generation, so not really a good test (but there are hints you'll want to prune backups to one month's…

One of the downsides with duplicity is you have to provide your GPG privkey password in ENV in order for dedupe with GPG encryption to work.

You don't. You can use gpg-agent with --use-agent.

  duplicity inc \
    --sign-key $PGP_PRIV_ID \
    --encrypt_key $PGP_PUB_ID \
    --use-agent \
    ${source} ${dest}

Re: Bup – An efficient backup system based on the git packfile format

#33
post #9

Kind of related: What do you use to backup binary files like photos? At the moment I've just got copies on old USB drives, but I'd like to put something on AWS Glacier too.

git-annex. It supports multiple external remotes, including USB drives, Glacier[1], bup and ddar[2]. You can keep files on any combination of the external remotes for redundancy and cost management. It keeps track of what is where, so you don't have to. The only catch is that you have to make sure to back up the (metadata-only) git repository itself also, and maintaining this backup on anything that is not a direct f…

git-annex website says[1] it is not supposed to be a backup solution:

> git-annex is not a backup system. It may be a useful component of an archival system, or a way to deliver files to a backup system

With this in mind, can we treat it as a backup tool? Assuming backing up the git repository itself as you mentioned.

[1] http://git-annex.branchable.com/not/

Re: Bup – An efficient backup system based on the git packfile format

#35
post #16

Earlier quoted context omitted.

Don't know if you are aware, but http://www.synctus.com/ddar/ is currently down

I'm aware, thanks. https://github.com/basak/ddar/wiki contains the content, thanks to a kind contributor. I should probably deprecate the old URL and remove references to it.

Perhaps you could have it redirect to the wiki?

Re: Bup – An efficient backup system based on the git packfile format

#36
post #17

I wonder how this compares to venti. Being able to mount with FUSE can be an interesting feature, specially if it can work well even over the network (maybe with some kind of cache, like fossil).

bup can mount the backups with FUSE too. It also have a web interface with WEBDAV support, which our graphists uses to recover their old creations.

Re: Bup – An efficient backup system based on the git packfile format

#37

Currently, we're using Duplicity for our backups, going to Amazon S3. I've looked a some of the newer options like Bup, Attic, Obnam etc. However, none of them seem to support S3 as an endpoint, which is a shame. They all seem to need a full-fledged *nix server on the other end. Does anybody know of any of these new-fangled de-dupe backup apps that works with just S3?

Not technically a backup app, but camlistore (http://camlistore.org/) kind of does that:

- you push your files to it

- it optionally encrypts the content and hierarchy

- and stores it pretty much anywhere it can handle (on your disk, on S3, on MongoDB, on GCS, on another instance of camlistore, ...)

Re: Bup – An efficient backup system based on the git packfile format

#38
post #12

Earlier quoted context omitted.

One of the downsides with duplicity is you have to provide your GPG privkey password in ENV in order for dedupe with GPG encryption to work.

You don't. You can use gpg-agent with --use-agent. duplicity inc \ --sign-key $PGP_PRIV_ID \ --encrypt_key $PGP_PUB_ID \ --use-agent \ ${source} ${dest}

Which would require interactive usage or for you to save your passphrase in a system keychain, no?

Re: Bup – An efficient backup system based on the git packfile format

#39
post #4
post #2

When I had to pick a backup system, I considered Bup until I saw that there were no way to prune old backup ( https://github.com/bup/bup/blob/master/README.md#things-that... ). This is really a stopblocker for me. Obnam ( http://obnam.org ) is a similar tool but support forgetting old generations. However, it still suffers for youth problems and tends to corrupt backup repository when pruning old data on a remote ser…

I wrote ddar before I knew about bup. It works in a similar way, but uses sqlite and flat files for chunk storage, so removing old archives isn't a problem. I'm not aware of any corruption issues in ddar; I rely on sqlite for integrity. I modeled ddar after Tarsnap.

ddar sounds like it could be really useful. However, it looks like the last functional change to code base on GitHub was a year and a half ago. What do you think the future of the project is? For something like backups, I wouldn't want to invest into a tool that has no prospect of support.

Re: Bup – An efficient backup system based on the git packfile format

#40

Currently, we're using Duplicity for our backups, going to Amazon S3. I've looked a some of the newer options like Bup, Attic, Obnam etc. However, none of them seem to support S3 as an endpoint, which is a shame. They all seem to need a full-fledged *nix server on the other end. Does anybody know of any of these new-fangled de-dupe backup apps that works with just S3?

S3QL may be a good fit for your needs. It's a FUSE filesystem for S3 that supports encrypted dedup snapshots. You can do backups by rsyncing your current state into the filesystem and snapshotting it. I considered using it for my backups but ended up choosing Attic, so I can't say how well it works in practice.

Unfortunately S3QL uses MAC-then-encrypt[1], which is pretty strongly discouraged[2]. Very nice there's a detailed writeup on the details in the docs though, wish more projects did that.

1: http://www.rath.org/s3ql-docs/impl_details.html (last paragraph) 2: http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....

Post reply on HN