As Luca told us, these changes were made possible through the use of a new internal scheduler that is able to deduplicate and parallelize backup operations, as well as a new JSON library. Also, an important innovation was the ability to configure the number of threads that will be used when scanning changes that occur in accounts, which allows the system administrator to use all the advantages of multi-core processors.
“The new scheduler instantly receives notifications of every change from the mailbox and puts it in the queue in an ultra-light memory structure, where the operation is deduplicated and planned in order to optimize the end-to-end transmission of the reserved data. In addition, we have analyzed and improved the JSON library. Now it works faster than the previous version, and optimizes the use of processor and memory, reducing the number of calls to the garbage collector, ”says Luca Arcara.
In this regard, the question begs itself: is it possible to achieve an additional performance increase through the use of more powerful iron and, in particular, more multi-core processors? As it turned out, such a trick would not work. The fact is that the speed of real-time backup is more affected by the time I / O is performed, as well as the number of operations performed per unit time, than the performance of the RAM or the central processor.
That is why, if we are talking about a server with several hundred mailboxes, it is not necessary to use any additional equipment on it. However, if it is really important for you to achieve maximum performance, then a server with a dual-core processor, 2-4 gigabytes of RAM and, most importantly, a dedicated SSD for storing backup metadata is suitable for you. But if your infrastructure calculates millions of different changes, for example, 1000 mailboxes with a quota of 10 gigabytes each, then it is best for you to switch to using a file system such as XFS, which supports billions of inodes for storing data. It is also recommended to increase the size of blocks in devices for storing backup metadata and backup archives in order to maximize the speed of scanning the directory structure. In other words, the system administrator should reduce the block size in the storage for metadata, since they usually occupy less than 4 kilobytes that make up a normal ext4 file system block, and increase the block size in the storage for blobs, since they usually take more than 4 kilobytes.
Also in Zextras 3.0 there was an opportunity to adjust the compression level of backup data. If earlier in Zextras Backup the compression level was set at 3 and it was impossible to change it, now the system administrator can independently set the compression ratio from 0 to 9. As it turned out, this function appeared for a reason.
“The idea of the function of choosing the compression level for backups was born during the communication with our customers who used specialized storage devices that support deduplication and compression at the block level to store backups. Besides the fact that compressed files are much more difficult to deduplicate, double compression under certain circumstances led to an increase in the final file size. Now the owners of such devices can lower the compression level or completely disable it in order to achieve optimal use of their devices and reduce the load on the central processor, ”Luca Arcara shared with us.
Since Zextras Suite uses open standards, compression in Zextras Backup is performed using GZip and only for blobs containing data directly from emails. The attentive reader will immediately notice a slight discrepancy, because the default compression level in GZip is 6, and in Zextas Suite it is 3. The default compression level was specially lowered to reduce the load on the central processor and ensure greater responsiveness of highly loaded systems, while ensuring acceptable level of compression.
The amount of space that a system administrator can save depends on what data is stored on his server. For example, when storing compressed attachments in JPG, PDF or other formats, the user of Zextras Backup will not receive much benefit from increasing the compression level. However, if it stores a lot of text or HTML email messages, documents, spreadsheets, or plain text files, a higher compression ratio will save more space. Since BLOBs are a BASE64 EML file, compression can reduce the volume they occupy by up to 65%.
That is why, before setting a certain compression ratio, the system administrator should evaluate the structure of the stored files and if incompressible JPEGs or PDFs prevail among them, reduce the compression ratio to a minimum, ensuring maximum server performance, or if most of the stored information represents self text documents and spreadsheets, increase the compression level to ensure maximum economic efficiency of your server.
The best option is testing - exporting a backup copy from production to a test environment with various compression ratios. Such testing will clearly show how the compression ratio affects the load on the central processor, as well as how it affects the disk space occupied by the backup.
Thus, the updated Zextras Backup extension allows the system administrator to significantly accelerate the creation of backups, which means to prevent data loss in case of force majeure situations, and in some cases to increase the efficiency of backup storage due to compression of backups.
For all questions related to the Zextras Suite, you can contact the representative of the Zextras company Ekaterina Triandafilidi by e-mail katerina@zextras.com