Decía Benjamin Franklin que hay dos cosas seguras en esta vida: la muerte y pagar impuestos. Podríamos decir que aunque no tan deterministas, pero bastante cerca, el mundo de la tecnología sigue necesitando preservar y proteger la información con políticas de backup. Eso no cambia y sigue siendo una tarea bastante ingrata, por cierto (como todo aquello de lo que solo nos acordamos cuando hay algún desastre, pero que para evitarlo, requiere un coste y esfuerzo diario).

Lo que ha cambiado es la naturaleza y sobre todo el volumen de esa información (y los servicios de datos asociados) haciendo cada vez más complejo realizar esa tarea y una mayor incertidumbre en asegurar la capacidad de recuperación.
Esto nos lleva a buscar nuevos modelos y paradigmas de protección de datos que haga la tarea más efectiva, eficiente, predecible …. y barata.

Limitaciones estratégicas, organizativas y procesos

Por nuestra experiencia, detectamos en las empresas las siguientes limitaciones principales en la protección de la información, en todo lo relacionado con aspectos estratégicos, organizativos o de procesos:

• Falta de una visión global de la naturaleza y criticidad de la información. Las empresas suelen tener razonablemente completos y actualizados (no siempre!) mapas de sistemas pero muy infrecuentemente mapas de repositorios y flujos de datos, con su naturaleza (p.ej. fuente o derivado, conceptos que maneja) y su criticidad (en función del valor).
• Políticas de protección definidas verticalmente por sistemas, no horizontalmente por lógica del proceso. Ligado a lo anterior, es habitual encontrar que las políticas de protección de datos se hacen verticalmente por el sistema lógico (o físico) que lo alberga, y no por la naturaleza de la fuente. En muchos casos, los responsables del backup, desconocen por completo la naturaleza del repositorio al que están aplicando políticas de backup.
• Incapacidad de tratar de forma diferenciada, pero combinada, las políticas de protección de los datos y la disponibilidad de los sistemas. En muchos casos, los planes de recuperación de sistemas (lo que permite que un determinado servicio de información se preste) y los planes de protección de datos (lo que permite recuperar una determinado repositorio en caso de pérdida, borrado accidental o corrupción de datos) se gestionan de forma independiente e inconexa.
• Falta de modelos de análisis de riesgos e impacto económico asociado. La mayoría de organizaciones carece de modelos de riesgo medianamente completos relacionados con los dos aspectos anteriores. Y sobre todo no lo tienen modelizado con la métrica que todo el mundo entiende: DINERO. Esto hace que las políticas de protección de datos (y los modelos de retorno de inversión realizados) sean basados en criterios subjetivos, en algunos casos, espurios.

Limitaciones tecnológicas

En la otra cara de la moneda están las limitaciones tecnológicas derivadas de un mercado de poco glamour (el de las soluciones de backup) y de una creciente complejidad en los requisitos:

• Predecibilidad de las capacidades y métricas de recuperación. En general las herramientas de backup hacen un trabajo más o menos digno en realizar backups. Pero pregunte a un responsable de backup en la organización de operaciones de IT de una gran empresa si pone la mano en el fuego (y se juega su puesto) porque es capaz de recuperar la información de un sistema crítico con los niveles de servicio acordados en caso de un desastre, a ver qué contesta. En caso afirmativo, pregunte si realiza simulaciones regularmente.
• Heterogeneidad de los entornos y sistemas técnicos de protección. Cualquier empresa de tamaño mediano / grande acaba teniendo múltiples sistemas y soluciones de backup, complicando los procesos y aumentando el riesgo global de la solución. La adopción de los modelos Cloud solo ha añadido un factor adicional de complejidad que muchas soluciones ‘tradicionales’ no consiguen manejar de forma eficiente.
• Escalabilidad de los volúmenes de información a proteger. En el ámbito de bigdata es conocida la frase ‘los datos tienen gravedad’. O sea, pesan. Mover datos o realizar copias a efectos de protección o recuperación de los mismos no hace más que incrementar la complejidad técnica del proceso con el incremento (incesante) del volumen de información a manejar.
• Incapacidad de gestionar en función de la naturaleza específica de la información a proteger. Esto es, en muchos casos, nuestras políticas de backup, por razones técnicas, tienen que usar políticas de ‘café para todos’ cuando se mezclan en los repositorios, información con distinta naturaleza y que no deberían tener los mismos requisitos de protección (por ejemplo, información de alta volatilidad con información voluminosa, pero de baja o nula tasa de cambios).

Tendencias en la era de los datos masivos

El crecimiento imparable de los volúmenes de información a procesar y respaldar y el advenimiento de los proyectos de analítica masiva de datos, llevan a una presión adicional, que no se puede resolver de forma lineal. Necesitamos transformaciones radicales en la aproximación tecnológica. Algunas líneas de innovación que destacamos son las siguientes:

• Protección intrínseca. Lo que buscan las soluciones de protección intrínseca es sustancialmente eliminar la necesidad de realizar una copia de backup con una herramienta de backup convencional. Esto es el repositorio se auto-protege y es capaz de proporcionar una solución a los distintos escenarios de recuperación de información que podemos tener (recuperación completa por desastre físico, borrado accidental, recuperación de una versión previa en el tiempo, aseguramiento de la inalterabilidad de contenidos concretos por razones legales o funcionales, etc.). Hay muchos aspectos a tener en cuenta, pero en general la visión de un repositorio de datos como una sucesión de cambios en el tiempo, es la base que permite abordar estos modelos.
• Reducción de los activos tecnológicos a proteger. Como comentábamos en el apartado de limitaciones tecnológicas, tradicionalmente las políticas de backup se usaban para dotar de disponibilidad un determinado servicio o repositorio, no solamente para proteger los contenidos. Para entendernos, hacemos un backup de nuestro servidor, entero, con todos sus elementos, para asegurar que puedo restaurarlo entero en caso de problemas (con toda la información que alberga y sirve). Esto es profundamente ineficiente. La tendencia en ingeniería de software y sistemas con evoluciones como la virtualización en su momento y los containers más recientemente es que los servicios sean recreables por descripción de los mismos, no porque hemos guardado una copia exacta ‘por si acaso’. Es como si para proteger el servicio de movilidad en automóvil, tenemos un coche que es el que usamos y tenemos otro exactamente igual en el garaje por si el primero falla o tiene un accidente. Pero además tenemos que pasar el trabajo de hacer en ese segundo vehículo todos los pequeños golpes, arañazos, desgaste que tiene el coche original, para que sea exactamente igual. Si fuéramos capaces de describir de forma automatizada el proceso de construir un coche, es mucho más eficiente simplemente tener ese proceso actualizado y, cuando nuestro coche falla, lanzar el proceso de crear uno nuevo; naturalmente en nuestro ejemplo, ‘fabricar’ algo físico como un coche es complejo y costoso en el tiempo; pero ‘fabricar’ un servidor virtual o contenedor (especialmente esto último) no lo es. Por tanto, si diseñamos de forma adecuada nuestros servicios de SW, podemos limitarnos a respaldar únicamente los datos, no los sistemas que los ejecutan. En Tecknolab, en nuestro servicio DBcloudbin, hemos llegado al hito de que no hay ni un solo servidor físico o virtual del que se haga backup; únicamente se respaldan descriptores de servicios (las instrucciones para construir automáticamente el coche si es necesario) y los repositorios de datos, que están desacoplados físicamente de los servidores que los gestionan (por dos medios completamente independientes y heterogéneos; uno físico y otro lógico proporcionando cada uno una robustez añadida a las capacidades de recuperación).
• Combinar necesidades en un mismo proceso técnico (protección, disponibilidad y seguridad). Si tenemos que seguir realizando protección de los datos y debemos seguir asegurando que nuestros servicios están disponibles en caso de desastres y además tenemos que asegurar que los datos que manejamos no se corrompen accidental o intencionadamente (p.ej. ransomware) parece razonable aprovechar el mismo proceso para cubrir esas necesidades, simplificando y aumentando la eficiencia. Algunas soluciones modernas de backup permiten que sobre la misma copia de seguridad que hemos realizado de un sistema, podamos arrancar una nueva versión del servicio en caso de desastre en nuestro entorno primario (aprovechando por tanto ese backup para una casuística de disponibilidad de servicio); de paso, como tenemos toda una secuencia de backups en el tiempo de cada uno de nuestros repositorios, podemos identificar cambios inesperados (por ejemplo tasas de cambio en los datos fuera de un patrón razonable para ese repositorio de forma histórica) y alertar de ello como un potencial ataque de un virus. Ya hay fabricantes que proporcionan esta combinación de funcionalidades en el mercado.

Conclusiones

En resumen, no podemos sostener el modelo de ‘hacer las cosas como siempre’ con el escenario de escalado geométrico de los volúmenes de información a manejar. Esto es especialmente cierto en el ámbito de la protección de datos. Debemos cambiar los procesos, la forma de hacer las cosas y las soluciones para proteger lo que es (y cada vez más) el activo más importante de nuestras empresas: la información.

En Tecknolab, hemos aprovechado nuestra juventud y falta de herencia tecnológica para adoptar internamente procesos muy eficientes. Adicionalmente, hemos diseñado una solución de reducción de bases de datos empresariales, DBcloudbin, que nos permite segmentar de forma muy sencilla información a la que se debe aplicar políticas de respaldo de información muy distinta, simplificando el proceso con políticas intrínsecas de respaldo y reduciendo los costes de backup. Os animamos a probarlo y contactar con nosotros para cualquier duda al respecto.