La triste historia de JournalSpace

El caso de JournalSpace ha tenido notoridad a lo largo de este fin de semana e incluso ha aparecido en Slashdot. En resumen la empresa perdió todos los datos de sus usuarios debido a que el encargado del TIC sobreescribió toda la base de datos, con lo que la información se perdió para siempre. Al menos es la explicación que dio el CEO de la compañía en el blog de la misma:

"This sounds like an ancient Chinese curse: ‘may you be featured on Slashdot and have 80 Twitter followers.’

Some more background for the folks who caught the news on Slashdot or another blog: yes, I was a huge idiot, first and foremost.

It was the guy handling the IT (and, yes, the same guy who I caught stealing from the company, and who did a slash-and-burn on some servers on his way out) who made the choice to rely on RAID as the only backup mechanism for the SQL server. He had set up automated backups for the HTTP server which contains the PHP code, but, inscrutibly, had no backup system in place for the SQL data. The ironic thing here is that one of his hobbies was telling everybody how smart he was.

This doesn’t excuse what happened, though: I should have taken a better look at what he’d left behind, and fixed all of the things that needed fixing."

Es decir toda las medidas de back-up de dicha empresa eran un RAID 1. Al parecer esta compañía ha corrido con bastante suerte todos estos años, pues de acuerdo a Slashdot, estan en el negocio desde el 2002. Yo he visto morir RAID 1 y 5 tantas veces a lo largo de mi experiencia profesional que me sorprende que no hayan tenido aunque sea un backup semanal. Incluso ahora es tan barato y fácil que se puede hacer un cluster de multiples master con MySQL.

Como una vez le exponía a mi jefe el por qué no es suficiente solo el RAID 5. Mi ejemplo fue el siguiente: "Imagine que tiene un avion con 4 motores, y justo en medio del recorrido uno falla. Lo primero que hace el piloto es ubicar el aereopuerto más cercano para practicar un aterrizaje de emergencia, para poder reparar el desperfecto y continuar con la travesía. Esa es la forma de proceder con un RAID 5". Al parecer muchas personas leen sólo los comentarios sobre las tecnologías, pero jamas las han visto aplicadas a la vida real.

El caso de JournalSpace ha causado tanto revuelo en la blogosfera que hasta ha sido comentado en TechCrunch, justamente al final del post el autor del mismo se pregunta cuando fue la última vez que el lector hizo un back-up de sus datos.

Lo más sorprendente del caso de JournalSpace es que sencillamente dejará de operar; es más estan rematando en eBay el servicio de hosting del cual aún les quedan 6 meses y sus nombres de dominio "journalspace.com" y "journalspace.net". Los sufridos usuarios que tenían sus blogs alli, sencillamente se quedaran sin sus datos y como único consuelo la explicación breve del CEO en el blog de la compañía, culpando al encargado del departamento TIC, que era un chico malo que arruinó a la empresa. Meditelo un momento que tal si en lugar de ser los datos hubiera sido el dinero de una persona, acaso el dueño de un banco puede alegar, que debido a que el contador se llevó la plata los ahorristas se quedaron sin dinero. Creo que debería legislarce sobre esto y exigir un mínimo de seguridad en los datos que confiamos a empresas que solo vemos a través de nuestro navegador.

Un comentario en «La triste historia de JournalSpace»

  1. El CEO tiene un morro que se lo pisa. Echarle la culpa a un técnico es por decir algo apropiado, irresponsable y cobarde. Lamentablemente, el «echar la culpa al informático» es algo demasiado común en las empresas ultimamente.
    Lo que tendría que haber asumido, es la culpa de todo el embrollo y comerse el marrón con patatas. Que para eso le pagaban un sueldazo de CEO.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.