[Borgbackup] Storage, CPU, RAM comparisons

Dmitry Astapov dastapov at gmail.com
Mon May 4 05:54:11 EDT 2020


If you clone the repo and try to run the test yourself, you will find that
it tries to run a binary called "attic", not "borg".
So the author chose to rename "borg" to "attic" because ... why exactly?

Granted, it tries to run it with borg command line keys, but overall this
is suspicions and renders test unreproducible out-of-the-box.

As others have stated, comparing different compression modes is also quite
meaningless. For example, after fixing the scripts in the repo in the
minimal way i ran them with lz4 and zstd compression and got:

861M linux-attic-storage.lz4
599M linux-attic-storage.zstd

As you can see, zstd is 69% of lz4, which is not all insignificant. You can
run it with zlib if you are curious.

To answer your original question:

>
> Maybe borg improved from attic, but its not the point. Borg, attic,
> duplicacy based on deduplication using massive higher storage space in
> relation to duplicity (and rdiff-backup?). I dont' understand why
> file-based delta is more storage efficient then deduplication which can
> consolidate chunks from all files in the repo. I expect the opposite
> storage use ratio comparison.
>

Let's remove the first backup of 12 and compare disk usage afterward, shall
we?
Oh, wait, you can't do it with duplicity and rdiff-backup, right? Not
without taking another full backup first.

In real-life scenarios when taking full backups could be prohibitively
expensive (especially scenarios like massive amounts of data over
high-latency low-speed links), rdiff-backup/duplicity approach becomes
simply unviable, disk space saving or not, because you either have to keep
all backups infinitely long (and eventually run out of storage space) or
you need to pay the price of full backup once in a while (which will likely
overshadow all the time/disk space savings you have made previously).

Eventually, implementing meaningful retention strategy with
duplicity/rdiff-backups becomes major pain in the back. Let's say that I
have 2Tb of photos on my computer which I want to backup on an hourly basis
over wifi and retain just a week of hourly backups. With borg, i pay the
price of transeffing all of 2Tb just once, and afterwards my backups are
proportional to the number of photos changed. With duplicity/rdiff-backup I
will have to upload 2Tb over wifi once a week.

So some fraction of extra space taken by bog will be manifests that tie
blocks in the storage to files that use them.

Source: have been rdiff-backup and duplicity user for a while before moving
to attic and then borg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/borgbackup/attachments/20200504/8b5e35c4/attachment.html>


More information about the Borgbackup mailing list