compare borg to * - Githubissues

ThomasWaldmann commented 8 years ago

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.

dragetd commented 8 years ago

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.

ThomasWaldmann commented 8 years ago

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.

ThomasWaldmann commented 8 years ago

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.

Abogical commented 8 years ago

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

PlasmaPower commented 8 years ago

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).

level323 commented 8 years ago

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.

PlasmaPower commented 8 years ago

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

level323 commented 8 years ago

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.

enkore commented 8 years ago

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

$ pacman -V|base32|head -1 BIQC4LJNFYQCAIBAEAQCAIBAEAQCAIBAEAQCAICQMFRW2YLOEB3DKLRQFYYSALJANRUWEYLMOBWS

... should work for you.

level323 commented 8 years ago

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

anarcat commented 8 years ago

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.