Commvault

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2

Compression Overview

Compression of the data during backup operation is an important process that significantly reduces the footprint of the backup data in Commvault® storage targets. Using a lossless compression/decompression algorithm (GZIP or LZO), Commvault® software reduces the data size by removing statistical redundancy (waste space).  However, this reduction comes at a price; CPU cycles when using software compression, or supported tape drive when using hardware compression. 

If software compression is used, it is important to consider which system will provide the required CPU cycles. Two options are available, each providing advantages/disadvantages:

  • Client-side compression - The client takes the hit on the CPU but less data will travel the network.
  • MediaAgent-side compression - The MediaAgent provides the required CPU cycles for all client backups, but data must go over the network.

The available resources on the client servers and on the MediaAgent dictate where the compression should occur. If the client servers have more than enough CPU cycles available for production, few cycles could be used for compression, which would also benefit the production network by sending less data. But if client resources are limited, having a performant MediaAgent sized with enough CPU power could allow a single machine for all compression operations. This ultimately avoids impact on client servers. 

Compressed file example




Enable Compression

Enable compression for clients or MediaAgent from the storage policy's primary copy. By default, all subclients use the compression setting set at the storage policy copy level. However, this setting can be overridden for a given subclient.

Note that during this procedure, you can select clients or MediaAgent-side compression, or keep using storage policy level settings.

Important! If the subclient is sending its data to a deduplicated storage policy using client-side deduplication, any defined compression setting is ignored and forced to client-side compression, since it is required for the client-side deduplication process.




To enable storage policy level compression

1 - Expand Storage Policies | Right-click the storage policy Primary copy.

2 - Check to enable compression and define where it takes place.



To configure client compression settings

1 - Expand Client Computers| Right-click the subclient.

2 - Define if compression is used, where it takes place, or follow storage policy settings.



Virtual Server Agent Compression

The Virtual Server Agent (VSA) compression has the LZO lossless algorithm. LZO tests have shown a significant reduction in CPU usage when compressing virtual machines. This reduction allows a VSA proxy to process more VMs concurrently, which is a tremendous benefit when protecting large environments.

Since the VSA compression replaced the traditional GZIP in SP4, LZO is used only if it is a VSA pseudo client sending data to a deduplication store that was created after SP4. If the storage policy was created and used before SP4, GZIP is used as usual. Sending data using a different compression method would result in different deduplication signatures – which would re-baseline the entire dataset. In order to leverage the LZO compression, the deduplication database must be sealed and the data re-baselined.



Compression Troubleshooting

Compression is handled by the clbackup.exe process of the client server. To troubleshoot a compression issue, the following logs are investigated:

  • clbackup.log (on the client)
  • CVD.log (on the client)

The following two entries appear in the logs and indicate if compression is used, as well as the location where it takes place (client or MediaAgent).

Compression related entries in log files





Troubleshooting Tip for Hardware Compression

If data sent to tape is larger than expected, it can be indicative of a tape drive that is not compressing the data. The first step is to look at the logs and ensure that hardware compression is enabled. If it is, but the data still does not compress, it may be caused by a drive not supporting compression or for which compression is not enabled. Contact the vendor to resolve the issue.

Run additional testing to confirm the hardware issue. Proceed with the following steps:

  • Create or use a test subclient with a fair amount of data to conduct tests.
  • Create a non-deduplicated storage policy with compression turned off.
  • Create a non-deduplicated storage policy with software compression enabled.
  • Create a non-deduplicated storage policy with hardware compression enabled.
  • Run a full backup for the test subclient in each storage policies.
  • Compare the resulting size of the written data.

Troubleshooting procedure for hardware compression issues



  • No labels