> And Dropbox isn't specifically marketed towards developers.

Dropbox for teams is specifically marketed towards businesses.

That's wonderful, except that this thread is about a developer being added and then removed from teams while working at a startup and this triggering data loss. This isn't about grandma storing her pictures of the kids. Grandma ain't gonna join "teams". That's for developers.

Did you read the article this thread is about?

You could, of course, take the approach that Dropbox should be there to protect everyone from themselves.

Fair enough.

I have, in other comments, given the example of my own usage, which guarantees that no data can ever be lost by Dropbox. It's simple and it works. I've been constructive here. If you implement my approach you should be safe. Still, don't take my word for it, implement and verify. That's engineering.

I have also, in another comment, posted about a feature request that might help insure that this does not happen to casual users:

Dropbox, if possible, should modify their client software such that files can only be copied in and out of Dropbox folders and never moved. For the adventurous, they could make this an option that is set by default but can be disabled. A huge warning about the potential for data loss would accompany the act of disabling this feature.

In that regard, I've been as constructive as one could be in this thread.

In the end, you can't protect everyone from their own mistakes, incompetence or carelessness. And, no, I don't think everyone is stupid. We all make mistakes. I had a very painful data loss event in college, so I learned my lesson very early on. I have never lost valuable data since.

I am not going to blame a service for something that is the responsibility of the user. Engineers, in particular, have no excuse for data loss. A 2TB external hard drive is about $100. Please.

You could also argue that business users in this day and age cannot be computer illiterate. Being "literate" does not mean being able to open a browser and push a mouse around. If a business owner is not capable beyond that they ought to be smart enough to hire a qualified IT service to help them manage and secure their systems. If they do have in-house IT then data backup and security ought to be one of their top functions.

Private users are a little bit of a different story. There's a huge chunk of them that, today, could loose every digital asset they own and have no way to ever recover it. This is still a business opportunity for a startup somewhere. Services like Carbonite and others abound:

https://www.google.com/search?q=online+backup

At one point you have to point your finger at the data's owner and say "You, and only you, are responsible for your data".

I can guarantee you that if you read the TOS of any online data backup service there's a clause there about the potential for accidental loss. There is no way in hell that an attorney would advise anyone not to have that clause there. And, no matter how good of an engineer you might be, there is no way you would risk it all to offer some kind of an absolute no-loss guarantee.

The test is simple: Would you, personally, be willing to be sued into absolute poverty for issuing that guarantee? Probably not.

So, we can sit here in righteous indignation for me daring to suggest that users are ultimately responsible for their data and lie to each other or accept the reality that the reality, developer or not.

Down-vote away, but I am right.

If we go back to the very original article that this thread is about, the programmer who joined the startup team seems to have not had any explicitly-created local backup of the data in question. He got lucky. He said "The client left all the files on my machines, so I didn’t lose any personal data - it wasn’t a catastrophic failure.". That's luck, that is not planning. So, he did OK, he talks about having to re-upload some 2GB of data to a new account. He was off and running after that. I can bet you that, unless he isn't very smart, he now has private local backup of his data in case something like this happens again. And that's the right way to handle it.

Don't trust anyone with your data unless you can independently verify the ruggedness and reliability of their solution. Period. If you did not do that, engineer or "civilian", total data loss is on you, not the service.

> Apparently you've never heard of incremental backup?

Oh, please.

> Dropbox may not be a backup but there are many services that backup via the internet. Assuming you don't change backup systems every month, 100 days for the initial sync is perfectly acceptable.

Oh, please. Again.

If you don't have local backup, for a third of a year you have no backup whatsoever. Even after that, depending on the nature of your work, even incremental backups could have you unprepared for failure for days.

Not saying at all that remote backup is a bad idea. Not at all.

Remote backup BY ITSELF, without local high-speed backup that you control is a very bad idea.

The best pattern is to have single or redundant backup under your control (yup, use that "incremental" thing I didn't know about) and remote backup. Don't expect anyone backup destination to be 100% reliable, not even local backup. If your data is important you need multiple redundant backup, local and remote. Then you can sleep at night.

I added a "Development" drive as an experiment a few years ago. I'm still on the fence about it.

I own more than one business and we also do work for other businesses, so, generally speaking, the "Data" drive holds business data partitioned-off into appropriately-named directories.

I also have what I call "support" directories there. For example, I have a "SolidWorks Support" directory with models, macros, tools and other items that are there to support work with that software. The same is true of Photoshop, Altium Designer, Web Design and other segmentable tasks.

Then there's more mundane stuff, like "Digital Photography", "Personal", "Scans", "Temp", "Outlook Data", etc.

Projects started to kind of pollute the data drive in some form. Also, the directory hierarchy started to become a little crazy. For example:

    D:\<company name>\Projects\<project name>\Design\Mechanical\<project work folder>\Suppliers
    D:\<company name>\Clients\<client name\...

Even there were hardware, embedded and web projects with their own requirements. And, even though we use Git, I still have the habit of making full copies of directories every so often to freeze thing in time. With projects such as Solidworks mechanical designs or some electronics designs using source control can be painful, so, full backup copies of work directories works very well. Storage is cheap.

At one point I thought that I should segregate active development from finished or shipping product. In other words, make a distinction between "project" and "product". That's why I introduced the "Develpment" drive.

There's another reason. When doing FEA thermal and/or flow simulation for various projects the Data drive started to become clogged-up with simulation data. As you navigate through many iterations of design ideas and simulations you can easily fill-up gigabytes. I didn't think that this belonged anywhere near the "Data" drive.

Finally, some tools (Xilinx ISE back then) did not take kindly to paths with spaces. So I always had to have a separate folder for Xilinx projects which has always bothered me.

This "Development" drive now allows me to create a simple folder with a short path:

    Z:\ProjectA

This "feels" simpler and it "feels" like the right way to do it.

I also have an "xampp-sites" folder on there for web projects. The projects can live in their own directories in the "Development" drive:

    Z:\TheNextFacebook
    Z:\TheNextGoogle

These have full source control, work folders and generally contain all the work resources for a project (for example a Photoshop work directory). The "xampp-sites" directory is setup as the testing server and only sees an upload of the files that would normally go to the real production server (easy to do with tools such as Dreamweaver --which is never used in design mode here!).

Once a "project" graduates to being a "product" it is zipped-up and copied or moved into a "Products" folder under the appropriate company directory in the "Data" drive. As an example, if we are talking about an iOS project it turns into a product once it is submitted to the app store and approved.

The jury is still out on whether or not this is a good idea or simply a reflection of being insanely anal about organizing data. I don't know. I am always open to new and interesting ideas on this front. I try to think of the "Development" drive as a dirty or work drive of sorts where I can mess with a lot of things without polluting the "Data" drive. I have this implemented in one machine and have not been compelled to do so in other machines yet. Still thinking about it.