I want to make a snarky comment, but I just feel for the guy.
I'm with ya. This sort of thing can sneak up on you.
Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
131–140 of 175 posts
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#132I want to make a snarky comment, but I just feel for the guy.
I feel for the guy too, but it really isn't the first time in the last couple of months that some service provider fails at their #1 stated goal: to keep your data safe.
And it isn't just the small ones either.
For the love of - insert your favorite deity here - please try to restore your backups, and try to do so on a regular basis. If not all you might have is the illusion of a backup.
It is a very easy trap to fall in to, and I really am happy this guy writes about it because it seems there are still people that feel that if their data is in the hands of third parties that it is safe.
That goes for your stuff on flickr, but it also goes for your google mail account and all those other 'safe' ways to store your data online. In the end you have to ask who suffers the biggest loss if your data goes to the great big back-up drive in the sky, the service provider or you. If the answer is 'you' then go and make that extra backup.
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#1331. Register an Amazon AWS S3 account - https://aws-portal.amazon.com/gp/aws/developer/registration/... 2. Download my S3 backup script (or anyone's S3 Backup script) - http://github.com/leftnode/S3-Backup 3. Set up a cron to push hourly/daily/whatever tar's of your vhost's directory to S3. Spend, like, $10 a month. Thats 30gb of storage, 30gb up and 30gb down. Now, I know that may not be a lot, but I doubt codinghorr…
I do the same thing, with a script using ruby s3sync I wrote a while ago (that I should probably update): http://paulstamatiou.com/how-to-bulletproof-server-backups-w...
s3sync is great. I'm using it for automated backups for a number of work projects. Thank you for writing it and sharing it.
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#134Earlier 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.
No it's not.
It should be. It might even be in some of the plans. But most of the time it doesn't happen.
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#135Earlier quoted context omitted.
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...
Well, he did make sure to tell us to shut up, stop what we're doing and make a back-up. Because he knows things, you see: http://74.125.93.132/search?q=cache:2HHNAk2SB6EJ:www.codingh...
Jamie Zawinski said to shut up, stop what you're doing and make a back-up. Jeff simply spread Jamie's message to a wider audience, rather than claiming it as his own.
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#136I've backups of my silly blog antirez.com, this guy ran a business out of his blog and don't have external backups. The data is small, it is easy to transfer. It's almost unbelievable to me.
Did he? I thought Jeff had some "real job" in addition to blogging and Stack Overflow. I honestly doubt an occasionally-updated programming blog was putting the food on his table.
For several years he made this post every working day:
inane comment showing strong naivete
copypasta
copypasta
Confident summary with conclusive statement
displaying no comprehension of the quoted text
Buy a Visual Studio Plugin from my sponsor!
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#137Earlier quoted context omitted.
Joining the chorus of other people saying "WRONG". Reason 1: I pay for my bank account one way or another. It's bank's responsibility to keep the system running and secure, not mine. Sometimes we just can't do everything ourselves and have to rely on others. Reason 2: Many of us host something somewhere. How many do backups? How many of us check the backups? How many do check the backups checking process? (enter infi…
The bank analogy is interesting and a good point, but the reality of ISPs is that they are less reliable, and less regulated, than banks. If my income is dependent on data, I make sure it gets backed up. If it's an active project, I use my backups to build my dev environments so it's fairly obvious when a backup has failed.
You have good habits, and that's sincerely commendable.
However, it really isn't fair to blame this kind of problem on the end user.
Are website developers also expected to keep the servers secure? If Apache isn't patched and up to date, is that the website admin's fault?
Service providers are paid to do a job. This one failed tremendously, and should lose a large chunk of business for it. I think Atwood is being far too kind in accepting 50% of the responsibility for the data loss.
To put it another way: the only reason to maintain your own backups of your site data -- aside from healthy paranoia -- is because you expect your service provider to fail at doing their job. And if that's the case, shouldn't you be finding a service provider that does it better?
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#138Just 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 checke…
Do not use SSH with Expect.
Do not use them here or there.
You will not use them anywhere.
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#139Earlier quoted context omitted.
Yes, but I'm not sure if your comment is targeted at CrystalTech or codinghorror? You can't outsource liability. If YOU are not testing YOUR backups. YOU fail.
It's a blog. How much time and money is worth spending on this? (I backup my Slicehost account with their official service. If they die and my backup dies with it, that's fine; I don't have the time or money to do anything better.)
If I was in his shoes, yeah I'd be freaking out too and trying to get everything recovered ASAP. Then again my blog pays more than my (startup) job so that's why I care about it.
Re: Coding Horror and blogs.stackoverflow.com experience "100% Data Loss"
#140Earlier quoted context omitted.
Yeah, but if you pay for a mission critical service and never bother testing it, you've pretty much passively decided to fail.
Joining the chorus of other people saying "WRONG". Reason 1: I pay for my bank account one way or another. It's bank's responsibility to keep the system running and secure, not mine. Sometimes we just can't do everything ourselves and have to rely on others. Reason 2: Many of us host something somewhere. How many do backups? How many of us check the backups? How many do check the backups checking process? (enter infi…
Reason 1: I pay for my bank account one way or another. It's bank's responsibility to keep the system running and secure, not mine. Sometimes we just can't do everything ourselves and have to rely on others.
You are responsible for reading your statement and ensuring that all activity is valid, much in the same way that you are responsible for ensuring the viability of your recovery strategy.
Reason 2: Many of us host something somewhere. How many do backups?
Anyone who wants to keep their data badly enough to pay (time, money) to do so. Coding Horror is a popular technology blog, and there's a significant cost in traffic and credibility when it fails.
Jeff Atwood lacked cognizance of the risks and made an incredibly poor technical and business decision in failing to validate correctness of his backups and implement a suitable recovery strategy.