4 ms·

So I guess the conclusion is that no mainstream cloud service is to be relied on.

• hengheng 12y ago
  Well, these big services probably close down as often as an end user sees their hard drive fail.
  • belorn 12y ago
    This is not about a company closing down. Its about a company deciding to close their services for a user, arbitrarily, at their own discretion. Files you upload can be permanent deleted, at any time, at the whim of the service provider or any of their employees. You have no rights and no appeals.
  • Dewie 12y ago
    The difference is that a user doesn't feel like just using his computer normally gives him any backup. But if his folder is inside Dropbox, he might be lulled into a sense of comfort since he thinks of Dropbox as a kind of backup[1]. So if he uses Dropbox instead of just using his plain old computer (hard drive), then he might start to get more careless than when he didn't feel that he had a safety net. [1] Though personally I would disagree.
• dfinninger 12y ago
  https://owncloud.org/ https://owncloud.org/
  • sz4kerto 12y ago
    Can't your hosting provider terminate your contract?
    • vinceguidry 12y ago
      Use multiple services and replicate between them.
      • zkhalique 12y ago
        May as well use MaidSafe or Freenet
    • jiffytick 12y ago
      I always thought Tor hidden services make a great way to host your own cloud. Not only can you host on your own hardware without messing with dns, isp reps, and router settings, but you get privacy features for free. IMO, I think local hosting is the primary usecase the Tor project should be advertizing.
      • dublinben 12y ago
        Hidden services are not a primary concern of the Tor Project, or a primary use of the Tor network. They are a novel way of using a system designed for anonymous and censorship-resistant communications.
    • robotresearcher 12y ago
      Does no one have their own physical box any more?
      • vinceguidry 12y ago
        Doesn't solve the problem. The essential nature of the problem is that your data can disappear under circumstances that you can't control, be it because the server died, problems with the host, they're going away entirely, they decide they don't like you anymore. To fix all permutations of this problem, you have to replicate, host the data in multiple physical places. It introduces another problem, managing the replication and testing to make sure it's working, but if the data you're trying to protect is important enough, you devote the resources. Looked at in this light, hosting your own physical box is less useful than using two separate online services. You still have the management and testing overhead either way, but with your own physical box you also have to maintain and manage that resource too. That only makes sense if you have existing infrastructure you can plug into, and sometimes it doesn't even make sense then.
        • monkmartinez 12y ago
          Or vice versa... all the solutions you mentioned are liabilities if given enough thought. The cost of hosting in multiple places coupled with the very real possibility of other circumstances not in your control are enough to make the argument to host your own stuff a viable solution. The cognitive overhead of learning the api, writing tools to automate processes, testing and so on are not free in either time or money. I don't think a clear cut winner emerges in all cases. Cloud vs. DIY is situationally dependent and requires a great deal of deliberation. I think the pendulum will swing between cloud and DIY for a long time... With proponents of each making awesome cases to use either one.
          • vinceguidry 12y ago
            When it comes to risk, honestly, most people and companies are their own worst enemies, much much more inclined to hose themselves than, say, Linode or Amazon would. The cost of using multiple solutions should be negligible compared to the cost of losing the information. If it isn't, then store it wherever, and if you lose it, so what. A competent developer should not have to spend a lot of time learning an api, automating the process or testing the automation. If you don't have a competent developer, you should just use COTS. If you have a developer that complains about the time these tasks take, you don't have a developer, you have a technical handyman. In which case you can't engineer anything and should just use COTS, because that's all he'll realistically be able to handle anyway. If the developer is you and you can't afford to waste your time engineering your infrastructure, then yours is not a technology company and again should just use COTS. Your operating profits should support the cost of your engineering, including the salary of a competent developer, this will typically dwarf your hosting costs. If they don't then you don't have a real business and need to spend more time figuring out how you're going to make money and less time on the technology. If you're storing and using big data, and currently using a cloud provider, then your roadmap should include a plan for eventual self-hosting, as that's one of the few areas where self-hosting still makes sense, as costs can diverge very quickly. It's not big data unless building your own Backblaze storage pod is a viable option. For all other applications, self-hosting can quickly become a boondoggle, unless you have competent systems administration, the cost of which will again dwarf your hosting costs. If you do not have competent systems administration, and you are owning and managing systems, then your business is a disaster waiting to happen. If the hard drives fill up on your home-built server, you will have downtime until you can figure it out and fix it. You will not have your hosting company's skilled customer support team, which handles the common cases that trip people up all the time, at your disposal. Any time you touch the machine do do anything other than deployments, you run the risk of breaking something important. If your development is not competent either, then you run the risk of having your hygienic development process dirtied by, say, someone working directly on the production server. The problems caused by this are insidious and can take up time and attention that is better used pushing your business forward.
• TillE 12y ago
  Realistically, you can't rely on anything. You should always have independent redundancy for stuff that's really important.
• notatoad 12y ago
  The conclusion should be that unless you're paying for an SLA, you aren't going to get an SLA.