• State Suggested Answer
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 10399 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

Deferred Delete / Repo space

Emte
over 6 years ago

Does anyone from RR have any insight into the Deferred Delete Process and/ or managing full repo's?

 

1) Deferred Delete

I cant find a lot of info on deferred delete past https://support.quest.com/rapid-recovery/kb/198715/understanding-deferred-delete-in-nightly-jobs

- How is it different than the normal deleting rpfs index file jobs? Does it just run after a delete is performed vs waiting till the nightly?

- Is there any reason not to enable this (and if not, why is it not the default) 

- If we upgrade to v6 and enable deferred delete (or the normal nightly job) Will this clean up v5 repos that were affected with several bugs from v5 repos, such as the ones documented here

support.quest.com/.../understanding-0-compression-in-an-appassure-rapid-recovery-repository

 

2) Full Repo's

I wish you guys would take a look at this entire repo situation. We constantly have sites call us with full repo's and it is a pain to deal with. The Cores are always in this catch 22 where you need space to free up space and we always seem to end up doing something we don't want to do just in order to get it running again and each time, what we have to do seems different. These types of posts go back years without any change, the forum suggested 2 of them as "solutions" to me when I was creating this one

Some idea's

- Have the Repo reserve some space for performing jobs that clear up space, like deletes, rollup etc. Make it so this space can not be consumed long term, EVER

- Have the Core stop backup when the repo reaches a certain % full or even better a % of the total size. So a working % is stored if the repo is 500GB or 50TB, make this configurable

- Have some sort of external space that can be used for jobs like rollup, RP deletes. Even if we had to add a storage location to the repo that was used for this process ONLY. so we could add it, delete data, run rollup and then DELETE the storage location from the repo (long shot, probably)

 

Or maybe I am missing something that is already there? If so, I would love a bit of guidance

 

Thanks in advance

Parents
  • 0 over 6 years ago

    1) Deferred delete in the nightly jobs is an option that you can enable. What it does is reserve time for the deleting index RPFS file jobs to run. So if you have a very busy core where jobs are constantly running and blocking the deletes, you can enable this job and specify a duration for it allowing the job to run and block all other jobs from running during this time period. The goal being to allow the repository deletes to run unhindered by other tasks for a defined quantity of time.

    One reason not to enable it is that it blocks other jobs for the duration that you specify. Another reason not to enable it is that it changes the job compatibility logic for deletes. Currently Deleting Index RPFS files jobs run in the background and do not affect other jobs. When you enable this nightly job not only do you get a window at night in which the deletes can run, but outside of that window the delete jobs are moved into the job queue and block other jobs from running. So if you have a single delete job that is large and takes a couple hours to complete, while it is running it will block backups and replications.

    Upgrade from version 5 to version 6 does not fix any issues that may exist in the repository related to defects in version 5 such as the ones that create white space. Once white space exists in the repository there is no way to remove it. You have to archive the data, delete the repository, import the data, and add the agents back to the repository. That is the only solution at this time. I highly recommend upgrading all your systems to Rapid Recovery 6.x since version 5 has reached end of support and all of the repository impacting defects in version 5 have been fixed in version 6.

    2) The core has alerts built in that can be enabled to warn of the repository filling up when certain thresholds are passed. I want to say they are at 80% and 90% full (but don't quote me on that). At this time we have chosen not to put any limits on how full we will allow a repository to get or marked storage space for maintenance tasks only. So our recommendation is to enable the alerts and then when storage starts to fill up, make sure to manage that space and don't overfill the repository. I'm sure that's not what you want to hear, but that's how the software has been designed as it exists now.

    I have sent your forum post over to our Product Manager to ensure he sees it as I think you have some good ideas here and he is adding these to his list of items to review related to repositories filling up and managing data.

Reply
  • 0 over 6 years ago

    1) Deferred delete in the nightly jobs is an option that you can enable. What it does is reserve time for the deleting index RPFS file jobs to run. So if you have a very busy core where jobs are constantly running and blocking the deletes, you can enable this job and specify a duration for it allowing the job to run and block all other jobs from running during this time period. The goal being to allow the repository deletes to run unhindered by other tasks for a defined quantity of time.

    One reason not to enable it is that it blocks other jobs for the duration that you specify. Another reason not to enable it is that it changes the job compatibility logic for deletes. Currently Deleting Index RPFS files jobs run in the background and do not affect other jobs. When you enable this nightly job not only do you get a window at night in which the deletes can run, but outside of that window the delete jobs are moved into the job queue and block other jobs from running. So if you have a single delete job that is large and takes a couple hours to complete, while it is running it will block backups and replications.

    Upgrade from version 5 to version 6 does not fix any issues that may exist in the repository related to defects in version 5 such as the ones that create white space. Once white space exists in the repository there is no way to remove it. You have to archive the data, delete the repository, import the data, and add the agents back to the repository. That is the only solution at this time. I highly recommend upgrading all your systems to Rapid Recovery 6.x since version 5 has reached end of support and all of the repository impacting defects in version 5 have been fixed in version 6.

    2) The core has alerts built in that can be enabled to warn of the repository filling up when certain thresholds are passed. I want to say they are at 80% and 90% full (but don't quote me on that). At this time we have chosen not to put any limits on how full we will allow a repository to get or marked storage space for maintenance tasks only. So our recommendation is to enable the alerts and then when storage starts to fill up, make sure to manage that space and don't overfill the repository. I'm sure that's not what you want to hear, but that's how the software has been designed as it exists now.

    I have sent your forum post over to our Product Manager to ensure he sees it as I think you have some good ideas here and he is adding these to his list of items to review related to repositories filling up and managing data.

Children
No Data