That would give you a good target though, because if performance is adequate to handle daily data turnover making it faster and more efficient may be a good idea if there were no other bugs remained to get addressed; but data safety would be always a priority, regardless of the performance.
To clarify, I’m not saying that performance is not important. All being equal of course one should choose more performant tool. But all is not being equal: moreover, most of that all is difficult to quality and is often not discussed at all; therefore just focusing on performance data (because of a sense that some data is better than none) will not necessarily result in the best choice. (The fact that duplicacy is fast and robust does not extend to all solutions). (copy to /dev/null is very fast, but hardly useful. Raw copy with folder versioning is also super fast, and you can even restore! – but also, not optimal. etc)
‘dedup stress’ scenarios
That’s the thing. Nobody runs backup tools on a “stress test datasets”. They run on actual data and some people have different datasets… To get a realistic reflection of how tool will backup on your specific dataset it would be way easier to just try it than try to quantify and interpolate between synthetic benchmarks and still only get a vague idea.
Testing the robustness however is time consuming and doing ridiculous tests to sabotage the backup process and dataset to see how would the backup program handle that – that experience would be universal, not dependent on a type of data users have and helpful. But I haven’t seen any data like that published.
Not trying to downplay your work by the way – this is all good data, I’m just concerned that having only that data implies “the fastest is the best one” which is not necessarily true.
The HDD or OneDrive one?
If the latter – comparing tools in how well does OneDrive resist abuse from them is hardly useful: I think duplicacy (and all other backup tools) shall drop support for OneDrive, DropBox, and other *drive services because this will never will, should, or can work well: (Newbie) Backup entire machine?
You are right. I thought I saw duplicity there.
the only wish-list piece I have would be to explore whether duplicacy can support the possibility of increasing the data block sizes; something that I found during testing was that Arq/Duplicacy a bit harder to handle coz the file sizes tend to be smaller (and so all equal many more data files).