Bup – An efficient backup system based on the git packfile format
1–10 of 40 posts
Re: Bup – An efficient backup system based on the git packfile format
#2When 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 server.
I'm really looking forward for a mature and feature full backup system based on git principes. Bup or obnam might be one of those.
Re: Bup – An efficient backup system based on the git packfile format
#3I do a monthly offsite backup. I use rdiff-backup for plain text and 7z with encryption for data I want to keep private, but I am on the lookout for more efficient solutions. I looked at bup, but two things stop me from using it: no encryption, and inability to delete old backups to reclaim space. To me, attic (https://attic-backup.org/) looks attractive so this is what I am going to try soon.
Re: Bup – An efficient backup system based on the git packfile format
#4When 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.
Re: Bup – An efficient backup system based on the git packfile format
#5I do a monthly offsite backup. I use rdiff-backup for plain text and 7z with encryption for data I want to keep private, but I am on the lookout for more efficient solutions. I looked at bup, but two things stop me from using it: no encryption, and inability to delete old backups to reclaim space. To me, attic ( https://attic-backup.org/ ) looks attractive so this is what I am going to try soon.
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 worth). I haven't figured out an acceptable way to automate it, so I've been running it manually on an infrequent basis while I evaluate it. Give it a look, if you haven't already.
Re: Bup – An efficient backup system based on the git packfile format
#6I do a monthly offsite backup. I use rdiff-backup for plain text and 7z with encryption for data I want to keep private, but I am on the lookout for more efficient solutions. I looked at bup, but two things stop me from using it: no encryption, and inability to delete old backups to reclaim space. To me, attic ( https://attic-backup.org/ ) looks attractive so this is what I am going to try soon.
I have to give attic my support here. Recently collapsed around 2.5 TB of nightly database backups to about 50 GB. It is very simple to use.
Re: Bup – An efficient backup system based on the git packfile format
#7Kind 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.
Re: Bup – An efficient backup system based on the git packfile format
#8I do a monthly offsite backup. I use rdiff-backup for plain text and 7z with encryption for data I want to keep private, but I am on the lookout for more efficient solutions. I looked at bup, but two things stop me from using it: no encryption, and inability to delete old backups to reclaim space. To me, attic ( https://attic-backup.org/ ) looks attractive so this is what I am going to try soon.
I have to give attic my support here. Recently collapsed around 2.5 TB of nightly database backups to about 50 GB. It is very simple to use.
Allow me to plug atticmatic, a wrapper for attic that provides a config file, automatic backup pruning, etc:
Re: Bup – An efficient backup system based on the git packfile format
#9Kind 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 filesystem is painful.
[1] Through my tool, glacier-cli, for which git-annex has native support.
[2] I wrote ddar and the git-annex support for it.
Re: Bup – An efficient backup system based on the git packfile format
#10When 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…
Obnam I liked using, because I love the authors attention to testing and details. But I found it started taking longer and longer and longer to run a backup - to the point that it was crazy.
I switched to atic instead, which also started taking longer to run backups as more things changed, and longer still to check the archives, but it is still faster than obnam by a significant margin: