Do encryption and compression increase backup time?

One of the questions raised by our users is whether compression and encryption can increase the backup time? Since we all strive to do things as fast as possible security of the data that is being backed up can suffer. For the purposes of this article, we did some extended testing just to show off how much time can you really lose (if any) by implementing encryption and compression when backing up your data. We also took notice and apart from performing the test from SSD to SSD, we also did a test using an old USB drive just to show that when looking to save your backup time compression and encryption shouldn’t be the first places you should look at. Of course, testing was performed with Active@ Disk Image.

But first a word about encryption. Active@ Disk Image uses modern and safe encryption algorithms such as AES-128, AES-192, and AES-256 respectively. It goes without saying that AES-256 has a bigger and more complex key than AES-128 and therefore harder to break.

However, in theory, AES-256 encryption should take more time to implement into backup compared to its less complex counterparts. We wanted to investigate this issue as well as how much time will compression take during backup and also what happens when you combine encryption and compression and drive them to the max? The results are in and some of you may be surprised.

To clarify the below tables, Resulted Image we got by comparing the size of the original non-compressed and non-encrypted image (100%) with its later compressed and encrypted counterparts.

For example, in SSD to SSD, 100% is a 37.34 GB non-compressed and non-encrypted and is used as a reference in all of the tables Resulted Time, on the other hand, is there the measure the effects that encryption had on the backup time and should be only compared with the results within that table. Every non-encrypted image in each table is used as a “100%” reference for that table.

SSD to SSD

For this testing, in particular, we used two Samsung SSDs 850 Pro and Intel’s i5-2400. We used a system partition of 37.34 GB in size. Since operating systems have lots of files that are quite easy to compress efficiently, we expected a high compression rate and we weren’t disappointed.

Disk to Image – No Compression

Disk to Image – Fast Compression

Disk to Image – Normal Compression

Disk to Image – High Compression

USB to USB

The following test was conducted creating a disk image of a smaller plain 4GB USB drive and transferring it to a bigger SanDisk Extreme 64GB USB. The drive was filled mostly with eBooks and photographs. This example is the showcase the scenario where you would perform a backup by using some of the older drives in the process. Such drives, in our case a 4GB USB, can be a bottleneck in your system and severely affect its performance when performing a backup. The computer was using i7-4770k on stock settings.

Disk to Image – No Compression

Disk to Image – Fast Compression

Disk to Image – Normal Compression

Disk to Image – High Compression

Conclusion

When backing up a system partition from SSD to SSD we can see that compression not only doesn’t increase the backup time but also greatly reduces it. If we compare No Compression to High Compression as two extremes, we can see that High Compression reduced the backup time by 50% and reduced the image size by 60%. These are numbers that should not be ignored by any means.

However, when it comes to encryption, we see that an increase in backup time (SSD to SSD) was around 25% with No Encryption vs AES-192 (No Compression), fairly negligible 3-4% (Fast and Normal Compression) and up 7% in High Compression across the board.

We see that the effects of the compression are quite negligible on the overall performance and that it shouldn’t be avoided when performing a backup. We used an older i5 and i7 CPUs for our testing and did not notice any hiccups during testing. But expect slowdowns on CPUs with older architectures and lesser number of cores, as well as with older and slower drives.

If we got anything conclusive from USB to USB example is that the read time of the smaller USB was sub-par and that both CPU and the faster drive were bottlenecked by it, and that you shouldn’t use older USBs for backup. Since the vast majority of the files on the USB were jpegs the compression could not do much for them since they are already compressed format.

In our experience, text and .exe files provide the best compression ratio, while images and video files the worst.

So, to finalize, if you care about the time and space spent on the backup you should:

• Have a half-decent CPU and moderately fast drives that can support it
• Always perform compression, the higher the better it will save you time and space
• Encryption does not tax the CPU that much and should not be avoided