Comment by no_protocol | Hacker News Reader

Comment by no_protocol | Hacker News Reader

Parent Full thread

I see some comments here from people wondering why anyone would use this or searching for use cases. I'll share mine.

I use tarsnap to keep daily backups of a web server with a handful of sites. I send over their content, configuration, and database backups. This isn't $$$-critical stuff so I just make a once-daily database backup and I'm fine with that. Every few months I verify one of the backups to make sure everything is still working, but it is extremely hands-off. I just don't have to think about it.

It is currently costing me about 3 cents per day. I could probably reduce that a bit with some pruning. It was 2 cents per day for a while.

Here is my most recent billing statement:

  2016-01-26 Balance                   43.152827492555316729
    Client->Server Bandwidth   8.2MB    0.002069643750000000
    Server->Client Bandwidth  41.2kB    0.000010296000000000
    Daily storage             3.35GB    0.027041509164110040
  2016-01-27 Balance                   43.123706043641206689

So far I have used a total of $7 of my $50 deposit. Let's hope Colin keeps the service running at least until I've worked through that. Might be a few more years, though. Here are my statistics:

  $ tarsnap --list-archives | wc -l
  496
  $ tarsnap --print-stats --humanize-numbers
                                         Total size  Compressed size
  All archives                               200 GB            86 GB
    (unique data)                            8.4 GB           3.3 GB

It appears I have been using it for about 496 days. I can access any specific day's snapshot and download it if I need. The 3.3GB here is the same as the 3.3GB for daily storage on my billing statement. I'm guessing that is also very close to the total amount of Client->Server traffic I have generated in my account's lifetime. Probably within a few percent? Not sure if I can quickly verify though.

2¢, 3¢, 10¢ per day, does that really matter? We are talking about less than a Starbucks for a full month of backups. Sorry, but developers who literally optimize cents over their time and effort is a pet peeve of mine.

2¢, 3¢, 10¢ per day, does that really matter?

It doesn't matter right now, but if you're building a company which you hope to scale up, it's good to have costs which won't get too big when said scaling happens -- because when your company explodes overnight, you're going to be too busy keeping everything else running to spend time reworking your backup strategy.

(Also: If you don't have backups now because you're "not big enough to have data worth protecting", you're going to be too busy to start doing backups when you suddenly do have data worth protecting.)

> but if you're building a company which you hope to scale up

This is a popular sentiment among engineers at startups and in my opinion founders should work hard to (kindly) beat it out of the team as soon as possible.

Basically, you can use that line to justify nearly any engineer hobby. We need microservices! We need message queues! We need master-to-master replicated NoSQL databases spread geographically! We need Redis, Kafka and Cassandra with a CQRS event source pumping data in there, oh and also to a Postgres so we can do arbitrary queries for management reports! We need our backups to cost not 3 but 2 cents a month!

But the truth is that, statistically, the chance that a startup will not actually scale up, is much bigger than the chance that once it does, the sharply increasing Tarsnap bill is going to drive it to bankruptcy.

I agree with you that you need backups from the start, but whether they cost $.02 per month or $10 per month initially really doesn't matter. There's a lot of features to build (and kill), users acquire, content to market, and the team is tiny.

I used to laugh about Twitter during their early growth days, fail whales all over the place. "What, they made that in Rails? Idiots". Now that I'm a startup founder myself, I realize that they did it perfectly right and I strongly doubt Twitter would've been what it is today if they had wasted time getting the perfectly scalable tweet processing timeline before putting the site out there.

I think it's a false dichotomy that great architecture and fast iteration are at odds. In fact, great architecture is what allows fast iteration to happen.

Yes, simplify your system by using as few moving parts as possible. But that also means don't use bloated frameworks that silently slow down your iteration pace with technical debt.

So many startups I've consulted with were stuck with having to redo core architecture right when they found market fit. It's a tough position to be in. The main rule to follow is that good design allows better design to happen later, it's worth investing in that

I fully agree and I don't believe anything in my comment contradicts yours.

> So many startups I've consulted with were stuck with having to redo core architecture right when they found market fit. It's a tough position to be in.

Good point, but watch out for survivor bias here: plenty startups failed before they reached product market fit, and some did so because they wasted time doing the wrong things. All things be told, I'd rather run a startup that needs to hire you to fix the core at the worst possible moment, than a startup that fails. But I agree fully nevertheless: good design begets good design and it really doesn't take much time.

> I agree with you that you need backups from the start, but whether they cost $.02 per month or $10 per month initially really doesn't matter.

For one service, no. But you can easily have one or two dozen such services, and then it really adds up, particularly with per-user or per-server charges.

Of course not. I'm mainly trying to show that it is incredibly cost-effective for this particular use case.

Sorry if my comment seemed rude, not my intention. I've had too much coffee and wound a bit too tight today.

I see what you're saying but like the breakdown anyway. The fact that it's "less than a Starbucks for a full month of backups" at 2-3 cents a day is a good, selling point. If it UI was layperson friendly, that line by itself would get a bunch of customers.

Honestly, I think he was just trying to illustrate how inexpensive the system is by showing how cheap it is and saying it could even go lower if someone cared enough (Which I don't think he does). That was my take away, not that he needed to optimize it

Reply on news.ycombinator.com