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).
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/repairfunction 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
immutableneed 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,Xcompression 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).