In the case of the airplane, the potential damage is quite clear: people die and it is is so high, that one is willing to accept the very high mitigation costs, even though the failure of a hydraulic system (let alone two) is quite low. More specifically: what kind of damage can occur, how serious is it, and how likely is it to occur. In order to answer that question, you need to understand “your risk”. The question is: how much are you willing to spend to mitigate your risk?Įxactly, that is my point. So in my opinion, it’s not a “trusting vs not trusting” issue. If one fails, the other system takes over. An airplane has two or three parallel hydraulic systems. In an airplane, to mitigate risks, systems are redundant. Or I can dilute the risk by backing up to multiple destinations (can be more expensive depending on how you will set it up). It’s cheap (free), and it minimizes the risk a little. The more measures, or more complex, the safer it gets but also more expensive.įor example: To mitigate the risk of “trusting the backend”, I can periodically download random files and compare them with the production environment files. So what we have to do is take actions under our control to minimize or mitigate the risks. Of course there are systems theoretically more reliable than others, but in the real world you don’t have easy access to system data to confirm this reliability. There is no 100% fail-safe software / system, neither Dropbox, nor Duplicacy, nor Duplicati, or your NAS, and no other. A comprehensive and insightful comparison like this will only advance our understanding and make both software better in the long run.Īs you asked for “anyone”, then, my two cents: Both sides can learn from each other and have something different to catch up on. Having said the above, I applaud their collaborative efforts to start and expand such as discussion. In cases where a cloud storage violates this basic assumption (for example, Wasabi, OneDrive, and Hubic), we will work with their developers to fix the issue (unfortunately not everyone is responsive) and in the meantime roll out our own fix/workaround whenever possible. In Duplicacy we took the opposite way – we assumed that all the cloud storage can be trusted and we based our design on that. Their developer argued that by taking an aggressive repair approach one will be able to identify storage issues sooner. More than one new Duplicacy users mentioned that the database corruption is the main reason they gave up on Duplicati. In my opinion, Duplicati’s main problem is the use of the database and the aggressive approach to attempt to ‘repair’ it (as pointed out by several users in that thread). However, Duplicati lacks the killer feature of Duplicacy, cross-client deduplication, and it doesn’t look like it will ever support it. It also has a larger number of storage backends. Duplicacy already offers the -threads option for multithreaded uploading and downloading, while Duplicati currently doesn’t, and it is unclear when it will be available.įeature wise, Duplicati comes with a web-base UI and is more feature-complete than Duplicacy. By disabling compression and encryption, and applying an optimization on the hash function, they were able to achieve the same or even slightly better performance (than Duplicacy with compression and encryption), but the CPU utilization was still significantly higher. Performance wise, Duplicacy is about 2-3 times faster than Duplicati with the default settings (3:09 vs 9:07 for a small data set, and 0:27:27 vs 1:12:40 for a larger one). There is an interesting discussion comparing Duplicacy with Duplicati: Duplicati 2 vs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |