What is 0% compression when viewing the repository statistics in the UI
This issue occurs due to accumulation of residual data processed during the backup process which was not properly removed through the normal clean-up process. Abnormally stopping the core service (either by forcefully killing the associated task), power failure on the Core server, system reboots due to automatic Windows updates, etc are examples of how the clean-up process will not complete properly.
When such an event takes place, indexing information held in the Core Server memory is lost thus leaving blocks of data in a "not marked for deletion" state. When the core service is available again, it is unable to identify these blocks of data as "delete candidates" and remove them. Since these blocks occupy space in the repository, they count against repository statistics. If the accumulation of these blocks offsets completely then the compression/deduplication of the protected data (which continues to be performed properly), of the repository will show "0% compression."
DEBUG 2015-07-01T00:16:04 [393] - Replay.Core.Implementation.Repositories.RepositoriesMetricsLogger () Repository Repository 1 (64419243-734f-4c48-8683-1619ed1c3aea): Status:Mounted; Bytes Used:68.53 TB; Bytes Free:9.45 TB; Compression Ratio:0.00 %; Protected Data:66.2 TB
The parameter 'Compression Ratio' counts as 0% when the parameter 'Protected Data' is less then the parameter 'Bytes Used.'
DEBUG 2017-07-16T10:00:30 [3561] - Replay.Core.Implementation.Repositories.RepositoriesNightlyJobsService ()Repository Repository03 (79998fb2-a403-4e23-8339-5d7430246576): Status:Mounted Bytes Used:32.25 TB Bytes Free:248.58 GB Compression Ratio:0.00 % Protected Data:27.71 TB
The parameter 'Compression Ratio' counts as 0% when the parameter 'Protected Data' is less then the parameter 'Bytes Used.'
Factors that can affect compression ratio:
Manual cancellations of Deferred Delete has shown to result in repository White Space. We strongly advise not to cancel Deferred Delete jobs and to stop the Core Service should you need to "cancel" a running Deferred Delete Task.
Once 0% compression occurs there is no solution to undo this. No matter which of the following workarounds you choose, the affected repository must be deleted and remade.
WORKAROUND:
Option 1
Option 2
If Agents are currently protected, you will need to point your Agents manually to the new repository. It may be faster to remove your agents from protection and re-add using Bulk Protect.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center