4 ms·
> 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
by nsfyn55 11y ago
> 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.
- dspillett 11y ago> 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.
- nsfyn55 11y ago>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"
- dmoo 11y agoMaybe 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.
- nsfyn55 11y agoDo 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.
- jacquesm 11y agoI 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.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- lmm 11y agoUnless 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.
- matwood 11y agoIt 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.
- fixermark 11y agoIn 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).
- matwood 11y agoOf 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.
- jacquesm 11y ago> 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.