6 ms·

Down-voted because I think that it is just dumb to have a Dropbox account and forgo local backup of the files on the service. Dropbox is not an extension of yo

Down-voted because I think that it is just dumb to have a Dropbox account and forgo local backup of the files on the service. Dropbox is not an extension of your mission-critical local storage and backup. My approach for Dropbox on both Windows and OSX is to have the Dropbox folder on a drive that will never see development work, even if that means creating a separate partition for it. In most cases the system drive works fine (you do have separate system and data drives on your machines, right?). This forces a COPY operation rather than a file MOVE if you drag-and-drop files into any Dropbox folder. Which means that everything in the Dropbox folder could be trashed tomorrow and nothing whatsoever would be lost. On Windows you can also do this by dragging files while holding down the RMB and on OSX while holding down the Option key. This, however, is fraught with issues because it is easy to forget and move something in or out of Dropbox accidentally. In addition to that, daily system and data backups to external media on EVERY SYSTEM in the office ensures that even if you took a sledge-hammer to any given machine all the data could be recovered to within a 24 hour boundary. So, no, this is NOT a "Dropbox horror story" as far as I am concerned. At best this is an unfortunate "pilot error" and at worst this is a sign of incompetence. Sorry, a little harsh there, but, as a student, I lost six months of heavy coding work once in college. That really hurt. And that was probably the best time and place to learn that lesson. That is all it took for me to be completely insane about having backups of backups on anything important. Now, may years later, you will not find any critical system in my office that is not backed-up at least once and usually twice. These days there's almost no excuse for loosing your work. Don't go around blaming Dropbox, not their problem. I am not associated with Dropbox in any way other than being just another user. FEATURE REQUEST: It would be very nice if Dropbox client software could have an option to auto-magically COPY files in and out of Dropbox rather than allowing any files to be moved. The above-mentioned hack works fine but it'd be nice to not have to use it. Also, I'd venture to guess that most Dropbox users don't do this, which opens them to unintended loss.

jiayo 14y ago
> At best this is an unfortunate "pilot error" and at worst this is a sign of incompetence. I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. > you do have separate system and data drives on your machines, right? I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. Most people use the operating system that came installed on their PC as-is. > daily system and data backups to external media Dropbox makes the following claims on their website: "Your files are safe" "Even if you accidentally spill a latte on your laptop, have no fear! You can relax knowing that Dropbox always has you covered, and none of your stuff will ever be lost." "Even if your computer has a meltdown, your stuff is always safe in Dropbox and can be restored in a snap. Dropbox is like a time machine that lets you undo mistakes and even undelete files you accidentally trash. " I think it's completely reasonable to expect Dropbox to be a reliable backup solution as-is.
- robomartin 14y ago
  OK, let's take a look at your points: > I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. Not a "obscure Windows-specific drag and drop quirk". This is how the OS works. If you are a developer you need to know your OS. > I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. It isn't, but if you are smart you'll take my advice and go implement it right now. > Most people use the operating system that came installed on their PC as-is. Developers are not "most people" and should certainly not behave as such. Your data is the only thing that is important. Your work product. Investing in separate drivers (not partitions, separate physical drives) on every development machine is invaluable. And, backing-them up with disk images on a daily basis is just as important. If the system drive goes out your data is intact. If the data drive goes out the system is intact. Recovery is an academic exercise. If both drives go out it is a little more of a pain in the ass, but at most you'll loose a day's worth of work, not a lifetime or a whole year's worth. > Dropbox makes the following claims on their website: Pardon the raw-ness: I don't give a shit of what anyone says or claims about any service. Neither should you or any serious developer. You, and only you are responsible for the safety of your data. You HAVE TO assume failures, not just locally, but also remotely. Hardware fails. Software fucks-up. Even if Dropbox (or name your service) guaranteed 500% redundancy I'd still have my own backups. It would be irresponsible to do otherwise. Then there's the practicality of the whole thing. The machine I am using to type this has the following physical drives (not partitions on a single drive, these are independent pieces of hardware in the chassis): Internal backup drive External backup drive (USB) System drive Data Library Development The last four are backed-up daily with incremental backups to both backup drives. The data drive alone has over 300GB of data right now. The Library and Development drives are about 150GB of data each. That's 600GB of valuable work in three drives probably representing millions of dollars of work-product and value. So, Dropbox is backup, right? Well, uploading 600GB to your "backup" would take somewhere in the order of 100 days of continuous 24/7 upload with my current DSL connection (~600Kbps upload speed). That's a third of a year. Nope, it's not backup.
  - icambron 14y ago
ubershmekel 14y ago
Do you not trust dropbox as a backup of your data at all or do you require 2 backups of everything?
- robomartin 14y ago
  This has NOTHING to do with Dropbox or not trusting it. As a developer, if you've been around computers for more than a microsecond the NECESSITY and VALUE of backups don't need to be explained. Dropbox is not backup, no matter what anyone says.
gabemart 14y ago
>At best this is an unfortunate "pilot error" It is in no way "pilot error". If the post you replied to is correct, the dropbox software performed an action it should never perform - deleting files the user did not tell the OS to delete. What's more, every dropbox plan I'm aware of keeps deleted files for 30 days, so if it wasn't possible to recover some of the files, dropbox failed not once but twice. It's all very well blaming the user for not having multiple redundant backups, but that doesn't change the fact that deleting user data without explicitly being told to do so is one of the most egregious sins software can commit. It's not "pilot error" when the software performs an action that should never occur.
- robomartin 14y ago
  The "pilot error" is in not testing the solution before trusting it and in making an assumption that the data would be safe in an untested external system. Let me put it into a financial context. I did a project that added up to some $800K in cost. Two developers over about a year. Do you think that for even a microsecond I would trust Dropbox as a backup mechanism without extensive qualification and testing? And, would I have that as my sole approach to backup? Nope. And this isn't me coming down on Dropbox or suggesting that they are unreliable. I use Dropbox and I am very happy with the service. However, based on experience gotten the hard way, I do not use it for anything that is mission critical. The important stuff is backed-up locally, sometimes with redundant backups. I don't have any sympathy for an engineer who uses a service and relies on it without the proper testing and qualification phase. Behaving that way is most-definitely, as I said, to be kind, "pilot error". It is completely unfair to blame Dropbox for anything. This is like the idea of cutting-and-pasting code from the Internet and trusting it with a mission-critical aspect of your application without dissecting the code, testing it and fully qualifying it for what it is you need it to do. There are tons of examples of this behavior, perhaps the most common one in the web development community is email validity verification. How many careless developers copy a regex like this to validate their email and don't think twice about it: ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$ These things are all over the web. And most of them suck. Even some of the most impressive ones will lead you astray. How many engineers (and, as a result, websites) fail to test and research and end-up with questionable solutions? Would you blame the regex writer for this or the engineer who chose to use it without doing any testing at all? It doesn't matter what the regex author claims or how authoritative the website featuring the regex might be, you have to test it before deploying it! If you don't test, deploy and then loose customers because it is a bad regex it is YOUR fault, not the author's. Blaming them is nonsensical. In case you are curious, here's "the" solution: http://isemail.info/about http://isemail.info/about Not only is it well documented, the author offers test vectors and all of the relevant code and references so that you can take the time to qualify the solution. So, yes, to be redundant, if an engineer does not do his job I am perfectly happy calling it "pilot error" and even going as far as calling it "incompetence".
moconnor 14y ago
Lots of people use Dropbox just like this, without local backups. For many people I know, that's part of the point - versioning helps, too. It's certainly neither 'dumb' and nor is mentioning a friend who did this down-vote worthy.
- robomartin 14y ago
  Using anything this way (meaning, without testing and without knowing of what you might be exposing yourself to) is absolutely dumb. The down-vote wasn't for posting about his friend's experience. The down-vote was about his friend and also for blaming Dropbox for something that was 100% his friend's responsibility. Let's bring it down to a "skin in the game experience". - Save-up $250K - Invest all of it in a startup - Hire a couple of programmers to help you out - None of you setup any local backups - You choose to rely on web service X for backups - You don't test anything 'cause everyone is doing it this way - You still don't have local backups - A year later something goes wrong and you loose all of your work - You just lost all of your time, money and the startup tanks - You go online and blame service X for your loss Clearly service X had nothing to do with the series of decisions and actions that led to your loss. Your loss was due to "pilot error" and plain-old home-grown incompetence. Nothing more, nothing less. Blaming someone else might feel good, but the reality is that a less-than-professional treatment of the matter is what caused the loss. Service X was just along for the ride. I quit blaming others a long, long time ago. In my experience you can do forensics in almost all of these situations and identify someone who was either dumb, lazy or incompetent who ended-up giving you the gift of irrecoverable data loss. Like I said in my original post, I was EXTREMELY lucky to have learned this lesson while in college. I lost six months of work of a project for the Physics department to a drive failure. Horribly painful. Ugly. I am so thankful for having learned that lesson in that context. It would have sucked to have learned it outside of academia and while working on projects where data loss could have resulted in significant financial loss. My sentiment stands: With local storage being so plentiful and inexpensive these days there is no excuse for not having multiple redundant backups of anything that is important. You can even have a policy of shipping physical redundant backups to another storage location to mitigate the possibility of your local backups being compromised by something like a building-wide fire. In another post I treat the other fundamental issue of backups over connectivity such as DSL.
deleted 14y ago
[deleted]
rlu 14y ago
Critical files or not, data loss is a 100% unacceptable bug. I really doubt you will be able to convince anyone that data loss is okay. It's not. With that said, I think Dropbox is a pretty amazing service and I credit them for getting Google and Microsoft to wake up and make some similar services which are solid and different in some respects (Google Drive and SkyDrive).
- robomartin 14y ago
  Not saying anywhere that data loss is OK. Absolutely saying that data loss is a part of life, no matter what anyone says or chooses to promise. So, you can travel two paths: One where you believe that service X can absolutely-positively not loose your data for whatever reason. Or, another, where you understand that your data can be lost at any time and for any reason by both remote service X or even your local $100 USB drive. If you choose the first path, you are going to get stung sooner or later. And, it is my contention that blaming the service provider for your total data loss is nothing more than not wanting to admit the truth of the matter. If you choose the second path, which could sound really paranoid but is actually very realistic, you take steps towards creating enough redundancy that a single point of failure isn't going to burn days, months or years of data. And, while no absolutes exist in this world, it doesn't take much in this day and age to have a system that will almost guarantee that your data is safe from most loss-inducing events. I consider problems like data loss to be serious engineering problems. The difference is that I choose to look in the mirror first and blame myself first before pointing the finger at someone else.
kalleboo 14y ago
> This forces a COPY operation rather than a file MOVE if you drag-and-drop files into any Dropbox folder. Which means that everything in the Dropbox folder could be trashed tomorrow and nothing whatsoever would be lost. This removes the main point of Dropbox, that when you edit your files they're automatically continually re-uploaded. If you're only making copies into Dropbox, you might as well just mount an SFTP server and save a bunch of money.

jiayo 14y ago

> At best this is an unfortunate "pilot error" and at worst this is a sign of incompetence. I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. > you do have separate system and data drives on your machines, right? I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. Most people use the operating system that came installed on their PC as-is. > daily system and data backups to external media Dropbox makes the following claims on their website: "Your files are safe" "Even if you accidentally spill a latte on your laptop, have no fear! You can relax knowing that Dropbox always has you covered, and none of your stuff will ever be lost." "Even if your computer has a meltdown, your stuff is always safe in Dropbox and can be restored in a snap. Dropbox is like a time machine that lets you undo mistakes and even undelete files you accidentally trash. " I think it's completely reasonable to expect Dropbox to be a reliable backup solution as-is.

robomartin 14y ago
OK, let's take a look at your points: > I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. Not a "obscure Windows-specific drag and drop quirk". This is how the OS works. If you are a developer you need to know your OS. > I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. It isn't, but if you are smart you'll take my advice and go implement it right now. > Most people use the operating system that came installed on their PC as-is. Developers are not "most people" and should certainly not behave as such. Your data is the only thing that is important. Your work product. Investing in separate drivers (not partitions, separate physical drives) on every development machine is invaluable. And, backing-them up with disk images on a daily basis is just as important. If the system drive goes out your data is intact. If the data drive goes out the system is intact. Recovery is an academic exercise. If both drives go out it is a little more of a pain in the ass, but at most you'll loose a day's worth of work, not a lifetime or a whole year's worth. > Dropbox makes the following claims on their website: Pardon the raw-ness: I don't give a shit of what anyone says or claims about any service. Neither should you or any serious developer. You, and only you are responsible for the safety of your data. You HAVE TO assume failures, not just locally, but also remotely. Hardware fails. Software fucks-up. Even if Dropbox (or name your service) guaranteed 500% redundancy I'd still have my own backups. It would be irresponsible to do otherwise. Then there's the practicality of the whole thing. The machine I am using to type this has the following physical drives (not partitions on a single drive, these are independent pieces of hardware in the chassis): Internal backup drive External backup drive (USB) System drive Data Library Development The last four are backed-up daily with incremental backups to both backup drives. The data drive alone has over 300GB of data right now. The Library and Development drives are about 150GB of data each. That's 600GB of valuable work in three drives probably representing millions of dollars of work-product and value. So, Dropbox is backup, right? Well, uploading 600GB to your "backup" would take somewhere in the order of 100 days of continuous 24/7 upload with my current DSL connection (~600Kbps upload speed). That's a third of a year. Nope, it's not backup.
- icambron 14y ago

ubershmekel 14y ago

Do you not trust dropbox as a backup of your data at all or do you require 2 backups of everything?

robomartin 14y ago
This has NOTHING to do with Dropbox or not trusting it. As a developer, if you've been around computers for more than a microsecond the NECESSITY and VALUE of backups don't need to be explained. Dropbox is not backup, no matter what anyone says.

gabemart 14y ago

>At best this is an unfortunate "pilot error" It is in no way "pilot error". If the post you replied to is correct, the dropbox software performed an action it should never perform - deleting files the user did not tell the OS to delete. What's more, every dropbox plan I'm aware of keeps deleted files for 30 days, so if it wasn't possible to recover some of the files, dropbox failed not once but twice. It's all very well blaming the user for not having multiple redundant backups, but that doesn't change the fact that deleting user data without explicitly being told to do so is one of the most egregious sins software can commit. It's not "pilot error" when the software performs an action that should never occur.

robomartin 14y ago
The "pilot error" is in not testing the solution before trusting it and in making an assumption that the data would be safe in an untested external system. Let me put it into a financial context. I did a project that added up to some $800K in cost. Two developers over about a year. Do you think that for even a microsecond I would trust Dropbox as a backup mechanism without extensive qualification and testing? And, would I have that as my sole approach to backup? Nope. And this isn't me coming down on Dropbox or suggesting that they are unreliable. I use Dropbox and I am very happy with the service. However, based on experience gotten the hard way, I do not use it for anything that is mission critical. The important stuff is backed-up locally, sometimes with redundant backups. I don't have any sympathy for an engineer who uses a service and relies on it without the proper testing and qualification phase. Behaving that way is most-definitely, as I said, to be kind, "pilot error". It is completely unfair to blame Dropbox for anything. This is like the idea of cutting-and-pasting code from the Internet and trusting it with a mission-critical aspect of your application without dissecting the code, testing it and fully qualifying it for what it is you need it to do. There are tons of examples of this behavior, perhaps the most common one in the web development community is email validity verification. How many careless developers copy a regex like this to validate their email and don't think twice about it: ^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$ These things are all over the web. And most of them suck. Even some of the most impressive ones will lead you astray. How many engineers (and, as a result, websites) fail to test and research and end-up with questionable solutions? Would you blame the regex writer for this or the engineer who chose to use it without doing any testing at all? It doesn't matter what the regex author claims or how authoritative the website featuring the regex might be, you have to test it before deploying it! If you don't test, deploy and then loose customers because it is a bad regex it is YOUR fault, not the author's. Blaming them is nonsensical. In case you are curious, here's "the" solution: http://isemail.info/about http://isemail.info/about Not only is it well documented, the author offers test vectors and all of the relevant code and references so that you can take the time to qualify the solution. So, yes, to be redundant, if an engineer does not do his job I am perfectly happy calling it "pilot error" and even going as far as calling it "incompetence".

moconnor 14y ago

Lots of people use Dropbox just like this, without local backups. For many people I know, that's part of the point - versioning helps, too. It's certainly neither 'dumb' and nor is mentioning a friend who did this down-vote worthy.

robomartin 14y ago
Using anything this way (meaning, without testing and without knowing of what you might be exposing yourself to) is absolutely dumb. The down-vote wasn't for posting about his friend's experience. The down-vote was about his friend and also for blaming Dropbox for something that was 100% his friend's responsibility. Let's bring it down to a "skin in the game experience". - Save-up $250K - Invest all of it in a startup - Hire a couple of programmers to help you out - None of you setup any local backups - You choose to rely on web service X for backups - You don't test anything 'cause everyone is doing it this way - You still don't have local backups - A year later something goes wrong and you loose all of your work - You just lost all of your time, money and the startup tanks - You go online and blame service X for your loss Clearly service X had nothing to do with the series of decisions and actions that led to your loss. Your loss was due to "pilot error" and plain-old home-grown incompetence. Nothing more, nothing less. Blaming someone else might feel good, but the reality is that a less-than-professional treatment of the matter is what caused the loss. Service X was just along for the ride. I quit blaming others a long, long time ago. In my experience you can do forensics in almost all of these situations and identify someone who was either dumb, lazy or incompetent who ended-up giving you the gift of irrecoverable data loss. Like I said in my original post, I was EXTREMELY lucky to have learned this lesson while in college. I lost six months of work of a project for the Physics department to a drive failure. Horribly painful. Ugly. I am so thankful for having learned that lesson in that context. It would have sucked to have learned it outside of academia and while working on projects where data loss could have resulted in significant financial loss. My sentiment stands: With local storage being so plentiful and inexpensive these days there is no excuse for not having multiple redundant backups of anything that is important. You can even have a policy of shipping physical redundant backups to another storage location to mitigate the possibility of your local backups being compromised by something like a building-wide fire. In another post I treat the other fundamental issue of backups over connectivity such as DSL.

deleted 14y ago

[deleted]

rlu 14y ago

Critical files or not, data loss is a 100% unacceptable bug. I really doubt you will be able to convince anyone that data loss is okay. It's not. With that said, I think Dropbox is a pretty amazing service and I credit them for getting Google and Microsoft to wake up and make some similar services which are solid and different in some respects (Google Drive and SkyDrive).

robomartin 14y ago
Not saying anywhere that data loss is OK. Absolutely saying that data loss is a part of life, no matter what anyone says or chooses to promise. So, you can travel two paths: One where you believe that service X can absolutely-positively not loose your data for whatever reason. Or, another, where you understand that your data can be lost at any time and for any reason by both remote service X or even your local $100 USB drive. If you choose the first path, you are going to get stung sooner or later. And, it is my contention that blaming the service provider for your total data loss is nothing more than not wanting to admit the truth of the matter. If you choose the second path, which could sound really paranoid but is actually very realistic, you take steps towards creating enough redundancy that a single point of failure isn't going to burn days, months or years of data. And, while no absolutes exist in this world, it doesn't take much in this day and age to have a system that will almost guarantee that your data is safe from most loss-inducing events. I consider problems like data loss to be serious engineering problems. The difference is that I choose to look in the mirror first and blame myself first before pointing the finger at someone else.

kalleboo 14y ago

> This forces a COPY operation rather than a file MOVE if you drag-and-drop files into any Dropbox folder. Which means that everything in the Dropbox folder could be trashed tomorrow and nothing whatsoever would be lost. This removes the main point of Dropbox, that when you edit your files they're automatically continually re-uploaded. If you're only making copies into Dropbox, you might as well just mount an SFTP server and save a bunch of money.