Home > Storage > PowerFlex > White Papers > Dell APEX Block Storage for Azure: Protecting SQL Server Data with Dell APEX Protection Storage > Backup time and tests efficiency
DD compresses data at two levels: global and local, global compression, or deduplication, identifies redundant data segments and stores only the unique data segments by comparing received data to data already stored on disk, while local compression compresses the unique data segments.
The total compression factor indicates the total amount of compression the DD system performed with the data that it received. The higher the total compression factor for a backup, the greater the space savings for that backup.
The data reduction percentage represents the total compression savings to show the consolidation achieved during the backups. The higher the reduction percentage, the greater the space savings on the DD appliance.
DD Boost software sends only unique data from the backup host or client to the DD system, enabling more efficient use of the network. Also, the greater the amount of unique data, the higher the CPU utilization.
In this test, we deployed an Azure VM Standard_D16s_v5 with specifications of 16 vCPUs and 64 GB memory to host SQL Server, serving as the compute optimized SDC instance for Dell APEX Block Storage on Azure. This setup included six volumes, for the SQL Server installation and using APEX Block Storage volumes. The Azure VM Standard_F48s_v2 instance type, equipped with NVMe SSDs, was used for the storage optimized SDS instance for Dell APEX Block Storage on Azure. The compute-optimized Azure VM running SQL Server database was configured with a total application data size of 733.5 GB. The initial backup of the SQL Server database measured 733.5 GB, with subsequent backups reflecting a data change of 26.5 GB.
We obtained test results under the following categories:
The provided figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup as shown in the following figure:
Figure 11. Pre-compression and post-compression
The provided figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup.
For the Backup time, the initial backup, encompassing all SQL Server database totaling 733.5 GB, was accomplished in 98 minutes. Subsequent data full backups for the SQL Server database, involving a mere 26.5 GB data change in 733.5 GB, were completed in just 54 minutes as shown in the following figure:
Figure 12. Pre-compression and post-compression with backup time
The provided figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup.
For the Total compression factor, the initial backup consists of unique data and had the lowest total compression factor. The subsequent backups were similar in the amount of unique data, and the compression factor increased accordingly.
Figure 13. Pre-compression and post-compression with total compression factor
The following figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup.
For the data reduction percentage, the initial backup had unique data and yielded the lowest reduction percentage. The subsequent backups were similar in the amount of unique data transferred and their reduction percentage increases accordingly.
Figure 14. Pre-compression and post-compression with data reduction percentage
In this test, we deployed an Azure VM Standard_D16s_v5 with specifications of 16 vCPUs and 64 GB memory to host SQL Server, serving as the compute optimized SDC instance for Dell APEX Block Storage on Azure. This setup included six volumes, for the SQL Server installation and using APEX Block Storage volumes. The Azure VM Standard_F48s_v2 instance type, equipped with NVMe SSDs, was used for the storage optimized SDS instance for Dell APEX Block Storage on Azure. The compute-optimized Azure VM running SQL Server database was configured with a total application data size of 733.5 GB. The initial backup of the SQL Server database measured 733.5 GB, with subsequent backups reflecting a data change of 26.5 GB.
We obtained test results under the following categories:
The provided figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup as shown in the following figure:
Figure 11. Pre-compression and post-compression
The provided figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup.
For the backup time, the initial backup, encompassing all SQL Server database totaling 733.5 GB, was accomplished in 98 minutes. Subsequent data full backups for the SQL Server database, involving a mere 26.5 GB data change in 733.5 GB, were completed in just 54 minutes as shown in the following figure:
Figure 12. Pre-compression and post-compression with backup time
The provided figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup.
For the Total compression factor, the initial backup consists of unique data and had the lowest total compression factor. The subsequent backups were similar in the amount of unique data, and the compression factor increased accordingly.
Figure 13. Pre-compression and post-compression with total compression factor
The following figure indicates that the initial data backup size on the Application system is 733.5 GB. Following the transfer of data to the DD system, where deduplication and compression algorithms are applied, the physical storage consumption is minimized to 563.6 GB. In the subsequent full backup of the SQL Server database, which involves only a 26.5 GB data change out of the initial 733.5 GB sent to the DD system, the physical storage consumption is further reduced to 97.3 GB. This reduction is attributed to deduplication taking precedence, coupled with compression, making subsequent backups more space-efficient than the initial backup.
For the data reduction percentage, the initial backup had unique data and yielded the lowest reduction percentage. The subsequent backups were similar in the amount of unique data transferred and their reduction percentage increases accordingly.
Figure 14. Pre-compression and post-compression with data reduction percentage