Re:Bup – towards the perfect backup
by Smudge on Monday November 17, 2014 @05:29PM
(#8621119)
I can see how this would be theoretically possible in the same way I could see using `git filter-branch` to remove one or more commits from a code repository. But as it requires walking back up the tree to recalculate all of the commit hashes based on the new state of your files, I suspect it would be an extremely slow/expensive operation in bup's case. Someone who knows more about bup's internals can correct me if I'm wrong.
[ Parent
| on HN ]
true. and actually bup can't use git's tooling directly because of the different use cases it's optimized for. git won't make any use of bup's optimizations: midx (combination of multiple .idx files into a handful of bigger ones to reduce page faults during binary searches) and bloom filter.
git's tools, namely filter-branch and gc have been reported to work on limited-size bup repositories, but it very quickly eats up all ram and cpu and never finishes because of the sheer amount of objects that are usually stored in a bup repository
Isn't this exactly what Obnam does?
I suspect that Obnam doesn't cause all of the de-duplicated chunks to get so "entagled" (as bup puts it, in their readme).
There are existing discussions about the way bup pruning would have to work:
https://groups.google.com/forum/#!searchin/bup-list/prune/bu...
Sounds like they are actually making progress on it.