Esa es la pregunta que muy pocas veces nos hacemos, ¿podría sobrevivir mi organización a una pérdida de datos? ¿cuanto me costaría recuperar los datos?¿en dinero?¿en tiempo?

Todas las organizaciones deberían tener un plan de contingencia contra una eventual pérdida de datos, y como soy consciente de que el uso del término organización puede resultar extraño así que, antes de nada, vamos a definir qué entendemos por organización.

Atendiendo a la RAE se define organización como:

Del fr. organisation.
1. f. Acción y efecto de organizar u organizarse.
2. f. Disposición de los órganos de la vida, o manera de estar organizado el cuerpo animal o vegetal.
3. f. Asociación de personas regulada por un conjunto de normas en función de determinados fines.
4. f. Disposición, arreglo, orden.

Vamos a utilizar la acepción número 3, en su sentido más amplio, desde organización empresarial, hasta nuestra familia.

Ahora que tenemos claro quien puede sufrir una eventual pérdida de datos, vamos a ver qué es una eventual pérdida de datos.

Y aquí el abanico es realmente amplio, puede ir desde que se nos borre una fotografía hasta que físicamente perdamos el acceso a los datos, bien por sustracción del dispositivo que los almacena, bien por deterioro total o parcial del mismo.

Hoy en día huelga decir que hemos de tener copia de seguridad de nuestros datos, y por suerte las empresas nos lo ponen muy fácil para hacer copia de seguridad de los dispositivos más susceptibles de sufrir una pérdida, nuestros dispositivos móviles, da igual que nuestro dispositivo sea de la manzanita o del robot, puesto que tanto apple como Google te permiten hacer una copia de seguridad, tanto instantánea de nuestras fotografías como de todo el dispositivo cuando lo ponemos a cargar, así que podríamos decir que en un dispositivo móvil estaríamos bastante cubiertos frente a una pérdida de datos, lo que realmente nos dolería sería el coste de reposición del terminal.

Estoy seguro que al igual que somos conscientes de la necesidad de habilitar la copia de seguridad en nuestros dispositivos móviles, sabemos que tenemos que hacer copia de seguridad de nuestros equipos de escritorio, y de nuestros servidores. También estoy seguro de que todos seguimos la estrategia 3 - 2 - 1 (o más) en nuestros procesos de backup, pero por si alguien no sabe de qué le estamos hablando lo explicitaremos, esta estrategia se basa en realizar 3 copias de tus datos en 2 soportes diferentes y aloja la tercera copia en 1 lugar físico distinto. Esta estrategia cubre los mínimos para poder realizar una recuperación de nuestros datos con ciertas garantías y algunas salvedades.

Antes de seguir, me gustaría hacer hincapié en las salvedades que hay a la hora de recuperar los datos con esta estrategia;

  • En primer lugar hay que tener en cuenta que podremos recuperar los datos a la copia más reciente que tengamos, es decir, si nuestros datos se pierden por la tarde y hemos hecho la copia de seguridad por la noche, podremos recuperar nuestros sistemas al estado en que se encontraran en ese momento, no en el momento inmediatamente anterior al desastre.
  • En segundo lugar tendremos que tener en cuenta que si no podemos acceder físicamente a la copia de seguridad que queremos restaurar, la tenemos en la nube, el proceso de restauración va a ser más largo que si la tenemos físicamente y solo hemos de conectar el dispositivo a nuestros sistemas.
  • Y en tercer lugar, no podemos olvidarnos que los errores ocurren, podemos estar haciendo todos los procesos correctamente, pero si no comprobamos con cierta periodicidad que los datos son recuperables, puede darse el caso que estemos haciendo una copia de seguridad que no sirve para nada, y cuando queramos echar mano a nuestros datos puede ser demasiado tarde.
  • También tenemos que asegurarnos de qué estamos copiando y a donde lo estamos copiando, deberíamos de llevar un registro de los procesos de copia, especificando el origen, destino de los datos y si se ha comprobado su "recuperabilidad", para que en caso de siniestro un miembro de nuestra organización, o de la empresa que se contrate para recuperar los datos tenga un mapa para ayudar en la reconstrucción de la estructura digital de nuestra organización. Y todo esto sin olvidar que siempre será mejor tener los datos en tres sitios que en dos.
  • Y sobre todo, sobre todo... usa el sentido común. Antes de salir corriendo, para, cálmate, piensa, pregunta, y luego actúa. Ten un criterio a la hora de hacer las cosas, sobre todo a la hora de evaluar los riesgos que entraña hacer una determinada acción, en la vida real™ no existe el botón de deshacer, ni hay la posibilidad de salir sin guardar...

Por suerte yo puedo decir que SI, mi organización ha sido capaz de sobrevivir a una pérdida de datos.

Y por eso, si os interesa, os voy a contar cómo lo hacemos y como hemos podido recuperar los datos en las dos crisis que hemos vivido...

Empezaremos por los equipos, todos los usuarios tienen su cuenta tanto de Google Drive, como de Microsoft Onedrive y gracias a la integración de esta última con el sistema operativo Windows todos los datos con los que se trabaja en los equipos locales se guarda automáticamente en la nube de Microsoft, adicionalmente las cuentas de correo electrónico que están dadas de alta con Google están configuradas con el protocolo imap, por lo que solo se descarga al equipo una copia de los correos con los que se trabaja, estando todos completamente accesibles desde la web de la plataforma, tanto los correos enviados como los recibidos. Así que si un equipo muere solo hemos de poner un equipo nuevo, reinstalar los programas de gestión y poner las credenciales de acceso a las nubes.

Pero cuando tienes una red y muchos documentos accesibles por varios usuarios, las cosas se empiezan a complicar, en nuestro caso todos los documentos compartidos están centralizados en un NAS, que es un tipo de servidor especial para el almacenamiento de datos. Estas carpetas están protegidas y cuentan con políticas de acceso según los privilegios del usuario, vamos que hay documentos que todos pueden ver y editar (o borrar), documentos que solo pueden leerse y algunos documentos que solo pueden ser vistos por ciertos usuarios. Al estar estos documentos en un NAS se guardan en 8 discos duros especiales para este tipo de servidores. Y además tiene programadas una serie de sincronizaciones para que esos ficheros se repliquen en otros servidores.

Y aquí fue donde tuvimos nuestra primera crisis con los datos, un usuario en un despiste "borró" accidentalmente 17Gb. de datos, y también fue aquí donde cometimos nuestro primer error, que nos costó tiempo. La solución fue bajar del servidor externo los datos que se habían borrado, al no estar físicamente accesible el servidor tuvimos que depender de nuestra conexión de datos. Fue un proceso largo, pero se recuperó hasta el último archivo que se había "borrado", pero si nos hubiésemos parado a pensar en lo sucedido, nos habríamos dado cuenta de que los datos no se habían borrado, seguían en el servidor, pero se había arrastrado la carpeta dentro de otra. Actuamos por instinto en vez de pensar en todo el rato que le cuesta al sistema borrar tantos ficheros, por muy despistado que sea el usuario se habría dado cuenta de que le aparecía una ventana que ponía borrando, a parte de que le habría pedido confirmación antes de hacerlo...

De los errores aprendimos, no solo a pararnos a pensar, sino que decidimos añadir un segundo NAS en la organización que hiciese una copia local de lo que teníamos en el principal. Ambos NAS hacen una copia en cascada hacia nuestros servidores Cloud y hacia otro NAS que se encuentra en otra localización.

A estos NAS se copian, además, los datos de nuestros dos servidores de trabajo que mediante unos procesos copian periódicamente los datos sensibles para ponerlos a buen recaudo. Ambos servidores cuentan con discos en espejo, lo que implica que los datos que tengo en un disco duro se escriben a la vez en otro, y si un disco falla podemos acceder al segundo para sacar los datos.

Y eso fue lo que nos pasó ayer alrededor de las dos de la tarde, cuando casi todos se habían ido a comer, y yo estaba a punto de hacerlo me sobresaltó un olor a plástico chamuscado, seguí el olor y me llevó al armario donde están los servidores, identifiqué el culpable y rápidamente lo apagué. Fue al sacarlo del armario a otra sala y volver a conectarlo cuando me di cuenta de lo que estaba pasando, había un cortocircuito en el cable de alimentación de uno de los discos duros y se estaba prendiendo fuego, lo que hacía que se estuviese derritiendo el conector del disco duro. Evidentemente lo desconecté de la corriente inmediatamente.

Ahí fue donde vi que tenía que calmarme y pensar. Lo primero llamar a mis informáticos, llevar el equipo y hacer un análisis de la situación. El disco duro pintaba mal, así que se sacó se apartó y se intentó reiniciar el sistema con el otro disco espejo, el suspiro de alivio al ver que empezaba a cargar el sistema del servidor nos salió del alma. Comprobamos que estaba la carpeta con el programa de gestión y aparentemente estaba todo ahí.

Lo que no esperábamos era encontrarnos con un disco que tenía únicamente los datos de la fecha en que se configuró el sistema de espejo (RAID), misteriosamente los dos grupos de espejo habían fallado y los datos actualizados solo se habían grabado en uno de los discos de cada pareja.

Empezaron los sudores fríos

Pero como sabíamos que se hacían copias según las especificaciones del sistema pudimos comprobar que los datos necesarios para seguir trabajando estaban a salvo en el resto de localizaciones, aunque estaban a cierre del día anterior, íbamos a tener que perder una mañana de trabajo, lo que era una "putada", pero era un mal menor. habíamos aprendido un par de cosas, hay que comprobar el estado de los datos, y hay ciertos datos que hemos de tener actualizados con mayor frecuencia que otros.

Con la certeza de poder volver al inicio de la jornada vino la cabezonería de no perder nada, y os adelanto que lo hemos conseguido, el disco duro estaba en mal estado, pero solo se veían mal los conectores, la circuitería del disco se veía bien, y no había motivos para pensar que los discos en si mismos pudiesen estar dañados, podíamos mandar el disco a una empresa de recuperación de datos para que los sacase. Las pegas eran el coste en tiempo y en dinero de hacer esto, así que decidimos usar el sentido común e intentar algo diferente.

Si la empresa iba a recuperar los datos el primer paso era reemplazar la circuitería dañada por otra igual, nos costó pero conseguimos encontrar un disco duro exactamente igual que el que teníamos, reemplazamos los circuitos y lo conectamos a ver que pasaba. No hacía ruido extraño así que había esperanzas, aunque al conectarlo a un ordenador, este no era capaz de acceder a la información. Al quitar el circuito y volver a comparar las placas vimos que la que no estaba dañada era un poco más moderna que la dañada.

Lo segundo que la empresa iba a tener que hacer era sustituir la parte de plástico dañada por otra igual, por suerte teníamos la controladora que no había funcionado y podíamos intentar hacer esa sustitución. Pero claro, esto eran palabras mayores y hacía falta que un especialista confirmase que se podía hacer. Por suerte tengo grandes amigos que además son grandes profesionales y siempre están dispuestos a echar una mano.

Lo más rápido que pude me desplacé a casa de mi querido Toni y con su paciencia infinita y nervios de acero dijo que sí, que lo intentaba. Un rato más tarde, que a mi se me hizo eterno, me dijo que había podido soltar las dos piezas y sustituir la dañada. Solo nos faltaba pinchar el disco y comprobar que era legible.

Por suerte así fue, y lo primero que hicimos fue sacar la carpeta de datos para poderla copiar al servidor nuevo. Era el momento de respirar aliviados, aunque la cabezonería que me caracteriza me hizo ir un poco más allá y replicar el disco dañado en un disco nuevo, tenía las herramientas, tenía los conocimientos, solo necesitaba tiempo, y hasta las nueve de la mañana tenía toda la noche por delante para intentarlo.

Tengo que decir que fue un proceso largo y aburrido, pero que al final pude arrancar el servidor con un disco completamente nuevo que tenía los datos del disco dañado. Había conseguido que lo único que perdiese mi organización fuese el coste de las piezas que se habían sustituido, y mi tiempo.

De esta experiencia he(mos) aprendido que las políticas, por muy bien definidas que estén, siempre pueden tener fallos, así que había que copiar ciertas cosas cada menos tiempo, y de esta manera se reducían drásticamente las posibilidades de pérdidas, y que no basta con hacer copias, hemos de comprobar que podemos recuperar los datos en cualquier momento.

El disco duro dañado y como quedó tras a intervención
El disco duro dañado y como quedó tras a intervención

En fin, os dejo una "batallita" que por suerte ha tenido un final feliz, pero me gustaría que hicieseis una autoevaluación del estado de vuestros datos porque nosotros, a pesar de hacer todo aparentemente bien hemos tenido fallos, fallos que no han tenido consecuencias precisamente por eso, porque hemos hecho las cosas bien, pero que en una organización que no evalúe bien sus riesgos puede suponer su desaparición.

Haced las cosas bien, contad con profesionales y usad la cabeza, tres recetas básicas para minimizar los riesgos, aquí y en la vida real™