![]() The restore times of restic and Attic increased considerably for backups created later, with restic's performance deteriorating far more quickly. ![]() Again, Duplicacy was not only the fastest but also the most stable. The destination directory was emptied before each restore, so we only test full restore, not incremental restore. We also ran linux-restore-test.sh to test restore speeds. So there is always a dilemma of how often to perform a full backup for duplicity users. That is because while an incremental backup saves a lot of storage space, it is also dependent on previous backups due to the design of duplicity, making it impossible to delete any single backup on a long chain of dependent backups. In addition, duplicity has a serious flaw in its incremental model - the user has to decide whether to perform a full backup or an incremental backup on each run. Now let us look at the sizes of the backup storage after each backup:Īlthough duplicity was the most storage efficient, it should be noted that it uses zlib, which is known to compress better than lz4 used by Duplicacy and Attic. However, even if this issue is fixable, as restic currently does not support compression, the addition of compression will only further slow down its backup speeds. This could be caused by using too many threads (or more precisely goroutines, since restic is written in GO) in its local storage backend implementation. It is interesting that restic, while being the second fastest, consumed far more CPU times than the elapsed real times, which is bad for the user case where users want to keep the backup tool running in the background to minimize the interference with other tasks. Here are the elapsed real times (in seconds) as reported by the time command, with the user CPU times and system CPU times in the parentheses:Ĭlearly Duplicacy was the winner by a comfortable margin. Details can be found in linux-backup-test.sh.īackups were all saved to a storage directory on the same hard disk as the code base, to eliminate the performance variations introduced by different implementation of networked or cloud storage backends. The code base is then moved forward to these commits one by one to emulate incremental changes. After the initial backup was finished, other commits were chosen such that they were about one month apart. To test incremental backup, a random commit on July 2016 was selected, and the entire code base is rolled back to that commit. Its size is 1.76 GB with about 58K files, so it is a relatively small repository consisting of small files, but it represents a popular use case where a backup tool runs alongside a version control program such as git to frequently save changes made between checkins. ![]() The first dataset is the Linux code base mostly because it is the largest github repository that we could find and it has frequent commits (good for testing incremental backups). Enabled by -e repokey-blake2 which is only available in 1.1.0+ Backing up the Linux code base It was set it to 1MB to match that of restic The chunk size in Duplicacy is configurable with the default being 4MB. The following table lists several important configuration parameters or algorithms that may have significant impact on the overall performance. SetupĪll tests were performed on a Mac mini 2012 model running macOS Sierra (10.12.3), with a 2.3 GHZ Intel i7 4-core processor and 16 GB memory. ![]() Therefore, results presented here should not be viewed as conclusive until they are independently confirmed by other people. It is highly possible that configurations for other tools may not be optimal. DisclaimerĪs the developer of Duplicacy, I have little first-hand experience with other tools, other than setting them up and running for these experiments for the first time for this performance study. To benchmark the performance and storage efficiency of 4 backup tools, Duplicacy, restic, Attic, and duplicity, using datasets that are publicly available.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |