![]() On my 2020 Mac Laptop AES256-GCM wins over CHACHA20-POLY1305 by a lot: Hash Encryption ThroughputĠ. The default is AES256-GCM encryption with BLAKE2B-256-128 hash which tends to be faster on modern 64-bit Intel/AMD CPUs, but this is very machine dependent: You can run the benchmark yourself using: $ kopia benchmark crypto I know folks have Kopia for repositories of 10s of TBs, I’d be curious to know their stats as well. Note that content sizes are not related to source file sizes. This shows that the total size of live data is very close to the physical storage size: 729 GB blobs (physical) vs 722 GB contents (logical) $ kopia content statsĨ3096 between 10 B and 100 B (total 4.3 MB)Ħ18051 between 100 B and 1 KB (total 267 MB)ģ52019 between 1 KB and 10 KB (total 1.1 GB)ġ11774 between 10 KB and 100 KB (total 3.6 GB)ħ8833 between 100 KB and 1 MB (total 35 GB)Ģ50044 between 1 MB and 10 MB (total 682.7 GB) $ kopia blob statsħ0 between 100 B and 1 KB (total 12.6 KB)ġ60 between 1 KB and 10 KB (total 689.2 KB)ġ between 10 KB and 100 KB (total 49.5 KB)ģ9 between 100 KB and 1 MB (total 14.2 MB)ģ2242 between 10 MB and 100 MB (total 729.8 GB) The following stats show Kopia maintenance repackages virtually all data into pack blobs of around 22.5MB each. This is possible through efficient index structures and separate cache for metadata and data and lots of heavy parallelization and sharding to efficiently use all local machine and network resources. Full maintenance performs a walk of the snapshot tree and deletes unreachable contents. On my main personal repository of 730GB and 1.5M contents (file chunks), I’m running full maintenance every 4 hours and it currently takes less than 40 seconds to complete the full cycle (on my home internet which is 500Mbps symmetrical). It’s described here Details of maintenance command - #8 by jkowalski and I think it’s quite fast: Kopia uses multi-stage maintenance routine to perform what purge does in Restic and others. Instead of locks, kopia relies on passage of time for safety of its maintenance operations so it requires somewhat reasonably synchronized clocks (drift of several seconds to minutes is fine, but hours not so much) It has optional server mode but that does not introduce locks and is primarily for better access control and to avoid storing low-level repository credentials on client machines. The partial snapshot is transparently merged with last full snapshot from the history to get good incremental performance. During long snapshots Kopia will write checkpoints every 45 minutes or so, which will be reused on next snapshot attempt to not only avoid uploading data again but in many cases also avoid hashing. Yes, Kopia is designed to handle all kinds of crashes and ideally not redo work that has been done. Kopia uses symmetric encryption today (AES-256-GCM and CHACHA20POLY1305) but any authenticated encryption scheme is easily pluggable. If anyone have used them, how do they compare with Kopia? I cannot find any benchmark comparing Kopia with the other two. I have used Restic before Duplicacy, but switched over mainly because pruning was extremely slow on Restic.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |