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

Parents
  • +1 over 6 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.
Reply
  • +1 over 6 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.
Children
No Data