News for hackers. Stuff that matters.
Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @11:51AM (#10771973)
Until your control panel gets hacked and you lose all your data. See: codespaces.com (assuming it wasn't an inside job or a dumb mistake, but even then the same rules apply). So no, DON'T BLOW ANYTHING INTO THE CLOUD THAT YOU DON'T HAVE A COPY OF.

It has nothing to do with 'not invented here', it has everything to do with your inability to outsource your responsibilities.

The degree to which people rely on others to take care of their stuff is a huge blind-spot. Jason's advice is spot on in this respect, no matter what the up-time guarantees of the cloud solution you are using (and no matter what the redundancies), if you store all your data in the cloud without an off-line copy your company is 3 mouse clicks away from being history.

Re:Fuck the Cloud (2009) by Domenic_S on Monday December 21, 2015 @12:29PM (#10772190)
The 3-2-1 rule is a rule for a reason.

3 copies

2 formats

1 copy off-site

The cloud is a great place for that 1 off-site copy.

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @12:48PM (#10772284)
Assuming the rest of your data isn't in the cloud, yes. Otherwise reverse the situation. But you got it perfectly.
Re:Fuck the Cloud (2009) by ajross on Monday December 21, 2015 @03:35PM (#10773325)
No argument at all about the last sentence, but you should have skipped the first four lines as wildly premature optimization.

The vast majority of the world would be much better served by (to appropriate your jargon) a 2-1-1 rule, because it's a straightforward treatment for a straightforward problem that is easily implemented. Yes, "format skew" and double-failure of backup solutions does indeed happen, but at a much lower incidence than "oh crap I deleted it!".

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @03:49PM (#10773406)
I think the 'three copies' rule refers to cyclic backups, not necessarily three copies of the one piece of data.

This protects against data corruption that is not detected immediately.

Another common way of doing this (and one that I prefer) is one where you rotate out a backup medium with ever larger intervals. So one gets set aside per week, then one gets set aside per month and so on. That gives you a series of snapshots in time that will allow you to pinpoint with some accuracy when an event happened. Longer ago you'll have less accuracy but this can help a lot in trying to triangulate who or what messed up. Just being able to answer the question of whether or not 'x' happened before 'y' was hired or after can help in narrowing down the number of suspects in case of a breach or other nastiness. It also prevents against back-ups for whatever reason not wanting to be reloaded (and you should guard against that by loading your back-up immediately after you make it, even so, the medium might fail the next time you try a read).

Better still if there is a streaming log of everything but only very few companies can afford that sort of solution for all their data. Those can be hard to restore from (by replaying) so there too a snapshot system can help.

Re:Fuck the Cloud (2009) by ajross on Wednesday December 23, 2015 @11:44AM (#10784137)
Oh sure, there's lots to say about the design and effective use of a backup regime. I agree with all that stuff.

But if you're going to condense it to a "rule" that will help people not well-versed in the field, that rule can only be "MAKE BACKUPS!", because at least 90% of the data loss scenarios in the real world happen because simple backups weren't made.

Don't make it more complicated than it is, because someone will stop to do it "right" and then lose data because they didn't just make a copy on a USB stick.

Re:Fuck the Cloud (2009) by phinullfermata on Monday December 21, 2015 @01:55PM (#10772690)
Modern 3-2-1:

3 backup services 2 formats 1 local copy

I guess that could get expensive depending on the services.

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @02:14PM (#10772810)
Yes, it could be. The trade-off is usually measured by the cost to the company of re-creating or losing the data entirely. So for some stuff such a system is feasible, for others it isn't and then you'll have to compromise. Log data for instance does not need to be stored like that unless there are legal rules saying that you have to keep it no matter what.

For each business this is a delicate affair and you should spend some time on figuring out what you really absolutely have to have and what you could lose without losing the company or getting in trouble with the law.

Re:Fuck the Cloud (2009) by fixermark on Monday December 21, 2015 @12:08PM (#10772082)
What's the relative risk that my specific control panel will get hacked and I, specifically, will lose all my data, vs. the risk that data on my local store will be compromised by a virus on my computer encrypting my whole hard drive and refusing to let go until I send XYZ bitcoins to a specific address?

There's risks and then there's risks. As always, you can spend some time and money to mitigate some risk, and decide some risk is low enough that you don't care to mitigate it. I wouldn't just assume one risk vector is higher than another without some concrete numbers.

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @12:42PM (#10772247)
There's risks and there's bankruptcy. If you feel like gambling then be my guest. What's the risk of your house catching fire? Are you insured? What are the risks of getting burgled? Your car stolen, a car accident? Are you insured?

What are the risks of having a bad health issue happen to you? Are you insured?

I'll bet that you don't know the answers to any of those questions, and yet, you are probably insured against all of them.

As for your question in more detail: it happens often enough that for me if you operate your business 'in the cloud' and you don't have a back-up of your data outside of the cloud to guard against catastrophic data loss due to either malice or accident that I'll happily fail you. Think 'sysadmin was depressive, wiped out company' (or maybe you let him/her go and they took revenge or any one of a number of other scenarios that would instantly terminate your existence online if you had not guarded against it).

Risk management is consequences * incidence versus cost to mitigate. If the cost to mitigate is negligible, the risk is measureable and the consequences are terminal then it is a no-brainer to protect yourself against this. At least one of my customers wished they had set up a backup facility for their critical data (too bad, end of story for them) and there is one published case that we all know about. That's two that you can count on and most likely other trouble shooters have similar stories.

I see catastrophic cloud data loss as having a much higher chance of happening than many other items on the list of stuff that I verify before greenlighting an investment.

Re:Fuck the Cloud (2009) by fixermark on Monday December 21, 2015 @12:56PM (#10772331)
I see what you mean; I read "DON'T BLOW ANYTHING INTO THE CLOUD THAT YOU DON'T HAVE A COPY OF" and thought of only my personal data (because if it's user data, it's originating from the cloud and I'm not blowing it into the cloud; if anything, I'm pulling it out of the cloud).

Though if we unbox that a bit... How do we balance the risk of loss due to your cloud being owned vs. loss due to the risk of your users' PII being violated if someone attacks your in-house (ostensibly in-house reliability and security-managed) copies? Better make sure you're spending the money on security best-practices on all your copies, not just the "live" ones.

Side-note: What are your thoughts on two separate cloud providers as providing sufficient insurance? Say, having your data live in Google Cloud and at rest in Amazon S3?

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @01:01PM (#10772358)
That was Jason's use case that he had in mind, but for plenty of people the situation is the exact opposite but the principle remains.

Having two cloud providers would work assuming they don't share any critical infra-structure and assuming that it is not the same set of employees that have access to both systems. Also helps if you have a totally separate set of credentials for the back-up system and if that back-up system can only be unlocked by very senior people (preferably execs) after a catastrophe of suitable magnitude hits.

Whether you store your primary in the cloud or your back-up in the cloud the story is the same: have a copy somewhere else.

Finally: the only real back-up is one that is off-line. So from that (ok, ultra-paranoid) viewpoint it would be best if you actually went to an off-line medium to store your data in such a way that nobody can wipe it all out without physically destroying all copies.

All this of course after suitably weighing the importance of the data.

Re:Fuck the Cloud (2009) by zeveb on Monday December 21, 2015 @12:44PM (#10772262)
If your data is truly valuable to you, then yes, you host it (encrypted, I hope) in a cloud service to protect you from onsite issues; you host it live locally, to work with it — and you have a hard drive in a safe deposit box somewhere, as well, in case something goes wrong with the cloud copy.
Re:Fuck the Cloud (2009) by alextgordon on Monday December 21, 2015 @01:02PM (#10772361)
Read this and then consider if you ever want to write something like it. https://www.facebook.com/orainwikihosting/
Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @01:11PM (#10772408)
That's very painful to read. Codespaces went pretty much the same way, here is what they wrote:

"Code Spaces will not be able to operate beyond this point, the cost of resolving this issue to date and the expected cost of refunding customers who have been left without the service they paid for will put Code Spaces in an irreversible position both financially and in terms of ongoing credibility. As such at this point in time we have no alternative but to cease trading and concentrate on supporting our affected customers in exporting any remaining data they have left with us."

They promised a follow up once they got to the bottom of what happened but they never did, I'm still curious what the whole story was.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @01:17PM (#10772440)
Once again. I only entertain statistical arguments. This anecdotal nonsense is for the birds. Any given service can fail at any time. This is known kaleesi. You can poop out case after case of some shit wiki platform losing your bird watching posts and it won't make a lick of difference. You need to show me that its better with the magic of statistics. Should be easy peasy show me that you have lost less data(proportionally) than amazon over your entire career.

I can make this even easier. Its almost certainly going to boil down to this question. Have you ever lost even a single byte of data? Cause if you have, you aren't even in the same ballpark.

Re:Fuck the Cloud (2009) by DougWebb on Monday December 21, 2015 @01:41PM (#10772598)
"Have you ever..." is the wrong question when it comes to risk management; the right questions are "Is is possible...", "How likely...", "How can you avoid..." and "What's the cost to avoid...".

Have you ever been killed in a car accident? No? Then I guess you don't need a seatbelt, right? Has your house been burnt down by a lightning strike? No? Then no lightning rods and proper grounding for you, right?

You don't wait until a disaster occurs before you put a disaster recovery plan in place.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @01:58PM (#10772717)
This is a misrepresentation. The "Have you ever" was to demonstrate a point. There are armies of IT housemen that believe they are better than securing data than the major storage providers. This attitude is pretty pervasive and patently nonsense. My point was to get them thinking. If you in your entire career have lost even a single byte of data. You are statistically missing the mark(in terms of data loss) by orders of magnitude. S3 is stupidly resilient. So much so that no amount of raid configs, backups, and redundancy on the part of the joker in the corner cubicle will ever even be even close.

So getting back to risk management. So we about to make a QB selection for the big game. Now that we understand that the implementation of folks like jaque here are like the 12 year old pee wee standout vs. the cloud provider's seasoned NFL quarterback. Which one do you pick to safe guard your business.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @11:56AM (#10771997)
> Until your control panel gets hacked and you lose all your data

This is just alarmism. If you really wanted to demonstrate your point you would show me some data. The data would demonstrate that over the millions and millions of users on a number of cloud platforms that their rates of data loss are significantly higher than your "home spun" storage. Then you would take out the outliers and show an honest distribution on the most stable vendors(since I'd expect the majority of data loss over all vendors to have some amount of locality within a specific vendor). The result of this will be the rate of data loss on the most reliable cloud platforms. You can then compare this against your own success rates.

If you have ever(even once) lost even a single byte of data(for any reason), I do believe you will find yourself hopelessly outmatched.

Re:Fuck the Cloud (2009) by dspillett on Monday December 21, 2015 @12:14PM (#10772120)
> demonstrate that ... on a number of cloud platforms ... that their rates of data loss are significantly higher than your "home spun" storage

You seem to be missing the point.

People are not saying "don't use cloud storage at all"

They are saying "don't use cloud storage exclusively"

You might trust that your cloud providers will never be hacked, that your individual account on them will never be hacked, that they will never suffer a catastrophic failure, that they will never go out of business, that they will never be fully or intermittently down at the moment you need to retrieve some data, and so on and so forth, based on their claims and documentation, or that you won't cock up at some point and cause data loss in your account, but I prefer to have my own copy (or copies) as well as the ones that are "in the cloud". For truly essential data at least one of those copies is both offline and offsite.

Re:Fuck the Cloud (2009) by lmm on Monday December 21, 2015 @05:25PM (#10773998)
Unless you've personally memorized all the data in your head, you're trusting someone or something. Even if you've printed it all out on acid-free paper and stored it in a bank vault, you're trusting the bank, you're trusting your paper supplier, you're trusting the courier who transports it back and forth. If you've stored it on "your" servers you're still trusting your hard drive manufacturer, your RAID firmware, your OS code, your hosting company, your sysadmins.

For most values of "I have x hours and y dollars to safely store z gigabytes", a pure-cloud solution (possibly involving multiple independent cloud providers) has a lower chance of failure than one involving local storage.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @12:20PM (#10772149)
>For truly essential data at least one of those copies is both offline and offsite.

But the fact remains that where ever you choose to put it "offline and offsite" the odds of it being lost are orders of magnitude greater then its persistent and redundant storage on a reputable cloud provider. Even if you put it on the most stable storage you can find and lock it in a underground safe. You can't guarantee its integrity a handful of years from now let alone centuries.

To put it in other words you are advocating storing your money in a mattress because you don't "trust the banks"

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @12:46PM (#10772267)
You're entirely free to play fast and loose with your customers data.

It is interesting that even today there are still people arguing against having back-ups because 'the cloud', you'd think that we ITers learn from our mistakes but for some this has to be personal experience before the lessons are learned. Good luck if and when it happens to you, please re-read your comments here at that time. There isn't an IT person that I know that has not been saved by a back-up at some point in their career, the fact that you are lucky so far is not a reason to think you are exempt.

And no, nobody is advocating storing your money in a mattress because you 'don't trust the banks', the point is that you can keep a copy of your critical data for very little money to safeguard against an eventuality that seems to hit the IT world with alarming regularity, even if they use 'the cloud'. Fuck-ups, hacks, disgruntled employees and failures all happen, every day.

Re:Fuck the Cloud (2009) by dmoo on Monday December 21, 2015 @12:35PM (#10772212)
Maybe ask the people of Greece if they "trust the banks". Shit happens, a local copy of your stuff does no harm at all in the same way as some cash on the hip is cool in case your card stops working.
Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @01:11PM (#10772412)
Do you keep your money in a shoe box under your bed or stuffed in your mattress? I'd hope no, but then that begs the question "where do you keep it?" I'd assume not in a bank because any bank can fail at any moment and they are only insured by an instutition as flaky at the United States Treasury department. Governments collapse all the time just ask the Soviet Union. Right?

The failure probabilities are relative. And everyone here is equivocating. As if the likelihood of failure is evenly dispersed. You indicate that storing customer data in the cloud is "playing fast and loose" but I'd argue the opposite. Not having a cloud backup is what is "fast and loose"

Imagine you are an independent bank. You need to move your customers deposits. Do you load sacks of cash into your corporate minivan or hire an armored car service? Well lets look closer. With the latter you are giving up control, right? You have no control over the quality measures an armored car service might take. Yet somehow not contracting them seems like foolishness. The reason is obvious. Its because you know in this case that transporting money isn't your expertise. Its not something you can focus adequate time and resources on perfecting. You also can't spread the risk of failure across a lot of customers, absorb that failure, and make your service better for the next go. The exact same logic applies to long term storage of data. If that isn't your only function its extremely hard to get it right.

Re:Fuck the Cloud (2009) by LordKano on Monday December 21, 2015 @01:37PM (#10772578)
I'd assume not in a bank because any bank can fail at any moment and they are only insured by an instutition as flaky at the United States Treasury department. Governments collapse all the time just ask the Soviet Union. Right?

If you bank fails, you will be made whole with money from the FDIC. Money is fungible. Any money will do.

Data is not similarly fungible. There's no IT FDIC to replace your lost data with other data that's identical.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @02:03PM (#10772751)
Oh you can't trust the FDIC they are government insured. And governments collapse all the time. I gave an example. Like a I said there is only one safe place for your money. Thats in your own private bank that you build and maintain yourself.
Re:Fuck the Cloud (2009) by LordKano on Monday December 21, 2015 @02:05PM (#10772756)
When is the last time the FDIC failed versus the last time an online storage vendor folded?
Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @02:47PM (#10772993)
Its true that FDIC has lost fewer deposits than S3 has lost objects, but as usual there is a caveat. There are 2,000,000,000,000 objects in S3. In order to make a comparison the FDIC would have to insure over 300 deposits for every man, woman, and child on the planet and maintain a failure rate of '0.000000001%' or The FDIC would have to operate in its current state continuously for many millennia without interruption. I don't get a sense that the contrarians here appreciate the numbers involved.
Re:Fuck the Cloud (2009) by LordKano on Monday December 21, 2015 @02:54PM (#10773039)
You're evading.

When was the last time the FDIC failed versus the last time an online storage vendor folded?

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @03:30PM (#10773289)
Anybody who remembers nirvanix is going to have the willies just reading this thread, those who were caught by it will see red.

Personally I think the risk that AWS fails is remote, but if I were to store a bunch of data with them I'd most definitely make sure that I would not be dependent on them. It would be a convenience at best, but never a dependency.

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @01:16PM (#10772436)
I keep my money spread out across multiple accounts with multiple banks up to the insured limit. Because yes, banks can fail.

> You indicate that storing customer data in the cloud is "playing fast and loose" but I'd argue the opposite. Not having a cloud backup is what is "fast and loose"

Basic reading comprehension failure, that is not what GP is arguing.

He's arguing that if your live data lives in the cloud your backup copy should not be in the cloud and vice versa.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @01:37PM (#10772573)
>I keep my money spread out across multiple accounts with multiple banks up to the insured limit.

Insured by who? Not governments. Governments collapse all the time. The only safe place to keep it is in your own custom bank at home that you built yourself.

Re:Fuck the Cloud (2009) by omarchowdhury on Wednesday December 23, 2015 @03:55AM (#10782536)
And that money is worthless if the issuing government collapses. There is no ultimate security.
Re:Fuck the Cloud (2009) by dspillett on Tuesday December 22, 2015 @05:36AM (#10776905)
> To put it in other words you are advocating storing your money in a mattress because you don't "trust the banks"

Money and data are not directly compatible here, as one "bit" of money is the same as any other in most respects, but I do always carry a minimum amount of cash in case my cards stop working or are lost/stolen, have a pot of "emergency cash" at home for similar reasons, and recommend others do the same. Most of my money is in the bank so I'm not protecting against massive institutional failure here, but I am protecting myself against a variety of possible temporary inconveniences and possible mistakes on my part.

I'd rather have two backups of which one is more likely to fail then the other than just one, or three rather than two, and mixing types of backups means not all of them are subject to exactly the same failure modes (my local backups, online or off, are unaffected by connectivity issues for instance). For data that is important, a little paranoia is healthy IMO.

Re:Fuck the Cloud (2009) by tzudot on Monday December 21, 2015 @12:41PM (#10772237)
> To put it in other words you are advocating storing your money in a mattress because you don't "trust the banks"

In this case, money can't be compared to digital data. You can make multiple copies of digital data on our own but not of your money tucked away into a mattress, that would be illegal.

Re:Fuck the Cloud (2009) by nsfyn55 on Monday December 21, 2015 @01:13PM (#10772418)
It doesn't share the exact same properties, but you can make the comparison with any given copy. So yes the analogy holds.
Re:Fuck the Cloud (2009) by matwood on Monday December 21, 2015 @01:48PM (#10772644)
It is not alarmism at all. All it takes is a single pissed off employee or a single fat fingered command and an entire business can be wiped out. Coming from the database world it the saying was there are people who are crazy about backups and there are people who have not needed their backups...yet. For some reason everyone ends up having to learn the hard way.

I also not advocating against the cloud, just that a single copy in S3 is not a backup solution.

Re:Fuck the Cloud (2009) by fixermark on Monday December 21, 2015 @03:38PM (#10773345)
In all fairness, you need more than just off-cloud backups to guard against a single pissed off employee (make sure you're locking S3 and your local backups with different credentials, and the credentials to read the backups can't be gleaned from the credentials that write them) or a single fat-fingered command (kingdomofloathing.com once blew away N days of user progress by accidentally running a backup script in the "restore" direction against prod data).
Re:Fuck the Cloud (2009) by matwood on Monday December 21, 2015 @03:49PM (#10773404)
Of course! Offline backups are only one of the many things that need to be done. S3 versioning can help with fat finger errors, credential management helps with rogue employees, bucket policies can copy files to off to private buckets/glacier, etc...

There is no single perfect solution, so like security you layer your disaster recovery.

Re:Fuck the Cloud (2009) by jacquesm on Monday December 21, 2015 @03:52PM (#10773421)
> make sure you're locking S3 and your local backups with different credentials, and the credentials to read the backups can't be gleaned from the credentials that write them

This is more or less an exact copy of how I would advise companies to set this up.