How much does compression impact NAUbackup times on XenServer?

In setting up NAUbackup – all the documentation says that while compression is supported, it’s recommended to leave it off and compress on the storage side later on if needed. I decided that I’d take a quick look at the performance on a small EDI stack that we have running in production, duplicated over to the test environment, to see the impact.

Test #1 –  The AS/2 front end VM with iSCSI storage on a 1 Gb connection:

  • Uncompressed – 18 minutes, 57 seconds – total size 19.12 GB
  • Compressed (“compress=true”) – 31 minutes, 4 seconds – 7.48 GB

So for slightly less than a doubling in time, we get well under half the file size footprint. In just subjective usage, I didn’t notice that any processes or general usage was delayed or slowed down in any way. Now this is a software stack that essentially has zero user input and generally very low load – so your results might be slightly different. In general monitoring of XenCenter performance reporting, none of our performance warnings were triggered.

That test went well enough that I decided to try it on the whole list of VM’s.

Test #2 – The entire EDI stack using local storage backed up to same NAS share on 1 Gb connection:

  • Uncompressed – 2 hours, 40 minutes, 23 seconds – 579.62 GB
  • Compressed (“compress=true”) – 5 hours, 50 minutes, 42 seconds – 310.34 GB

This stack has a combination of Ubuntu and Windows servers running a mix of light load web servers and the EDI translator databases, and is probably a closer representation of our typical environment and loads. Again, system performance seemed reasonable while performing the backup and no alarms went off in XenCenter. Here we see that an almost doubling of time results in not quite half the data size. I think a follow-up test would be to go back and see which machines are under the double time factor and if there are common elements.

In conclusion – should you use compress=true when using the NAUbackup scripts? The answer is of course – maybe. For us, we have the luxury of enough down time that no work-hour loads are impacted and the space savings allowed us to cut our off-site procedure down to a single backup drive instead of having to split the job or go with more expensive backup media. Restoring from the compressed backups does require a slightly different route, although in doing our DR testing, that has not been a big hurdle.