CONSIDERACIONES PARA ELABORAR UNA ADECUADA ESTRATEGIA DE RESPALDOS DE SISTEMAS Y DATA PARA SU ORGANIZACIÓN

Respaldos

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.

0 Comentarios

Contesta

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

*

©2020 Info Technology Consultants | Sitio Web diseñado por:  Pluss Marketing

Inicia Sesión con tu Usuario y Contraseña

¿Olvidó sus datos?