• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 27 subscribers
  • Views 3668 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

Quest vs Dell compression

lbuck
over 5 years ago

We have a couple of DL appliances that we've had for 3 years.  For the last year and half everything has been good with it with the same number of protected machines and retention rate settings so that it was close to max capacity.  Earlier this year I upgraded from the Dell to the Quest version.  Since then, I've had to remove 5 protected machines and reduce drastically the retention settings and even then, I'm constantly getting warnings about the Repository being full and when it hits the max, no new recovery points get saved.  Is the compression or deduplication or whatever it is, that much worse with the new Quest version?  Is it a matter of waiting it out till all the Dell recovery points are gone?

  • +1 over 5 years ago
    Nothing changed in the underlying dedupe engine between the Dell branded AppAssure/Rapid Recovery and the Quest branded Rapid Recovery. More than likely what you are experiencing is the change in the way deletes happen. To ensure that deletes do not get missed and cause white space in the repository, a queueing function for deletes was added. On extremely busy cores, this function can fall behind since it can be blocked by other jobs and so data is not removed from the repository. On the older builds where this didn't exist, the delete happened as the rollup job was happening. This meant that rollup took longer and it actually deleted the data. It's just a change in how the software handles the deletes. I would encourage you to look at the events tab and then clicking on the gear icon in the filters to show what background jobs are running. If you constantly see "Deleting Index RPFS Files" jobs running then that indicates that the delete jobs are behind. At that point I'd encourage you to look at this KB article - support.quest.com/.../understanding-deferred-delete-in-nightly-jobs - and consider enabling the deferred delete nightly job to give the core server time each night to process the delete jobs.
  • 0 over 5 years ago
    Thanks for your reply and suggestion. While it wasn't the issue, the cores are not busy and there is a lot of times when no events are running, it did make me look through the event logs for the protected machines looking for when rollups were happening and I didn't find any. I then took a closer look at the retention policy and the exiting recovery points and realized that the retention policy isn't being followed. To my limited knowledge, it looks like no rollups or deletes have been done since Feb when I upgraded to Quest. I did a Force Rollup on one protected machine and it went from 13 pages of recovery points down to one.

    I attempted to do Force Rollups on the other machines and unfortunately it looks like half of them error out with
    •The given key was not present in the dictionary.
    •The remote slave core with the id '9b3968d5-86c0-4e7a-90b4-0e5cfe07aa8a' was not found

    I'm assuming it is trying to do the rollups but encounters this error and then doesn't attempt any other machines. So now I got to look at this.
  • 0 over 5 years ago
    Run a repository check. If that doesn't help, then open a support case. That's an issue with the data in the repository. The repository check function can fix some issues in the repo. Other problems have to be addressed with help from support.