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

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
  • 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
Reply
  • 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
Children
No Data