• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 27 subscribers
  • Views 5149 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Compression 0%

daniel.santiago
over 5 years ago
Hello
I was having space problems in my repository, so to solve the problem, I paused all the jobs for more than 24 hours, so the rollups could complete, and it would not disrupt RPFS jobs in the background.
Today, my repository has more than 3TB of space, but the compression is still 0%. My doubt is. Is it necessary to complete RPFS jobs to start compression?
I ran a script now for more information.

QueuedFileVersions QueuedRPFSSize
134156 21.71TB

Do I need to wait to complete the compression?
  • 0 over 5 years ago

    https://support.quest.com/rapid-recovery/kb/158029/understanding-0-compression-in-an-appassure-rapid-recovery-repository

    Resolution

    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.

  • 0 over 5 years ago in reply to Emte
    I understood, today I have a lot of data in the repository. Unfortunately I will lose them. Thanks.
  • 0 over 5 years ago in reply to Emte

    Check Respository, would solved?

  • 0 over 5 years ago in reply to daniel.santiago

    If you are having the issue described in the article then it appears nothing will solve it short of deleting the repo. But if you are unsure, open a case with support

  • 0 over 5 years ago

    I agree with Emte. However, I would make sure you have some snapshots come in successfully before you make the call. The % compression reading on a repository relies on current snapshot activity (actual compression processing taking place) to give you a "reading" (much like a car's tire pressure sensor needs the car to be running to give you a reading - that may be a not so good analogy, but I hope you get my point). You may see that number pop back up after a few snapshots have successfully come through.

  • 0 over 5 years ago

    The compression ratio is purely a calculation comparing total protected data (raw data backed up) to used space in the repository. If total protected data is less than used space then compression will be 0%. So let's say you do a really big rollup or delete a lot of recovery points, since the delete jobs run in the background and don't free up space immediately, you can end up with 0% compression showing on the repository, but nothing is actually wrong. This is because you have deleted a lot of logical data, but the core has not yet freed up that space in the repository. Hence total protected data is greater than repository used space. My recommendation is to always wait until all deleting RPFS index file jobs are completed and then check the status. If it's still 0% compression, run a repository check (just the basic "check repository" in the GUI) to make sure there aren't any delete jobs that were cancelled or stuck in queue. After all deletes have finished and the repository check, see what the compression rate is. Since releasing RR 6.0.1 we have not seen a defect that causes 0% compression so it's unlikely that if you are running a 6.x build that you are actually experiencing 0% compression. 

    The other time you can see 0% compression is when you have an extremely large base image in process. The core does not update the total protected data value until the base image completes, but the used space in the repository increases while the base image is in progress. Hence if you are taking a very large base image and the repository used space is increasing then it is possible that could increase beyond the total protected data and push your compression rate down to 0%. Once the base image completes then you will see the numbers update and you will most certainly have a compression rate greater than 0%. If the job were to fail, the core would delete all the cached data from the repository (which would take some time) and then you'd see the rate return to what it was previously.

    Just remember, the core tries to compress and dedupe every block of data sent to it. So even if 0% compression is showing on the repository, it's still compressing and deduping. You just have to get to the bottom of why total protected data is less than total used repository space.