En la mayoría de las organizaciones, el personal a cargo de TI establece a qué sistemas o data se le hará respaldo, con qué frecuencia se ejecutará, en qué medio quedará almacenado dicho respaldo, por cuanto tiempo y dónde será depositado ese medio. Pero saben los niveles gerenciales superiores de la empresa, qué criterios o políticas rigen estas decisiones?
Para definir una adecuada estrategia de respaldos tanto de la data como de los sistemas informáticos de su organización es necesario considerar los siguientes aspectos:
Valor de la Data
Se debe conocer, para cada tipo de data que almacenamos (bases de datos, documentos, imágenes, videos, correos electrónicos) cuán valiosa es y con cuánta frecuencia cambia. Este conocimiento es el que permitirá definir correctamente el RPO (Recovery point objective) que requerimos.
El RPO determina la cantidad máxima de información que la organización está dispuesta a perder cuando se produce una falla en los sistemas o un desastre mayor. Esto define entonces con qué frecuencia se deben hacer los respaldos.
La mayoría de las organizaciones suelen manejar un RPO de 24 horas, lo que significa que la empresa está dispuesta a perder hasta un día hábil de data nueva, sea maestra o transaccional, o de modificaciones a la data ya existente. Esto se traduce en que los respaldos se obtienen una vez al día y en horas no hábiles. Sin embargo, creemos no equivocarnos si estimamos que el 80% de estas mismas empresas no ha realizado análisis alguno, para determinar este criterio y que sus directivos inclusive hasta lo desconocen.
El RPO debe determinarse por sistema o tipo de data. También deben tomarse en consideración las implicaciones respecto a la recuperación de la data que se está dispuesto a perder.
Para sistemas que reciben muchas transacciones o actualizaciones en períodos cortos de tiempo, el RPO debe ser más agresivo. Por ejemplo, un sistema de Punto de Ventas VS un sistema de Planilla de Pago Laboral.
Si el sistema es actualizado por múltiples usuarios externos, sobre los que la organización no tiene control, más agresivo aún debe ser el RPO. Por ejemplo, un sistema de Banca en Línea.
Costo de estar Fuera de Línea
Este costo depende del tipo de negocio y del grado de dependencia que el negocio tenga de los sistemas, para seguir operando. Lo importante es que para cada negocio, se debe poder cuantificar cuánto le cuesta que sus sistemas estén fuera de servicio. En algunos casos será fácil calcularlo, pero en otros es un poco más complejo.
En el caso de un sistema de manufactura que sufre un fallo que lo deja fuera de servicio, este valor se puede obtener calculando el costo de los trabajadores que están parados más el valor de los productos que no están siendo fabricados.
Si se trata de un sistema de reservación de vuelos que deja de funcionar, esto impide la venta de asientos, y por ende la aerolínea puede perder tanto, clientes habituales como nuevos clientes y además reputación, y cada uno de estos elementos tiene un determinado valor para la empresa.
El costo del tiempo de estar fuera de línea, a su vez es el que debiera definir el RTO (Recovery Time Objective) que es el tiempo máximo que se permite la organización, de que un equipo, sistema, red o aplicación esté no disponible después de producirse un fallo o desastre.
Los RTO se definen también por sistema.
Una vez la organización establece el RTO, para el área de sistemas se debe definir un RTO menor, porque es necesario no solamente considerar el tiempo que tomará restaurar la operación del sistema en cuestión, sino en verificar que el sistema está listo para empezar a trabajar nuevamente. Hay que tomar en cuenta lo que se conoce como el WRT o Working Recovery Time, que corresponde al tiempo que se necesita para verificar el sistema luego de haberlo recuperado, comprobar la integridad de los datos y de las bases de datos y asegurarse de que el sistema está ejecutando bien. Luego de esta verificación es que realmente se reanuda el estado productivo.
La suma de RTO y WRT se define como el tiempo de inactividad máximo tolerable que establece la cantidad total del tiempo que un sistema puede ser interrumpido sin causar consecuencias inaceptables para la organización.
Prioridad de los Sistemas ante una Recuperación
En la eventualidad de una pérdida total, se debe tener la capacidad de determinar las prioridades para ejecutar la recuperación.
Considérense los siguientes aspectos:
- El orden en que deben ser levantados cada uno de los sistemas.
- ¿Qué sistemas deberían tener redundancia y failover?
- ¿Cuáles sistemas pueden esperar unos pocos días para ser levantados y cuáles no?
- ¿Qué sistemas deben ser más bien detenidos para otorgarle su capacidad de operación a otro que ha fallado?
- ¿Dónde están almacenados los respaldos?
- La mejor práctica para la ubicación de los respaldos es la regla 3-2-1: 3 copias, 2 tipos de medios de almacenamiento y una copia almacenada en un sitio remoto.
- De manera ideal, se debe tener una copia en línea (disco), una copia fuera de línea, pero local (cinta) y una copia en una ubicación remota, que actualmente puede ser en “La Nube”.
- Debe asegurarse que estas copias estén sanas y salvas.
¿Cuánto tiempo se deben conservar los Respaldos?
El espacio disponible para el almacenamiento de respaldos es limitado, por lo que en algún punto se va a requerir eliminar respaldos de acuerdo con los tiempos de retención que estén establecidos en las políticas de la organización.
Una de las funcionalidades que ofrecen los sistemas automatizados de respaldo y recuperación es precisamente la especificación de las políticas de retención. De esta manera, el propio sistema se hace cargo de ir eliminando las copias más antiguas.
¿Qué herramientas de recuperación utilizar y cuándo?
Para recuperar un sistema completamente se necesita una combinación de hardware y respaldos del sistema operativo (SO), parches y actualizaciones, data de configuración, programas de la aplicación y la data de la aplicación.
Si se están ejecutando respaldos de imágenes completas de disco, todo este software y data, al que nos hemos referido, está en la imagen por tanto, no necesitamos recuperar en varios pasos y esto agiliza la recuperación ya que únicamente tocaría restaurar el respaldo. Hay sistemas automatizados de respaldo y recuperación que inclusive permiten recuperar imágenes de disco en hardware diferente al original.
Si el respaldo es por archivos, la recuperación debe ser hecha con una secuencia de pasos, pues primero hay que instalar todo el software base para poder recuperar la aplicación y la data. Toca entonces disponer del instalable de cada software original para restaurarlo uno a uno hasta lograr el ambiente que se tenía antes de la falla, para luego restaurar la aplicación y la data.
Documentación, divulgación y ensayos del plan de respaldo y recuperación
Desde el CEO hacia abajo en la organización, todos los colaboradores necesitan conocer cómo se debe ejecutar la recuperación de los sistemas y cada miembro del equipo de recuperación debe haber practicado el procedimiento.
¿Qué data está excluida de los respaldos?
Hay que conocer de antemano exactamente qué data no está contenida en los respaldos, para determinar cómo se recuperará, en caso de requerirse, en lugar de darse cuenta de ello, cuando el evento ocurre. Por ejemplo, si en un servidor tenemos las copias digitales de reportes que fueron generados utilizando un sistema, podríamos no incluir este servidor en las rutinas de respaldo, porque son reproducibles nuevamente, sin mucho esfuerzo.
¿Cómo y cuán profundo probar los respaldos?
Como mínimo, la prueba debería consistir en recuperar los respaldos, ejecutar rutinas de verificación de disco y comparar los tamaños de los archivos.
Actualmente hay sistemas automatizados para respaldo y recuperación que incluyen dentro de sus funcionalidades, el poder ejecutar validaciones de las copias obtenidas. La validación es un proceso mediante el cual se verifica la posibilidad de recuperación de datos en una copia de seguridad.
