

Tarsnap and the prepaid billing model - cperciva
http://www.daemonology.net/blog/2009-04-18-tarsnap-prepaid-billing.html

======
10ren
This is partly the micropayment problem. The other way around it is to extend
credit, and bill people. I can see this is against your profitability rule.
Just saying it's another solution, in general.

You didn't ask for feedback, so feel free to ignore the following :-)

It would be nice to have a demo service, to play with before paying the $5.
You could limit it to a trivial amount of storage (like 100 bytes) - the
purpose is not to store stuff, but to have a play. An easier on-ramp helps
adoption, gives people a chance to kick the tyres.

 _If your account stays below zero, your backups will be deleted._ This is a
bit scary for a backup service. I'm sure you haven't actually deleted
anything, but it would be reassuring if you gave a schedule, e.g. emails every
day for a month (perhaps mimic the warnings of a domain name registrar). The
main thing is to reassure people, by communicating what you will do before
deleting their stuff.

One warning about "a service that you would use". A multinational corporation
has different values from an individual, and they will happily pay more than
you can imagine, if you can solve their problems. I guess this doesn't apply
to you, because bigger customers would setup their own backup, instead of
using your service (as you say). I'm just saying that your own sense of value
doesn't always translate to different needs - unless you can imagine yourself
as a multinational corp, I guess. :-)

~~~
cperciva
_It would be nice to have a demo service_

That might happen in the future -- the current architecture of the tarsnap
server makes this difficult (I don't have "total storage used by user X"
updated in realtime).

 _If your account stays below zero, your backups will be deleted_

Right now what I do is send out an email when an account balance falls below 7
days worth of storage, another email when an account falls below zero, and
then I wait a week after that before deleting anything. These timelines might
change in the future, which is why I haven't specified anything precise on the
website.

 _...multinational corporation..._

You're quite right -- but I didn't start this because I wanted to make life
easy for multinational corporations. I started this because _I_ wanted a good
backup system, and it seemed to me that while multinational corporations had
lots of good options available, there weren't really any good options for
people like me.

~~~
10ren
Thanks for your answers. You email timeline seems reasonable to me, but what I
meant was that you need to communicate this on your website. Otherwise, _the
user thinks_ that if they forget to pay, their backups are suddenly and
instantly lost.

------
babul
> But I'm building tarsnap first and foremost to be the backup service _I_
> would want to use -- and who wants to pay more than necessary? I certainly
> wouldn't.

Always good to see someone scratch thier own itch _then_ sell the solution as
_they_ would want it.

~~~
cperciva
Thanks! To be honest, getting rich has never been on my list of reasons for
building tarsnap -- I really just wanted good backups. But my idea of good
backups is a backup service, and in order for a backup service to be
sustainable it needs to make money, and in any case I couldn't afford to spend
two years writing code for tarsnap without a good chance of earning some money
from it later...

~~~
babul
A reliable revenue model only increases confidence in a service such as
backups. It is always good to know your backups won't disappear because the
service has gone bust.

~~~
cperciva
Absolutely -- and there have been more than enough examples of backup services
going out of business lately to make people worry about this. This is the main
reason I wrote my previous blog post:
[http://www.daemonology.net/blog/2009-03-09-tarsnap-
reaches-p...](http://www.daemonology.net/blog/2009-03-09-tarsnap-reaches-
profitability.html)

------
blasdel
_I find pricing tiers distasteful in general_ \-- A man after my own heart!

How do you manage the float of your users' prepaid balances?

~~~
cperciva
At the moment, I'm not really managing it. It's just sitting in paypal.

Unfortunately being a Canadian makes it hard to get USD out of paypal without
having paypal convert it to CAD at a really horrible exchange rate -- I'm
going to get a US bank account soon (a USD bank account at a Canadian bank
isn't good enough) to get around this problem, but I haven't made it that far
yet. Given how horrible interest rates are right now it's not as if there's a
huge amount of money to be earned on the float anyway -- the main reason I
want to get the money into a USD bank account is so that I can pay AWS costs
in USD instead of having those converted to CAD (at a really horrible exchange
rate) so that they can be billed to my CAD credit card.

~~~
Andys
While you're a startup it doesn't matter much, but if you become a larger
company, having the user's money that they haven't "spent" yet can be quite
irritating for accountants, depending on which accounting method is being
used.

In essence you have may have to refund "unconsumed" funds and this affects how
you do your books.

~~~
cperciva
Well, users' balances can be refunded whenever they want -- I'm not going to
hold onto someone's money if they want it back.

As for the accounting side of things: My understanding is (at least as far as
Canadian accounting goes, which is what matters to me) that it's handled as a
liability called "unearned revenue". So while it's certainly something to be
aware of for accounting purposes, it's not a big problem.

~~~
chmike
From the user perspective, I find this a very attractive policy. I considered
it for my own business model.

Do you refund 100% of the initial fee or do you deduce some processing charges
?

I'm thinking of this 7 day full refund law abused in the domain name business.
People would get a name, test its "responsiveness" in hits, and ask for a
refund of names below a threshold.

What protection do you have against such type of abuse of your refunding
policy ? Are the refunding cost "payed" by other clients ?

~~~
cperciva
_Do you refund 100% of the initial fee or do you deduce some processing
charges ?_

At the moment I refund 100% of any unspent amount. In light of payment
processing costs, I might change this to deduct a small processing fee (say,
$0.30 + 3%) in the future; but so far the number of people asking for refunds
has been sufficiently small that it isn't really necessary.

------
dhouston
prepay is a good tactic for small customers -- getting the entire lifetime
value up front in most cases.

but why are you bothering with customers spending <$1/mo? (we avoided pay-as-
you-go for this reason)

~~~
cperciva
I'm not sure exactly what you mean by "why are you bothering", so I'll answer
both versions of the question I can imagine you meaning.

If you mean "why bother charging them instead of making it free" -- as I
explain in the post, I don't want to get into a situation where I might have
enough small non-paying users that I end up losing money.

If you mean "why accept them as customers at all" -- well, thinking as a user
of my own service, I'd be really irked if I got told that I couldn't use a
great service simply because I didn't want to use it enough! But from a purely
business perspective: In my experience, small-scale users are some of the most
important ones to have, since they tend to be the ones who go around telling
everybody they know about tarsnap.

~~~
eru
And they might turn into larger scale customers later.

~~~
staunch
This is the very important part. I probably had my S3 account for a year until
one day I dumped hundreds of gigabytes into it. I used S3 because I already
had it setup and it was convenient.

------
smanek
Is there anywhere I can read more about Tarsnap's features/architecture?
You're obviously a bright guy, and you say you've been working on it for over
2 years, so I'm just curious about what exactly you built ...

For example, what advantages does tarsnap have over some bash scripts I write
in a few hours that give me off-site encrypted backups with the help of GPG
and rsync? (That's pretty close to the system I use now). I'm sure there are
some, but I just don't see them enumerated tarsnap.com ...

~~~
cperciva
The tarsnap website links to several of my blog posts about tarsnap, but this
one probably has the most information of interest to you:
[http://www.daemonology.net/blog/2008-11-10-tarsnap-public-
be...](http://www.daemonology.net/blog/2008-11-10-tarsnap-public-beta.html)

 _For example, what advantages does tarsnap have over some bash scripts I
write in a few hours that give me off-site encrypted backups with the help of
GPG and rsync?_

It's hard to say without knowing exactly how your scripts work, but I'd guess
that one big advantage tarsnap has is that it works with a snapshotted model
of backups.

~~~
smanek
Thanks, that answers my questions. Your snapshot system reminds of a reference
counting GC - neat trick.

~~~
cperciva
As it happens, tarsnap's snapshots work via reference counting -- fortunately,
it works better for tarsnap than it does for garbage collection. (Reference
counting breaks if you have circular references; this is a problem for garbage
collection, but not for tarsnap.)

~~~
eru
Why didn't you go for a 'real' GC?

~~~
cperciva
I have no clue what your question is trying to ask. Can you clarify?

~~~
eru
Why did you choose to do reference counting instead of more sophisticated
techniques?

I can imagine that ref. counting is much easier to implement and the drawbacks
are unimportant in your domain. However I'd still like to read about the
reasons for your decision, since you will have thought about that issue much
longer and clearer.

But I guess I should take a deeper look at
[http://www.daemonology.net/blog/2008-11-10-tarsnap-public-
be...](http://www.daemonology.net/blog/2008-11-10-tarsnap-public-beta.html)
before writing anything..

~~~
cperciva
Oh, now I understand. Methods such as reachability analysis require reading
lots of memory locations; but for tarsnap, "memory locations" are blocks of
data stored remotely, so this gets expensive (and slow) very quickly. With
reference counting, the counts can be stored locally and no extraneous data
needs to bs transferred to or from the server.

~~~
pmjordan
I guess there's a precedent there in the fact that unix file systems use
reference counting for file links, presumably for the same reasons.
Considering how well-architected tarsnap seems to be, I suspect you've taken
steps to avoid losing data via inconsistencies in the reference counter?

~~~
cperciva
_... you've taken steps to avoid losing data via inconsistencies in the
reference counter?_

There are some sanity checks built in, but in the extreme case what you're
suggesting is impossible. Reference counts are managed on the client side, and
the client has the keys necessary to delete blocks from the server; if the
client is functioning correctly, it won't get the reference counts wrong, but
if the client is malfunctioning then it could go berserk and delete blocks
without even looking at the reference counts.

I have taken care of the obvious issues, though -- as long as the OS
implements fsync() properly, there's no way that tarsnap or the client system
crashing will result in corruption.

------
greendestiny
I actually quite like pay in advance. If you're not really using a service
like you thought you can extend the use over a long period making it
worthwhile. Of course the same applies to pay for what you use, after the
fact, but then there is some ongoing mental load with remembering to either
keep or cancel your account.

------
staunch
If you're going to stick with this model you should definitely add an auto-
recharge feature. This is how I use my Skype account. I auto-recharge $10
every time my balance falls below $2. Very convenient. I don't have to have
$100 sitting in there for no reason, but I'm never out of credit.

~~~
cperciva
_If you're going to stick with this model you should definitely add an auto-
recharge feature._

I might do that at some point, but right now that would kill one of the key
benefits of the prepaid billing model -- right now, I don't need to store
credit card numbers.

------
robryan
I'm guessing that this wouldn't be competitive in the market at a higher price
point? From a personal viewpoint if I was going to pay for a backup service
i'd be open to paying more.

I guess free alternatives would make that hard to be a competitive business
move though?

~~~
cperciva
There are certainly backup services which are more expensive than tarsnap --
Mozy, for example, charges $0.50/GB, and rsync.net charges $2.10/GB for their
georedundant storage (which is probably still far less reliable than the
backing storage for tarsnap). But I don't particularly want to find out
exactly how much I can gouge my customers; I'd prefer to have a comfortable
profit margin and hope that reasonable prices result in more people using
tarsnap.

------
acangiano
Too bad this is not available in Canada. I would love to pay for this service.

