4 ms·

We tried. Devs when give more space just didn't bother to clean old crap and exact same thing happened but with few months of delay. But then we generally just

• atoav 3y ago
  In my case the data was a dummy database of more dummy users than are at our org (maybe 50% more). So once this goes to production it would likely get smaller. The problem in this case was twofold: - admin had the job to implement database backups. He didn't factor in backup size when allocating disk space. So this was wntirely his own fault. - the database does store certain transactions for a certain period, so this grew initially until it it setteled at a certain level. Because the margin of storage was slim, this caused the problem
  • ilyt 3y ago
    ...did you communicate any of that ? Because most of our cases where that happens was either lack of planning or lack of communicating that plan. By far most common one was "neither dev nor client knows the data volume in longer period". Which is fine as long as that's also communicated, but that's also often a problem. But I'm not denying of course that there are just shitty incompetent ops departments, just for the other customer we had dealing with ops department that had: * backup storage (which was some remote FTPS server IIRC) provisioned so slow the backup wouldn't copy within 24 hours. And the backup size was below TB. * weeks long delays with any resize.