Understanding 0% Compression in an AppAssure/Rapid Recovery Repository (4032498)

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."

• To quickly determine if the repository has irremovable data in AppAssure, open the AppRecovery.Log file search for "RepositoriesMetricsLogger"  This event is generated every night with nightly jobs and displays the repository statistics for all allocated repositories.

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.'

• To quickly determine if the repository has irremovable data in Rapid Recovery, open the AppRecovery.Log file search for "RepositoriesNightlyJobsService"  This event is generated every night with nightly jobs and displays the repository statistics for all allocated repositories.

Factors that can affect compression ratio:

• Staging area data: Replicated data sent to a Target Core is committed to the repository in a ‘staging area’ until the replication job completes
  • Data in the staging area does not have metadata and is only recorded in Bytes Used – depending on the amount of data in the staging area in relation to the repository size, this can throw off the Compression Ratio creating a false negative with 0% compression
  • If a replication job fails, the data in the repository stays in the staging area until either the job completes or the staging area is cleared by a repository check
  • When a replication job completes, the data is assigned metadata and is recorded in Protected Data and Bytes Used
  • If a repository check has run to clear the staging area, space is not returned until after the deferred delete jobs for data in the staging area complete
• Too much activity on the core: Large deletions, back log deferred delete queue, large rollups, or incoming large base images
  • If too much is happening at once, the core simply cannot catch up in a timely manner causing the compression ration calculation to not be correct
  • Incorrectly sized cores and slow Hardware can contribute to this as well
• Rollup: Deferred Delete cannot run during Rollup and vice versa with-in the same repository
  • If the core is constantly rolling up, Deferred Delete will not run for long periods of time resulting in a huge back log

• AppAssure 5.x Defect D-25051: “Deferred Delete job doesn't delete garbage from repository that has not been deleted by previous deferred delete job, if previous Deferred Delete job was paused/cancelled”
  • If you cancel a deferred delete job while it is running you can create white space it the repository equal to the amount of data not completed during the job
  • If this happens with large enough amounts of data you will have true 0% compression
  • Update 3 with 5.4.3.106 includes the fix for D-25051
  • Do not stop the core service while a large RPFS file is being deleted unless the fix for D-25051 is applied

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

• Archive the repository data to storage that is not on the repository volume
• Delete the existing repository
• Create a new repository (preferably using AppAssure 5.4.3.106 with Update 4 or the latest Rapid Recovery version)
• Import the archive into the new repository

Option 2

• Replicate your data to a Target Core
• Bring your Agents under protection on the Target Core
• Delete the Source Core repository
• Create a new repository on the Source Core
• Replicate your Agent data from the Target Core to the Source Core
• Once replication has caught up, add your Agents to protection on the Source Core
• Replication will need to reconfigured to point your Source Core to the Target Core if necessary

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.