[This is the English translation by DeepL]
[Version originale en français]
I've been using Borg Backup for several years now. However, at the end of 2023, I encountered major problems with the backup of one of my machines. So I decided to explore alternative solutions. A quick search revealed two solutions that were relatively equivalent to Borg Backup: Restic and Kopia.
In the absence of a comparison of these three solutions (there is an "old" comparison between Borg and Restic, but it doesn't go as far and doesn't mention Kopia), I decided to carry out some tests myself, to be able to compare simple metrics common to all three software packages.
Finally, once a regular backup is automated, the important metrics for me are: backup duration, network exchange volume and storage volume on the backup server. Similar metrics are worth exploring for backup restore operations and backup server maintenance operations.
My test environment consists of the following components:
- client: macmini M2 Pro running macOS 13.6.3, 32 GB RAM
- backup server: Intel(R) Core(TM) i3-3220T-based PC, running FreeBSD 14, 16 GB RAM, ZFS storage on SSD
- switched 1Gbps ethernet network
- Splunk instance to ingest logs and produce statistics and graphs
To make sure I was working with representative data, I decided to back up part of my user directory. I've excluded a huge directory of digital photos that rarely changes, as well as numerous cache directories that it's not relevant to back up. The final size of my backup target is around 140GB.
I based my backup protocol on my experience with Borg. However, as each software has its own specificities, it took some time to document and adapt. In spite of these preparations, the backup process did have a few surprises in store for me.
Backups were automated using a single bash script, which launched the creation of backups via Borg, Restic and Kopia in random order. I had in mind that the first backup task would be potentially penalized by access to files on the client workstation that were not in the system cache, but after 15 days of testing, I found that there was no visible difference in backup time attributable to the order of the backup tasks. I therefore subsequently decided to freeze the order of backup jobs, which also makes it much easier to track metrics.
The client machine has scheduled sleep periods at night. During these sleep periods, no backup takes place. In addition, the script is scheduled in Launchd by setting the StartInterval argument to 3600 seconds. Unlike a crontab schedule, for example, this one ensures an incompressible delay of one hour between two script executions. In other words, one hour must elapse between the end of the previous execution and the start of the new one. This means that the script is actually run just under once an hour. For example, if each execution lasts 5 minutes, then it takes 26 hours, not 24 hours, to run the script 24 times.
Important note: I'm not going to go into detail in these articles about the differences in the software's ergonomics, the availability or otherwise of a graphical management interface, etc. Some of the solutions presented here have several different graphical interfaces, the functionalities of the three products vary, and I don't wish to make a catalog comparing each software point by point.
Here's the table of contents of my comparison. The link to each article will become active upon publication.