Resolver Problemas Consiga ayuda para problemas específicos con sus proyectos, procesos y tecnologías.

Planificación de recuperación de desastres: controles básicos sobre las pruebas de DR

Un plan de recuperación ante desastres no sirve de nada a menos que su empresa lleve a cabo los pasos correctos para someterlo a prueba.

Uno de los requisitos previos fundamentales para una planificación de recuperación ante desastres (DR) satisfactoria es el de comprender los requisitos reales. Qué necesita la empresa? y, es capaz de afrontar esta necesidad con respecto tanto a las capacidades como a los costos? Los indicadores clave de rendimiento son el Objetivo de Tiempo de Recuperación (RTO) y el Objetivo de Punto de Recuperación (RPO). En pocas palabras, el RTO es el tiempo máximo aceptable para retomar las operaciones – no solamente para la recuperación de datos – y el RPO es una medida de péDRida de datos aceptable.

La no comprensión y acueDRo sobre estos indicadores en relación con las aplicaciones críticas, y la subsiguiente incapacidad para invertir en y desarrollar capacidades para soportarlas, es la base de la laguna en la recuperación ante desastres existente entre el negocio y TI. Para salvar esta laguna es necesario que los responsables de TI se reúna con los empresarios y los propietarios de las aplicaciones para comprender las necesidades de recuperación de modo que el impacto financiero de los costos puedan ser cuantificados y sopesados frente al costo de proporcionar el nivel de servicio necesario. Esto puede que exija algunas negociaciones, pero la veDRad innegable es que sin estas conversaciones, el éxito de la DR es imposible.

Desarrollar esta capacidad va mucho más allá de un ejercicio de tecnología. Consiste en planificación, identificación de dependencias, desarrollo de procesos y, sobre todo, realización de pruebas.

Si fallas en la planificación, planificas para fallar

Un plan de recuperación ante desastres representa la hoja de ruta detallada de una organización sobre dónde ir, qué hacer y cuándo hacerlo en caso de un desastre. Debería incluir acciones que deben llevarse a cabo antes, durante y después de que se declare un desastre. Entre los elementos más básicos están la definición de los criterios bajo los que se declara un desastre, quién puede declararlo y cómo se informa a los individuos. En el pasado, las experiencias con huracanes reafirmaron el desafío y la importancia de las comunicaciones, y un buen plan debería incluir contingencias; no puedes presuponer que tu correo electrónico funcionará, o incluso que el servicio de teléfonos móviles estará disponible.

Sabemos que se deben documentar los procesos y procedimientos, pero también sabemos que la mayoría de la gente odia hacerlo. Incluso los planes de recuperación ante desastres desarrollados con mayor cuidado no servirán de nada sin la atención adecuada. La recuperación ante desastres debe desarrollarse dentro del proceso estándar de gestión de cambios de modo que siempre que los sistemas se modifiquen, el software se parchee o se asigne almacenamiento adicional, entonces se revise en consecuencia el impacto sobre el plan de DR. De la misma manera, cuando se producen reorganizaciones, se debe volver a mirar el plan de recuperación ante desastres.

Está claro que las tasas de crecimiento de datos de doble dígito afecta de manera espectacular a la capacidad para recuperar datos dentro de limitaciones de tiempo determinadas, pero la inteDRependencia y complejidad de las aplicaciones es un factor que a menudo se pasa por alto y que tiene un impacto muy importante sobre la recuperabilidad. Hoy en día, las aplicaciones más importantes están repartidas entre múltiples servidores y arquitecturas. No es raro que una aplicación que depende de una unidad central alimente a otras aplicaciones o subcomponentes que residen en plataformas Unix o Windows. Basándose en la perspectiva de recuperación tradicional centrada en el servidor, será posible hacerlo con éxito desde una copia de seguridad o snapshots de cada componente de la aplicación pero no podrá recuperar por completo la aplicación debido a inconsistencias entre los diversos componentes.

Esta situación se puede evitar primero comprendiendo las inteDRependencias entre las aplicaciones y después aplicando el enfoque de protección de datos adecuado. El método podría ser el del uso de tecnología de replicación/copia en espejo dividido que presente grupos de consistencia que abarquen los elementos inteDRependientes, o podría tratarse de la tecnología de protección de datos continua (CDP) que pueda garantizar una detallada restauración a un punto anterior de sincronización.

Sin probarlo no hay DR

La parte de planificación de la recuperación ante desastres es relativamente sencilla en comparación con el sometimiento a las pruebas del plan. A menudo se tiene pavor a probar el plan de DR y, lamentablemente, muchas veces se evita. Sin embargo, sin someterlo a prueba de la forma adecuada, lo mismo daría no molestarse con la planificación porque la probabilidad de una ejecución satisfactoria es pequeña si no has probado tu plan correctamente.

Entre las consideraciones fundamentales a probar se incluyen:

  • Pruebe la recuperación de la aplicación, no solamente la recuperación de los datos (piense en la inteDRependencia de la aplicación)
  • Deje que los individuos no responsables lleven a cabo la recuperación para validar los procedimientos y la documentación
  • Elabore múltiples escenarios de desastres y emplee el juego de rol
  • Establezca un modo de pensar positivo sobre la prueba de recuperación ante desastres: Descubrir (y resolver) problemas es una buena cosa.
  • Indicadores para medir y registrar las mejoras

La razón más habitual dada para no hacer unas pruebas más exhaustivas es el costo. Esto será forzosamente un punto de contención porque las pruebas de DR se perciben como una excepción de lo que se considera normalmente como las operaciones diarias. La única manera de afrontar de forma eficaz esta cuestión y justificar el costo es la de vincular estrechamente el proceso de prueba a los objetivos del nivel de servicio RTO/RPO. Esto significa que el modelo de negocio de recuperación ante desastres, especialmente el impacto financiero de RTO/RPO, debe ser preciso y completo. El mensaje debería ser que las pruebas exhaustivas son un requisito esencial para garantizar que esos indicadores pueden satisfacerse realmente y son parte integral del proceso de recuperación.

Este artículo originariamente apareció en la revista Storage.

James Damoulakis es Director de Tecnología de GlassHouse Technologies, una empresa de servicios de almacenamiento independiente con oficinas en los Estados Unidos y en el Reino Unido.

Profundice más

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close