about features

[ThomasWaldmann]

it's hard to compare backup tools as some features and policies/styles will be different and hard to compare.

nevertheless, some related ideas (see feature table in the README):

Reliability | Redundant index copies

Not sure what kopia implements there, but in general, an index (or cache) is usually a data structure for quicker access to some primary/authoritative data. If the index (or cache) is lost, it can be rebuilt from the primary data.

So not sure why it needs "redundant index copies" considering the index (or cache) by definition is redundant to the primary data it is indexing (or caching).

Continue restore on bad blocks in repository

Usually there is some separate check/ repair function to bring the repository into a as-good-as-it-gets state.
But this is not necessarily done "on the fly" within a restore operation.

File management: filesystem flags missing

Some flags like immutable need yet another api (besides stat / xattrs / acls).

File management | Automatically excludes CACHEDIR.TAG(3) directories

borg can do that, but (IIRC) does not do it by default, but only if you give the cli option to enable this feature.

Remove the "automatically" part maybe?

Dedup & compression efficience | Can files be excluded from compression by extension

borg actually had code for that for a while (not sure if ever released), but it was removed again because it creates quite a lot of configuration burden on the user to manage all these extensions and what should be compressed or not. borg now has a auto,X compression mode which first tries to predict compressibility using lz4 (super fast) and then runs compressor X, if it likely is well compressible. In the other cases it uses either no compression or the already computed lz4 result, if that is shorter.

Are encryption protocols sure (AES-256-GCM / PolyChaCha / etc ) ?

You mean "secure".

What I would recommend here is checking for modern AE / AEAD (authenticated encryption [w/ associated data]) crypto.

AES-GCM, AES-OCB, Chacha20-Poly1305 are well known "ready to use" AEAD combos (borg2 will use 2nd and 3rd).

borg1 uses AES-CTR + HMAC-SHA256 (or blake2b) self-arranged combo due to its roots in / compatibility with attic backup.

Security | Can encrypted / compressed data be guessed (CRIME/BREACH style attacks)?

IIRC there is something about this in our FAQ or on the issue tracker. Result was that it is not a problem in this scenario.

Misc | Does the backup software support pre/post execution hooks?

Is this a feature or anti-feature? :-)

Anyway, for borg this feature does not make sense because it is a CLI tool. So you use either a shell script (then you can put your pre/post commands just in that script) or a wrapper or GUI (like borgmatic, vorta - then it is not borg's problem).

[deajan]

Not sure what kopia implements there, but in general, an index (or cache) is usually a data structure for quicker access to some primary/authoritative data. If the index (or cache) is lost, it can be rebuilt from the primary data.
So not sure why it needs "redundant index copies" considering the index (or cache) by definition is redundant to the primary data it is indexing (or caching).

Maybe the word index isn't appropriate... but something like a superblock or so. The list that describes which chunks is linded to which files.

Some flags like immutable need yet another api (besides stat / xattrs / acls).

So borg supports backing up / restoring flags written by chattr +i ?

Remove the "automatically" part maybe?

Done

IIRC there is something about this in our FAQ or on the issue tracker. Result was that it is not a problem in this scenario.

I've read the thread borgbackup/borg#3687 Looks good to me.

Is this a feature or anti-feature? :-)

Lol, makes sense when using external tools like VSS snapshots on Windows, even if I admit this could be scripted.

[ThomasWaldmann]

https://borgbackup.readthedocs.io/en/stable/man_intro.html?highlight=flags#support-for-file-metadata see there about bsdflags / fs flags.

About the pre/post commands: i see it makes sense for higher level / gui tools, because you might not have a surrounding script there. But if you have it because the command is designed to be a script / cli command, it's somehow reinventing the shell (likely in a worse way).