{"id":38746,"date":"2019-10-31T22:25:40","date_gmt":"2019-10-31T19:25:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya\/"},"modified":"2019-10-31T22:25:40","modified_gmt":"2019-10-31T19:25:40","slug":"rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-6-sravnenie-sredstv-rezervnogo-kopirovaniya","title":{"rendered":"Backup, Part 6: Comparison of Backup Solutions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,
\nThis article will compare backup solutions, but first, it's worth understanding how quickly and efficiently they handle data recovery from backups.
\nFor simplicity, the comparison will focus on recovery from a full backup, especially since this operating mode is supported by all candidates. The figures used are averaged (the arithmetic mean from several runs). The results will be summarized in a table, which will also include information on features such as web interface availability, ease of setup and operation, automation capabilities, and various additional options (for example, data integrity checks), etc. The graphs will show the load on the server where the data will be applied (not the backup storage server).
\n<\/a><\/noindex><\/p>\n

Data Recovery<\/h2>\n

\nThe benchmarks will use rsync and tar as reference points since they are typically the basis for<\/a><\/noindex> the simplest backup scripts.<\/p>\n

Rsync<\/i> managed the test dataset in 4 minutes and 28 seconds, showing <\/p>\n

this load.<\/b>\"Backup,
\n
\nThe recovery process encountered limitations of the disk subsystem of the backup storage server (sawtooth graphs). It's also clearly visible that one core was heavily loaded without significant issues (low iowait and softirq \u2014 no problems with the disk and network, respectively). Since the other two programs, namely rdiff-backup and rsnapshot, are based on rsync and also use standard rsync for recovery, they will have a similar load profile and recovery time.<\/p>\n

Tar<\/i> performed slightly faster, at <\/p>\n

2 minutes and 43 seconds:<\/b>\"Backup,
\n
\nThe overall system load was on average 20% higher due to increased softirq \u2014 overheads rose in the operation of the network subsystem.<\/p>\n

If the archive is additionally compressed, recovery time increases to 3 minutes and 19 seconds with
\nthis load on the main server (decompression on the main server side):<\/b>\"Backup,
\n
\nThe unpacking process utilizes both processor cores, as two processes are running. Overall, this is the expected result. A comparable outcome (3 minutes and 20 seconds) was also achieved when running gzip on the server side with backups, where the load profile on the main server was quite similar to that of running tar without the gzip compressor (see the previous graph).<\/p>\n

In rdiff-backup<\/i> You can synchronize the latest backup using regular rsync (the results will be similar), but older backups still need to be restored using the rdiff-backup program, which managed the restoration in 17 minutes and 17 seconds, showing <\/p>\n

the following load:<\/b>\"Backup,
\n
\nThis may have been intentional, at least for limiting speed, the authors suggest such a solution<\/a><\/noindex>. The restoration process takes slightly less than half of a core, with proportionally comparable performance (i.e. 2-5 times slower) over disk and network with rsync.<\/p>\n

Rsnapshot<\/i> suggests using regular rsync for restoration, so its results will be similar. Overall, this was indeed the case.<\/p>\n

Burp<\/i> managed the backup restoration task in 7 minutes and 2 seconds with
\nthe following load:<\/b>\"Backup,
\n
\nIt worked quite quickly, and, at least, was much more user-friendly than plain rsync: no need to remember any flags, a simple and intuitive CLI interface, built-in support for multiple copies \u2014 though it was about twice as slow. If data needs to be restored from the latest backup, you can use rsync, with a few caveats.<\/p>\n

The program showed approximately the same speed and load BackupPC<\/i> when in rsync transfer mode, restoring the backup in <\/p>\n

7 minutes and 42 seconds:<\/b>\"Backup,
\n
\nHowever, in tar data transfer mode, BackupPC performed slower: in 12 minutes and 15 seconds, with the CPU load being overall lower <\/p>\n

by one and a half times:<\/b>\"Backup,
\n
\nDuplicity<\/i> without encryption showed slightly better results, completing the backup restoration in 10 minutes and 58 seconds. If encryption is activated using gpg, the restoration time increases to 15 minutes and 3 seconds. When creating a repository for storing copies, you can specify the size of the archive to be used when splitting the stream of incoming data. Overall, on conventional hard drives, and due to the single-threaded operation mode, there is not much difference. It may appear with different block sizes when hybrid storage is used. The load on the main server during restoration was as follows:<\/p>\n

without encryption<\/b>\"Backup,
\n
\nwith encryption<\/b>\"Backup,
\n
\nDuplicati<\/i> showed comparable restoration speed, completing it in 13 minutes and 45 seconds. An additional approximately 5 minutes were spent verifying the integrity of the restored data (totaling around 19 minutes). The load during this was <\/p>\n

quite high:<\/b>\"Backup,
\n
\nWhen aes encryption was activated by internal means, the restoration time was 21 minutes and 40 seconds, with the CPU load being maximum (both cores!) during restoration; during data verification, only one thread was active, occupying one CPU core. Verifying data after restoration took the same 5 minutes (totaling nearly 27 minutes).<\/p>\n

Result<\/b>\"Backup,
\n
\nSlightly faster, duplicati handled restoration when using an external program gpg for encryption, but overall the differences from the previous mode are minimal. The total time taken was 16 minutes and 30 seconds, with data verification taking 6 minutes. The load was <\/p>\n

as follows:<\/b>\"Backup,
\n
\nAMANDA<\/i>, using tar, managed to finish in 2 minutes and 49 seconds, which is quite close to the regular tar. The system load is generally <\/p>\n

the same:<\/b>\"Backup,
\n
\nDuring the restoration of the backup using zbackup<\/i> the following results were obtained:<\/p>\n

encryption, lzma compression<\/b>\"Backup,
\n
\nTotal time was 11 minutes and 8 seconds<\/p>\n

aes encryption, lzma compression<\/b>\"Backup,
\n
\nTotal time was 14 minutes<\/p>\n

aes encryption, lzo compression<\/b>\"Backup,
\n
\nTotal time was 6 minutes and 19 seconds<\/p>\n

Overall, it\u2019s not bad. Everything hinges on the CPU speed of the backup server, which is quite noticeable based on the program's performance with different compressors. On the backup server side, a regular tar was executed, so if you compare with it, the restoration operates three times slower. It may be worth checking the performance in multithreaded mode, with more than two threads.<\/p>\n

BorgBackup<\/i> In non-encrypted mode, it performed slightly slower than tar, taking 2 minutes and 45 seconds; however, unlike tar, there is the possibility of deduplicating the repository. The load during this process was <\/p>\n

as follows:<\/b>\"Backup,
\n
\nIf you enable encryption based on blake, the restoration speed slows down a bit. The restoration time in this mode is 3 minutes and 19 seconds, and the load was <\/p>\n

as follows:<\/b>\"Backup,
\n
\nAES encryption operates slightly slower, with a restoration time of 3 minutes and 23 seconds, while the load did not particularly <\/p>\n

change:<\/b>\"Backup,
\n
\nSince Borg can operate in multithreaded mode, the CPU load is maximized; meanwhile, when additional features are activated, the runtime simply increases. Apparently, it is worth investigating multithreading performance similarly to zbackup.<\/p>\n

Restic<\/i> performed the restoration slightly slower, with a runtime of 4 minutes and 28 seconds. The load during this process appeared <\/p>\n

as follows:<\/b>\"Backup,
\n
\nIt seems that the restoration process operates in several threads, but the efficiency is not as high as with BorgBackup, yet comparable in time to regular rsync.<\/p>\n

Using UrBackup<\/i> managed to restore data in 8 minutes and 19 seconds, with the load being <\/p>\n

as follows:<\/b>\"Backup,
\n
\nStill, it shows a fairly low load, even lower than tar. There are occasional spikes, but not exceeding the load of a single core.<\/p>\n

Selection and justification of criteria for comparison<\/h2>\n

\nAs mentioned in one of the previous articles, the backup system must meet the following criteria:<\/p>\n