Unexplained High Storage Usage

Customer Support Customer Only Discussion
1

I filed a TT (RS #IRV-94322-235) regarding a customer of mine. HSphere generated an over-storage limit message.

On investigating, this is what I found using HSphere generated stats from my RCP:

Nov 3
– Storage: 111MB
– Bandwidth: 630KB

Nov 2
– Storage: 111MB
– Bandwidth: 1.6MB

Nov 1
– Storage: 111MB
– Bandwidth: 5.9MB

Oct 31
– Storage: 108.4MB
– Bandwidth: 1.2MB

Oct 30
– Storage: 0.16MB
– Bandwidth: 164KB

Oct 29
– Storage: 0.16MB
– Bandwidth: 506KB

The customer has a storage limit of 100MB.

At present, there are NO files even approaching a megabyte in his FTP space. This was also true yesterday.

All of his very few email accounts are set to a 15MB mailbox limit and he downloads his mail and deletes it from the server as part of the POP processing.

This begs the questions:

– If a customer has no way to put files into his storage allocation WITHOUT consuming metered bandwidth, how did he get a 111MB file(s) into his storage when his largest bandwidth usage was just under 6MB in any one day. Indeed, ALL of his bandwidth for the relevant days is under 11MB–100MB short of what should show up if he had, in fact posted a file(s) or received a huge email attachment.

– Why is it I can’t get the Jodo techies to explain to me how this could’ve happened? The first response was, essentially: “Are you still getting overlimit notifications?” That wasn’t very useful.

When I once again posed the how and why questions, I got the “customer must’ve done it because both mail and web services are activated.” Hint: just because a service is activated doesn’t mean it’s being used. This is the case with this customer–he doesn’t have a Website. I activated Web service as part of the standard account creation process for this plan type.

– Why does it take so long to respond to a TT? The first response was about 4 hours. The second response was about 16 hours.

So…I’d appreciate an explanation of how the customer might’ve put 111MB of storage onto the server without consuming at least that much bandwidth. And if, in fact, the customer didn’t (and I have strong reasons to believe he did not), how did the error occur in HSphere? And if this isn’t a likely HSphere error, then just who did consume this amount of storage? Is there a security breach somewhere?

Thanks

Charles

2

Charles,
We can’t answer a ticket like this in under 48 hours, it has to go to psoft. Sometimes we don’t know why storage may jump like that either. It could be as easy as a log being read incorrectly or as complex as a database entry in the psoft written with 1 digit wrong. It happens sometimes :slight_smile:

Oh, at from thursday to Sunday night is no mans land at psoft, they hardly answer anything during this time period.

3

Stephen

That’s a reasonable answer and I accept it. It also implies that this is not an unheard of problem and that a likely answer may be a glitch in the software, not the end user doing something that makes no sense.

If you review the ticket, the answers I received were not so simple and reasonable. That’s what I think, not to put too fine a point on it, rots my socks a bit.

For the moment, I’ll assume this is an HSphere hiccup. If, however, the storage report doesn’t return to its normal sub-MB status by tomorrow, I’ll probably revisit this with you guys to see what might be done to kill the alerts and to avoid the hassles of putting the customer into an overage, over-billing situation.

I’ll also assume that this ticket will remain open until something comes back from PSoft?

Thanks for the quick, reasonable, and understandable answer, Stephen.

Charles