Le Crash

A technical explanation of the crash by Casey Fenton

Qu'est-ce qui s'est passé
Le 27 juin autour de 22 H 00, nous étions en train de travailler sur les bases de données qui constituent le coeur du serveur CS. La base de données principale a disparue et MySQL à généré un messages d'erreur qui semblaient être lié au fichier système. Juste avant,nous avions lancer une commande d'effacement d'une table sur une petite base de test, et il semble que la base de test et la vraie base de données ont disparue à ce moment. J'ai immédiatementaccédé à distance au serveur et démonté la partition en question, arrété le serveur MySQL et commencé à chercher. Ce qui c'était passé n'était pas vraiment clair, donc nous avons envoyé un message d'urgence aux administrateurs système professionnels que nous avions engagés pour gérer les serveurs CouchSurfing. Ils se sont connecté au serveur de base de données et ont essayé de trouver quel était le problème. Ils sont entrés en contact avec le centre de données où les serveurs sont situés. Quand les gens du centre de données sont allés vérifier les serveurs, ils ont découvert qu'un des quatre disques RAID-10 était endommagé. Quelques semaines avant, nous avions été prévenus qu'un autre disque avait déclenché une alarme et était endommagé, et qu'il avait été retirer, mais ils avaient oublié de le remplacer. Le RAID ne fonctionnait plus qu'avec trois disques sur quatre. Les techniciens du centre de données ont arrété le serveur et l'ont redémarré avec un Helix Data Recovery CD Helix Data Recovery CD et ont été capable de sauvegarder les partitions du RAID les moins endommagées vers un dique externe de 260 GB. Ils ont retiré le disque en cause, réparer le RAID, et ont redémarré le serveur. Ils ont essayé de récupérer les informations de l'image, mais ils n'ont pas eu de chance.

A partir de là, la récupération des données dura 36 longues heures. Pendant que les techniciens du centre de données tentaient de relire les disques, nous avons réfléchi à d'autres solution pour restaurer les données. Au début, nous avons pensé qu'il était possible de tout restaurer à partir d'une copie vielle d'environ 24 heures, mais nous avons découvert que le serveur de sauvegarde ne contenait que des sauvegardes vielles d'environ une semaine. Comme nous n'avions que ça, nous avons décidé de nous en servir et de commencer le processus de restauration. Ce n'est que quand nous avons demandés à nos administrateurs système de commencer la copie à partir du serveur de sauvegarde que nous avons découvert qu'au moins 15 tables sur 100 n'étaient pas dans le périmètre de la sauvegarde. Après des investigations supplémentaires, il apparut que les administrateurs systèmes que nous employons avaient modifié les méthodes de sauvegarde quelques semaines auparavant. Comme le serveur de base de données souffrait de ralentissements pendant de nombreuses heures par jours et que de nombreux membres se plaignaient, nous avions demandé aux administrateurs système de faire ce qu'ils pouvaient pour limiter la charge sur le serveur de sauvegarde. Ils nous ont répondue qu'ils avaient modifier la méthode de sauvegarde afin que la charge serveur soit minimale. Nous étions sur la route, en direction de Montréal à ce moment et nous n'avons pas prit le temps de faire une double vérification de la validité de leur travail qu'ils nous avaient assuré avoir fait correctement. Suite au crash, nous avons découvert que la nouvelle méthode de sauvegarde était connue sous le nom rsync (file synchronization). Ils copiaient les fichiers bruts de la base de données, ce qui est une méthode de sauvegarde d'une base de données bien moins efficace. De plus, ils avait commis de graves erreurs dans la configuration du rsync.

La base MySQL de CouchSurfing comprenait deux types de tables. Le premier type est appelé MyISAM et sert à stocker de grandes quantités d'informations qui n'ont pas besoin d'être accéder à de grande vitesses. Les tables MyISAM sont plus petites. La plupart des 100 tables étaient de ce type et ont été sauvegardées par le rsync. L'autre type de table s'appelle InnoDB. Ce type de table prend deux fois plus d'espace de stockage que le MyISAM, mais présente l'avantage que les données peuvent être utilisées par plusieurs serveurs en même temps. Les deux types de table étaient stockées dans des emplacements différents. Les administrateurs système sauvegardaient en rsync les tables MsISAM mais pas les tables InnoDB ! Les 15 tables InnoDB stockaient les informations les plus couramment accédées par le site web CouchSurfing, dont les profils, les liens d'amitié, les références, etc.

La perte de ces tables, sans sauvegarde récente signifiait la fin du site CouchSurfing.com tel que nous le connaission. Il n'y avait pas de sauvegarde uniforme récente. La sauvegarde la plus récente que nous avions datait juste quelque jours avant le crash, mais c'était une copie des fichiers du serveur de backup. C'étaient des fichiers de sauvegarde incomplets qui étaient vieux d'une semaine. En faisant l'inventaire des autres fichiers de sauvegarde que nous avions, nous avons découvert un mélange avec la plupart des plus importants fichiers vieux de quelques mois ou plus.

Trente six heures après le crash, le centre de données nous informa qu'ils avaient essayé de restaurer les données mais qu'ils n'avaient rien pu faire. Les données n'étaient pas récupérables. Sans données restaurables ni sauvegardes récentes de la majorité de la base de données CS, le site web semblait irréparable. C'est à ce moment que j'ai décidé d'annoncer que CouchSurfing.com était fini. J'ai écrit letter l'explication de ce qui était arrivé à la communauté et l'ai postée sur le site web, environ 48 après le crash.

What happened next was unbelievable. Within the following 24 hours we received more than 2000 emails of support from members expressing that they could simply not accept the demise of CouchSurfing, they wanted to help bring it back, and would have no problem re-entering their profile information. Many users expressed that they didn't mind if the databases were zeroed out and the community completely started from scratch. I was reminded that the CS community is not about the data, or about the furniture, it is about the network and the friendships that have already been created. The data was dead, but the community was alive.

Le vendredi 30 Juin, je décida de me sortir de la tourmante du collectif et de prendre un peu de temps pour réfléchir suite aux événements récents. Après une bonne nuit de sommeil et un des fameux café d'aldo, je me senti revivre and commenca à lire les quelques 2000 messages qui m'était parvenu via couchsurfing. Il etait évident que CS ne pouvait pas mourir. Cette communauté ferait tout ce qu'il faut pour aller de l'avant. Au même moment quasiment, je recevai un appel en provenance du centre de données qui m'expliqua qu'il tentait à nouveau de recouvrir les données perdues. Apparemment il avait lu la lettre que j'avais envoyé et voulait absoluement pas voir couchsurfing mourir de telle sorte. Ils m'ont assuré qu'ils travailleraient data forensics experts dans le but de recouvrir le maximum de données. Au moment ou je vous écris, les derniers rapports indiquent toujours qu'ils tentent de récupérer les données. nous devrions savoir dans une semaine au plus si cela est possible

Ce soir là, avec le support de toute la communauté, j'ésquissa une solution. Nous décidâmes qu'il était utile de continuer à faire progresser couchsurfing.Com si la communauté était prête à participer de manière encore plus importante et ainsi prendre une grosse partie du travail. Il était évident que je ne pouvais pas tout assumer tout seul. Le plan était simple, rassembler un maximum de données et relancer le site le plus vite possible. Le reste est décrit dans cette partie du site.

Alors, qu'est-ce qu'on perdu exactement?
Only database data was lost. No website code was damaged. The framework of the site, the functions and features, are intact. We had about 90,000 profiles in the database before the crash. All those usernames and passwords were recovered from the chat server. The chat server keeps usernames and passwords mirrored from the core database server, which are synchronized at all times. Working for many days, I was able to stitch together data from earlier back-ups of various sources and recreate an older version of the database. Approximately 11,000 profiles were lost, most of which were empty profiles. Just before the relaunch, I discovered more than 25,000 user profiles in three of the front-end the web server cache directories. This was great news! These 25,000 were all of the profiles (the most active profiles on the site) that were accessed on the website in the final 12 hours leading up to the crash. I was able to reverse engineer the cache and insert some of the lost profiles back into the user profile table, thus re-creating many of the most active (and recently added) CouchSurfing.com user profiles. These profiles should be very up-to-date, up to just moments before the crash happened. There might be some discrepancies, but for the most part, they are the most intact.

We were able to recreate empty "place holders" for those people who profiles didn't survive the crash. When you log in you will receive a message explaining that your profile was lost, but your username and password was recovered and your place held in the database.

Unfortunately some other data was not so lucky. We lost up to several months of references, email, group post, and friend links. We've done our best to recreate the data. It was also discovered that the European server had about 36 Gigabytes of image cache data. We were able to transfer these cached images back to the North American database server and re-populate the image table, losing only a minimal amount of user photos.

We will be recovering more data as time goes on. We've got the support of some of the best minds forensics data recovery and MySQL administration, including James Day of Wikipedia. As we recover more data, we will either merge it back into the website, or we will hold on to it if it is needed at some time in the future. We will make every effort to recover every possible piece of data that existed prior to the crash.

Comment nous assurons-nous de ne plus jamais perdre de données à nouveau?
First of all, we have learned so much from this disaster. We will never again assume that the administrators have it under control; we will always check the work. We have retained the professional 'Gold Support Service' of MySQL. We have created both an on-site and off-site, rock solid back-up plan that is cascading and redundant. We will always strive to make the most secure CouchSurfing possible.

MERCI!
I want to thank everyone who helped along the way, and continue to toil day and night to restore CouchSurfing. Thanks and big hugs to the community members who immediately started relief efforts for the refugee CSers on the road. These other projects, although sometimes controversial, sought to keep the CouchSurfing network alive and help people recover their profiles. I am eternally grateful for your hours of work, determination, and never-ending spirit. I'm sorry I couldn't be more responsive you in the chaotic days following the storm. I'd especially like to extend my deepest gratitude to Mike Giddens and Marcus Eder of the CouchSurfing-Phoenix Project. These two demonstrated heroic commitment and dedication, and you deserve a huge pat on the back from not only me, but also the community you have done so much service for.