borg compare borg to *

there are quite some outdated reviews comparing attic with obnam and other backup sw, but there isn't much out there that includes borgbackup.

write a new one. compare borgbackup latest release to:

restic
bup?
burp?
rsync?

Stuff to track:

speed (how long does 1st backup, 2nd backup take? how long does extract take?
with / without encryption
without / with fast / with high compression
how big is the repository? how many files are in the repository?
does it backup xattrs / acls / bsdflags?
test with sparse files (VM images are often sparse). Make 1st backup with VM. Start/Stop VM. Make 2nd backup of same VM.

Jul 23 '16 12:07 ThomasWaldmann

duplicati (popular under windows, has stable 1.x and a 3-year-in-development 2.0 beta)
duplicity (used by default by ubuntu with the Déjà Dup frontend)
rdiff-backup (more sync than backup?)
SnapRAID (not really a backup solution but maybe worth a mention?)

Plus this like resistance to corruption might be something that can be taken into consideration.

update Removed non-FOSS and dead projects.

Jul 25 '16 15:07 dragetd

guess only FOSS should be considered.

I added "documentation". Does not necessarily mean it should go into borg docs, but rather that this a documentation-like task.

Jul 25 '16 18:07 ThomasWaldmann

hmm, it might be nice to have this somehow repeatable or even reproducible.

maybe vagrant and some tests based on pytest-bench(mark) could be used, see also https://github.com/borgbackup/backupdata about how to generate data that is not deduplicatable.

Jul 28 '16 12:07 ThomasWaldmann

The Arch Linux Wiki has compared the features of a handful of backup programs (including borg) which would be pretty useful for this task.

Aug 06 '16 14:08 Abogical

That table looks pretty complete. Anything we would want that isn't on that table? I think just benchmarks. Maybe we could add those (while citing the machine used of course).

Aug 06 '16 16:08 PlasmaPower

That list on the Arch wiki is great (some tools in there I wasn't aware of). It's very detailed.

Although it did strike me that one cool feature of borg that many similar tools lacks is the ability to remove data from the backup repo. The table on the Arch Wiki doesn't have a column for that feature.

Aug 08 '16 02:08 level323

@level323 be the change you see in the world :P

Aug 08 '16 02:08 PlasmaPower

I just tried, but the bot filter for the Arch Wiki signup page requires the applicant to enter the output of an Arch-specific shell command. I don't have any Arch systems on hand to work this out. Change agent: 0. Bot filter: 1.

Aug 08 '16 03:08 level323

It seems to be a static question, so...

$ pacman -V|base32|head -1 BIQC4LJNFYQCAIBAEAQCAIBAEAQCAIBAEAQCAICQMFRW2YLOEB3DKLRQFYYSALJANRUWEYLMOBWS

... should work for you.

Aug 08 '16 11:08 enkore

Thankyou @enkore

I've added two columns to that table and posted an entry on the respective "Talk" page to suggest it be accepted.

Here's the new table I proposed: New chunk-based comparison table

Aug 08 '16 22:08 level323

i did a sort of "napkin benchmark" in this blog post here: https://anarc.at/blog/2014-11-18-bup-vs-attic-silly-benchmark/

considering how silly it is, i figured I would look into how to make this more generic and reproducible: it's not easy. creating a dataset is only part of the problem, which is somewhat solved by borg's backupdata or obnam's genbackupdata ...

the real issue is how to script running all those different programs that have different semantics and ways of calling them. liw (obnam's author) had written seivot for that purpose, but the project is basically abandonned, as the author is now using an obnam-specific benchmarking tool.

it's great the work that the Arch Linux people are doing on the wiki, amazing documentation as always. but it seemed to me the original post here was more about benchmarking than feature comparison.

furthermore, I am not sure such a comparison would belong to the documentation, as it would be needlessly stuck in time. by nature, such results are temporal and subject to change and are therefore a poor fit to a documentation page, in my mind.