• State Verified Answer
  • Locked Locked
  • Replies 15 replies
  • Subscribers 28 subscribers
  • Views 17225 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

Repository growing faster than anticipated

davidc
over 7 years ago

Our repository is growing faster than anticipated.  I'm curious if there are any tools / methods available to try to get a grip on why...?  It could be deduplication not working as well as desired, or repository cleanup not actually cleaning up, or I simply may need to add additional storage.  I'd like to be able to investigate before adding more storage.

We have a 10 GB dedup cache on a backup/core server with 32 GB of memory.

We are running RR 6.0.2.144.  The core is Windows 2008 R2 Std.  We have approximately 14 TB of usable storage for RR on a SAN, and it is currently using 10.5 TB and growing at a rate of about 1 TB per month.

I have tried Repository Optimization.  Unfortunately, it runs incredibly slow and consumes pretty much all resources for RR during its run, causing backups/rollups/checks to take so long that they fail.  I'd be willing to pause everything for an Optimization task, if it could complete over a holiday weekend.  Unfortunately, in two days it will complete less than 10% of an optimization job.  I simply cannot halt all backups for a month (or more) for it to run an optimization. 

I'd also like to track repository usage over time.  Is there any log showing that, so that I do not have to manually keep a written log of repository usage?

 

Thank you

Parents
  • 0 over 7 years ago
    RAM increase should help because the server will then be within sizing requirements, but I do not have enough information to really guarantee you full confidence. More needs to be looked at such as disk speeds, memory speeds, processing, ect. I don't think running the optimize job will help a whole lot though to reduce repository usage at the moment, unless you recently increased your dedupe cache a lot within the last few days.

    Earlier you mentioned that deferred deletes were still in progress. As long as these jobs keep running, there is garbage to clean out of the repository. Once the deferred delete queue is at 0 (no more deferred delete jobs are running), you can get an idea what your repository usage really is at.

    You can get an idea of how many deferred delete jobs are left after a Core.service restart. Open the AppRecovery.log file and search for the term "uncommitted."
Reply
  • 0 over 7 years ago
    RAM increase should help because the server will then be within sizing requirements, but I do not have enough information to really guarantee you full confidence. More needs to be looked at such as disk speeds, memory speeds, processing, ect. I don't think running the optimize job will help a whole lot though to reduce repository usage at the moment, unless you recently increased your dedupe cache a lot within the last few days.

    Earlier you mentioned that deferred deletes were still in progress. As long as these jobs keep running, there is garbage to clean out of the repository. Once the deferred delete queue is at 0 (no more deferred delete jobs are running), you can get an idea what your repository usage really is at.

    You can get an idea of how many deferred delete jobs are left after a Core.service restart. Open the AppRecovery.log file and search for the term "uncommitted."
Children
No Data