CouchSurfing Deletes Itself, Shuts Down - Old, yet relevant
techcrunch.com
techcrunch.com
It is interesting that if MySQL had built-in measures to prevent this kind of disaster, MySQL would have never got any money from them.
That is the problem I see with commercial FOSS: if your product installs easily, runs perfectly, and is easy to use, there is no way to make money.
The only reason they retained the 'Gold Support Service' is because their own database administrators obviously had no idea what they were doing or how to use the software correctly.
There are always companies that will make use of commercial support for FOSS but MySQL will probably never make any money from me.
At some point you have to be able to trust people, and unless you are already an expert in that area how do you really know?
Having followed this particular crash-recovery saga unfold and being involved with web 2.0 otherwise, it would be interesting to hear a few thoughts over this: what's the responsibility of the platform provider towards their possibly very engaged community - or is there any?
If the community wants to remain a community then normally someone else will step up, that's the power of community, it's bigger than just a web site. In the case of couch surfing v2 seems to be going strong.
Knowing a bit about it (having been a volunteer for the org) I think the crash was extremely badly handled. For better or worse, many people were relying on the service to find places to stay, connect with people in foreign cities, and so on. Leaving those people high and dry is bad karma. Likewise, users should be encouraged to make "backups" in the form of phone nos, email addresses, etc if the reliability of the site can't be guaranteed.
I think the problem is a classic one in technology. The geeks at the helm are over confident. Their self belief clouds their judgement with regards to backups, failure planning, and so on.
Certainly, if this happened to me and I came to that decision, I'd put up a forum for everyone so that they could engage and figure out post-startup plans. But that's me.
As far as I'm aware, during the CouchSurfing crash, some volunteers set up a separate forum, but it wasn't sanctioned or initiated by the founder, I believe he simply walked out. :(
I can't find any prepackaged thing on the web. I'd like to address 2 needs : disaster recovery and point in time recovery.
For now I only dump the database from time to time, but it's far from a real solution, if I loose my whole server it would take quite some time to get its configuration back on track.
/usr/bin/mysqldump -u dbusername -pdbpassword --skip-lock-tables database_name | gzip > /path/to/backup/file/file_$(/bin/date +\%Y-\%m-\%d_\%H-\%M-\%S).sql.gz
I'm using --skip-lock-tables because on a ZenCart site, the lock tables option was adversely affecting site performance.
Then you could add something to automatically email or scp the file to another host.
For bigger, more complex databases, look into MySQL binary logging, DRBD replication, and MySQL slaves. That should give you some keywords to get started.
For total completeness and peace-of-mind, you could have the script add anything else you need backed up, like your projects or public_html directories, configuration files, etc.
Likewise, when backing up 100s of GiBs of data, a simple tar gz is not suitable. More sophisticated strategies need to be used when the data becomes that big.
I've found http://HighScalability.com to be a great source of information on building scalable applications.