Please don't. Just pocket the margin. The prices should have gone up, anyway.
This is what happens when one's pre-paid Tarsnap balance goes to zero:
You will be sent an email when your account balance falls below 7 days worth of storage costs warning you that you should probably add more money to your account soon. If your account balance falls below zero, you will lose access to Tarsnap, an email will be sent to inform you of this, and a 7 day countdown will start; if your account balance is still below zero after 7 days, it will be deleted along with the data you have stored.
I was N days from hitting a the 7 day warning, so 14+N days away from hitting "Lose all my business' backups for the last several years." It is possible that I would have gotten really lucky and seen those emails (which I was, by definition, not particularly expecting) rather than, oh, being on a business trip in April and finding about them after the fact.
I cannot put enough underlines under I Would Consider Losing All My Backups A Failure Mode.
Even after de-duplication and compression, my company stores about 400 GB of data with Tarsnap. Tarsnap is a double digit percentage of our monthly infrastructure costs.
I think, perhaps, it's rather that the value that a business backing up a 30 MB database every day gets isn't radically different from the value that we get backing up several orders of magnitude more than that.
The question really is if straight utility pricing makes sense. I could imagine that a floor on the pricing, or a non-linear curve would probably do better than simply keeping the same model and raising the prices. There's also a question of distribution of total revenue -- if the revenue for the small accounts was increased by 10x, would it balance out a 50% loss of large accounts?
No. You wouldn't be far off if you assumed that 100% of Tarsnap's revenue came from large accounts.
The question is if the costs of running tarsnap correlate exactly with the amount of data that is stored, or if the number of users also have to be factored into the equation, ie. if each additional user has an added cost. I would say that in a business like this, with a low barrier to entry, the price should reflect the costs as close as possible. So if there's a constant setup cost for each user, the price shouldn't be $X/GB, but $X/GB + $Y.
Ideally, Tarsnap should make the same amount of money from a single user storing 100 TB and 100×10^12 users store a single byte. If this is not the case, the pricing structure is suboptimal.
Edit: in most HNers opinion.
While I'm at it, a feature I would love to see in tarsnap is server side pruning of old archives so I can remove the delete permissions from my production keys and not have to setup a secondary pruning server.
That's not possible -- the service doesn't know which old blocks are being reused in new archives.