Database growth

Question

We've had DPA running for almost 2 years now.  Currently running ver 18.2.  OS: Linux I recently 'inherited' the management of DPA (as well as the rest of our Backup/Recovery framework) A little over a week ago, the email reports that we had been getting daily stopped.  I logged on to the server, and restarted services.  Immediately after that, my inbox got the email reports I was used to seeing.  The next day, same thing - no daily email reports.  I noticed that it was only the datastore service that had stopped.  Restarted it, and got my emails.  Well, once, and I wouldn't worry too much, but twice in a row means something needs to be done ASAP  : ) It was then that I noticed the drive was getting full.  We had a 400gb drive which had next to no free space left.  I added 50gb, and all was well (or so I thought). I figured that should be good for a good long while.  Fast forward to today, and an additional 25gb or so has been consumed already. It's only been about a week. After adding space, I had already gone through the Data Collection defaults - changed many things to manual (don't know if that helps much - after all, if it doesn't exist in our environment, it wouldn't take up much space anyway, right?), and reduced retention where I thought it was okay to do so without losing historical data that might one day be useful. My questions are: - Is this kind of growth normal?  - Can I do something other than just reducing the data collection retention period and interval?  - Also, why is the space taken by indexes bigger than the data itself?   Any help or insights would be appreciated

CrashCart · Accepted Answer

I contacted support and they helped me with this issue.

First, we ran some capacity planning reports in DPA - this gave us a report on the size of the 10 largest tables and indexes. (the important thing is the names of these tables and the schema name)

Then, in a SSH session, we ran a "ds" command to perform a VACUUM on those tables. Since drive was pretty full at the time, I started with the smaller tables listed in the report, and moved on to bigger ones last (Postgresql documentation states that to perform a Full VACUUM one may need free disk space up to the actual size of the database to work, as it basically writes new tables. I didn't have that much space left so I started with the smaller tables first, and worked my way up from there)

Worked better than I hoped - a LOT of space was recovered. There must have been something that kept the background maintenance from happening in the past, causing the tables to be filled up. All good now.

Thanks to Dell EMC support

Anonymous · Answer

Nice Solutions

Data Protection Advisor

Was this post helpful?