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

  • +1 over 7 years ago
    Hi davidc,

    With the provided information, my thought is that the Core is undersized in resources, which may be causing deferred deletes from running efficiently. Below is information on proper sizing and the deferred delete process.

    Please provide us with your compression ratio and deduplication percentage found on the Core summary page.

    support.quest.com/.../198715 - Understanding Deferred Delete in Nightly Jobs
    support.quest.com/.../145697 - Repository free space status incorrect after deleting recovery points

    Rapid Recovery Sizing Guide 3.0: support.quest.com/.../downloads
    Note: "If the Rapid Recovery Core server is running on Windows Server 2008 or 2008 R2, add an
    additional 2GB of RAM per TB of repository space. " Page 16
  • 0 over 7 years ago
    Derek,

    Thank you for the reply.

    Deferred Deletes appear to be working correctly; there are lots of them, and no errors for any "deleting index" or "persist dedupe" tasks. In fact, for the past month, the only error in the log was a couple missed backups.

    However, they were not set as part of the Nightly Jobs. I have enabled them, there, and will monitor the situation.

    I took note of page 16.. may I ask what it is about Win2008 that requires such a leap in memory, as opposed to Win2012/2016?

    Upgrading the memory will require upgrading the OS to Enterprise or Data Center. We'll have to think about that one carefully. Currently, the backup/core server has 5.5 GB of available memory, and it is rare to see that bottom out.
  • 0 over 7 years ago
    I'm still looking for a way to chart Repository usage over time. Is there some record/log kept of this by RR ?
  • 0 over 7 years ago
    Also interested in finding a way to run an Optimize job without it grinding the server to a complete halt for literally weeks at a time. Is there a way for RR to handle an Optimize job gracefully (ie. pause it during other operations, or some other option where it does not compete with other operations for resources)??
  • 0 over 7 years ago
    The Optimization Job does require a lot of resources. So the undersizing of the RAM may be the culprit here. Additionally, the size of the dedupe cache being 10GB would impact the performance. I have seen these jobs take some time, but still allowed the Core services to be usable.
  • 0 over 7 years ago
    This KB describes the memory usage for Server 2008/R2 and a registry setting that helps reduce memory consumption: support.quest.com/.../119686
  • 0 over 7 years ago
    You can run the Repository Report and have it emailed to you on a schedule with the instructions here: documents.software.dell.com/.../understanding-the-repository-report

    and here:
    documents.software.dell.com/.../scheduling-a-report
  • 0 over 7 years ago
    The registry value, "WriteCachingPolicy", does not exist. I want to check before creating it, and also check that it is a dword...?

    Thanks
  • 0 over 7 years ago
    WriteCachingPolicy should exist as its a default registry entry. Verify you're in the correct "Specification" section, which is would be under "FileConfigurations" -> "0" (starts at 0 and then increments) -> "Specification".
  • 0 over 7 years ago
    You caught me. I was in the wrong location. We have two entries for FileConfigurations (two locations in our repository). One is already set to '3'. I'll adjust the other from '2' to '3' this weekend. Thank you.