• 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
    PM's have a tough job. Sales drives every organization I have ever seen, support is a cost center. When asked between a huge re-write of the repository that will take 100's of dev hours have a ripple effect through every part of the product and will entice exactly ZERO people to buy the product or adding a support for X OS/Application and flashy new GUI, we all know what gets picked. None of what we ask for is ever going to be high on PM's list without some type of feature champion. This is what support used to do at some un-named large backup software company I used to work with. Support would track their own enhancements and prioritize. Then Support would assign champions to those enhancements they picked to try and shepherd them through the process. Support has to be responsible for items that are important to supports users or you end up in this situation where year after year we ask for the most basic function. I would like to be able to shut down the Core with a supported and easy to use option. And we still don't have it.

    I would love to see a detailed write up on replication. In fact an ongoing deep dive on certain functions of RR every week/month would be great. I think most of us know replication has some sort of resume function (but the details are basic at best) and we know it can be configured to handle duplicate bases but it seems like we kinda have to piece it together here.

    You mention this is how the product works but this enhancement request is the 5th most poplar (out of 74) so RR users certainly don't know or understand this. I can tell you from my experience that it certainly does not feel like replication handles interruptions or network issues very well even though I know there has been a resume function and block tracking for years.

    www.quest.com/.../why-does-replication-need-to-restart

    Maybe the idea post could be a great jump off point for PM's to hand over to support the write ups. If a user requests something that is already in the product, vs saying it is already in the product, have a detailed write up done on how to accomplish what they want. The 5th item in the replication enhancement request is a great example. If I was one of the 14 other people that had this issue and the reply back was that it was already in the product, it would not be as helpful as it could

    We are getting WAY off topic so if you want to remove all of the reply's after the first one from Tim that answered this, go ahead
Reply
  • 0 over 6 years ago
    PM's have a tough job. Sales drives every organization I have ever seen, support is a cost center. When asked between a huge re-write of the repository that will take 100's of dev hours have a ripple effect through every part of the product and will entice exactly ZERO people to buy the product or adding a support for X OS/Application and flashy new GUI, we all know what gets picked. None of what we ask for is ever going to be high on PM's list without some type of feature champion. This is what support used to do at some un-named large backup software company I used to work with. Support would track their own enhancements and prioritize. Then Support would assign champions to those enhancements they picked to try and shepherd them through the process. Support has to be responsible for items that are important to supports users or you end up in this situation where year after year we ask for the most basic function. I would like to be able to shut down the Core with a supported and easy to use option. And we still don't have it.

    I would love to see a detailed write up on replication. In fact an ongoing deep dive on certain functions of RR every week/month would be great. I think most of us know replication has some sort of resume function (but the details are basic at best) and we know it can be configured to handle duplicate bases but it seems like we kinda have to piece it together here.

    You mention this is how the product works but this enhancement request is the 5th most poplar (out of 74) so RR users certainly don't know or understand this. I can tell you from my experience that it certainly does not feel like replication handles interruptions or network issues very well even though I know there has been a resume function and block tracking for years.

    www.quest.com/.../why-does-replication-need-to-restart

    Maybe the idea post could be a great jump off point for PM's to hand over to support the write ups. If a user requests something that is already in the product, vs saying it is already in the product, have a detailed write up done on how to accomplish what they want. The 5th item in the replication enhancement request is a great example. If I was one of the 14 other people that had this issue and the reply back was that it was already in the product, it would not be as helpful as it could

    We are getting WAY off topic so if you want to remove all of the reply's after the first one from Tim that answered this, go ahead
Children
No Data