Live data from Hacker News

Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

codinghorror.com

41–50 of 175 posts

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#41
post #33
post #18

http://web.archive.org/web/*/http://codinghorror.com/ --PidGin128 via bmn

Looks like someone changed something near the end of June '08 that prevented archive.org from storing the site. Gotta suck.

they have a lag (it's supposed to be 6 months, but they're trailing that at the moment).

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#42
post #35

Earlier quoted context omitted.

Automatic validation is done through every backup (and I have my guys do a review of the logs from the nightly cron procedures). Once a month we test our restore procedures.

This is SOP in the real world.

Yup jokes aside. If you are not doing external backups and checking it at least once a month, you are doing it wrong. You can blame your host as much as you want, its equally your fault.

I learned it the hard way.

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#43
Here's Google's cached version of a post of his about backup strategies:

http://74.125.95.132/search?q=cache:2HHNAk2SB6EJ:www.codingh...

It ends in what is now irony:

"If backing up your data sounds like a hassle, that's because it is. Shut up. I know things. You will listen to me. Do it anyway."

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#44
I sympathize, but I have little patience for calling out your data provider when disaster strikes. Sure, there is likely some technical fault on their end, but ultimately you are accountable for your own site.

I'm not going to imply anything negative about him for losing the site temporarily. We all have "learning experiences"...

I just hope that when he does come back, he posts an insightful analysis of how he could have done more for his own reliability, rather than point fingers at a vendor.

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#45

"looks like it's 100% internet search caches for recovery. Any tips on recovering images, which typically aren't cached?" This does not sound like the tweet of a man with backups.

Wasn't he using Amazon S3 for images?

Cache of the relevant blog post: http://74.125.95.132/search?q=cache:yE0OdU1q6q4J:www.codingh...

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#46
post #8

Earlier quoted context omitted.

"ugh, server failure at CrystalTech. And apparently their normal backup process silently fails at backing up VM images." http://twitter.com/codinghorror/status/6573094832

egads... methinks CrystalTech will be experiencing a mass exodus. [Also makes me wonder how to test my host's backups]

[Also makes me wonder how to test my host's backups]

Make your own, don't rely on someone else.

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#48
post #5

Let me get this right: the guy who ran a site whose entire purpose is to make fun of other people's poor programming practices has no external backups?

I think you're thinking of Daily WTF. Jeff's blog is/was just a programming blog. He also frequently said he was the world's worst coder, so...

You're right, I often confused Jeff's blog with Daily WTF. Jeff might be self-effacing, but at the same time he also dispenses a lot of programming and software development advice.

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#49
post #43

Here's Google's cached version of a post of his about backup strategies: http://74.125.95.132/search?q=cache:2HHNAk2SB6EJ:www.codingh... It ends in what is now irony: "If backing up your data sounds like a hassle, that's because it is. Shut up. I know things. You will listen to me. Do it anyway."

The part you quoted is a quote itself, which could change the meaning for readers like me.

Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"

#50
Just my 2 cents here: I encrypt my daily sql backup before sending it in a couple of places. This way I can store it pretty much everywhere - one place is actually on a client's server. Aescrypt for encryption, ssh with expect for actual transfer. Oh, and watch out for expect timing out - it was a fun moment when backups grew beyond the default timeout and expect started truncating them. Yup, backups should be checked often.
Post reply on HN