Skip To Content

Prácticas recomendadas de copia de seguridad y restauración

A medida que una implementación de ArcGIS Enterprise crece en complejidad, deben adoptarse consideraciones adicionales en materia de recuperación en caso de desastre. Estas consideraciones requieren conocer los sistemas dispares que conforman la arquitectura de la implementación. Al igual que en numerosos escenarios técnicos, no existe un enfoque único para la realización de copias de seguridad de los sistemas principales y dependientes en una implementación.

A continuación, se ofrece un marco para aumentar la tasa de éxito de la restauración durante un evento de recuperación en caso de desastre. Las organizaciones pueden adoptar estas prácticas para definir sus procedimientos operativos estándar como parte de un plan de continuidad y recuperación del negocio (BC/DR) en caso de desastre en el contexto de su implementación de ArcGIS Enterprise.

Copia de seguridad

Revise las siguientes prácticas recomendadas para crear copias de seguridad de su organización de ArcGIS Enterprise y de cualquier fuente de datos referenciada.

Copia de seguridad de ArcGIS Enterprise

Una organización de ArcGIS Enterprise está compuesta por el sitio de Portal for ArcGIS, todos los sitios federados de ArcGIS Server y sus datos asociados y los datos contenidos en el ArcGIS Data Store. Las copias de seguridad de los componentes pueden realizarse con la utilidad incluida, webgisdr o con herramientas de terceros para realizar copias de seguridad basadas en máquinas o en imágenes.

La herramienta webgisdr es una utilidad de línea de comandos incluida con Portal for ArcGIS que se utiliza para realizar copias de seguridad del contenido y los datos de la organización, la información del sitio de ArcGIS Server federado y los datos contenidos en los data stores relacionales y de caché de teselas. Esta herramienta es particularmente útil para mantener la consistencia en los componentes de una implementación base, así como en cualquier sitio federado adicional, aunque requiere una implementación funcional para realizar la recuperación.

Lo siguiente debe considerarse fuera del proceso de copia de seguridad de WebGIS DR:

  • Sitios federados de ArcGIS Mission Server o ArcGIS Notebook Server: si dispone de ellos, cree copias de seguridad siguiendo las instrucciones de la documentación de ArcGIS Mission Server y la documentación de ArcGIS Notebook Server.
  • Copias de seguridad de big data stores espaciotemporales y almacenes de gráficos: si tiene un big data store espaciotemporal o un almacén de gráficos (o ambos) registrados con su servidor de alojamiento, cree copias de seguridad de cada uno con la utilidad backupdatastore de ArcGIS Data Store.
  • Configuración del sitio ArcGIS GeoEvent Server: gestionar la copia de seguridad de su configuración de ArcGIS GeoEvent Server mediante el archivo de configuración de copia de seguridad.

Los almacenes de objetos se utilizan para el almacenamiento en caché de la respuesta de la capa de entidades efímera en la versión 11.0, por lo que no es necesario conservar los datos en el caso de un ejercicio de recuperación.

La mayoría de las plataformas de virtualización permiten tomar instantáneas de las máquinas virtuales en ejecución que permiten lograr objetivos de bajo tiempo de recuperación. Aunque son útiles, no se consideran copias de seguridad duraderas como parte de un plan de BC/DR más amplio.

Cuando se realiza una copia de seguridad antes o durante una ventana de mantenimiento, el objetivo de bajo tiempo de recuperación que proporcionan las instantáneas sirve de motivación para utilizar esas herramientas cuando están disponibles. Al tomar una copia de seguridad de terceros, los componentes subyacentes del nivel de datos de Portal for ArcGIS y ArcGIS Data Store no tienen una integración con esos métodos y, por lo tanto, implican un nivel de riesgo asociado con la toma de una copia de seguridad en directo de una base de datos en ejecución. Para minimizar este riesgo, las instantáneas y las copias de seguridad basadas en imágenes deben realizarse después de detener el servicio de los componentes de ArcGIS Enterprise en ejecución.

En el caso de las arquitecturas que utilizan un archivo compartido para alojar el directorio de contenido del portal compartido o el almacén de configuración y los directorios raíz de los sitios de ArcGIS Server, es importante tener en cuenta la consistencia de las copias de seguridad de esas ubicaciones cuando se utilizan herramientas de copia de seguridad de terceros, como instantáneas de máquinas virtuales o copias de seguridad basadas en imágenes. Por ejemplo, si un administrador está revertiendo después de una actualización de Portal for ArcGIS incorrecta mediante la recuperación de una instantánea, el directorio de contenido puede haber sido alterado por el proceso de actualización y ya no sería coherente con la información contenida en la base de datos en la instancia recuperada. Para minimizar estos efectos cuando se utilizan herramientas de terceros, las copias de seguridad deben realizarse durante una ventana de interrupción en la que no se esté publicando o editando contenido en la organización. Esto incluye tanto los componentes de ArcGIS Enterprise como cualquier archivo compartido asociado.

Se puede realizar una copia de seguridad del ArcGIS Data Store por separado de los demás componentes para minimizar la pérdida de datos en caso de fallo de ese componente. La ejecución de las copias de seguridad programadas de los data stores relacionales y de caché de teselas puede producirse fuera de la programación de la utilidad webgisdr y de otras herramientas de copia de seguridad.

Copia de seguridad de fuentes de datos con referencias

ArcGIS Server puede servir contenidos de numerosas fuentes, incluidas geodatabases de la empresa, archivos compartidos registrados y almacenes en la nube. Estas fuentes de datos externas deben incluirse en el plan de recuperación en caso de desastre para una implementación. Se recomienda seguir las instrucciones del proveedor para realizar copias de seguridad o replicar datos a otra ubicación.

La copia de seguridad de las geodatabases corporativas que contienen datos servidos por servicios referenciados debe realizarse de acuerdo con los objetivos de punto de recuperación de cada organización mediante el uso de las herramientas suministradas por el proveedor. Ya que estos datos son referenciados por servicios de ArcGIS Server, la consistencia de los servicios publicados puede llegar a desincronizarse con las tablas de la base de datos de back-end si la recuperación de base de datos se realiza independientemente de los sitios que contienen los servicios publicados. Esto hace que sea importante alinear la programación de las copias de seguridad entre todos los componentes de la implementación de ArcGIS Enterprise.

Los recursos compartidos de archivos de red pueden utilizar herramientas de copia de seguridad basadas en imágenes o en sistemas de archivos para empaquetar los datos y, a continuación, transferirlos a una solución de almacenamiento duradero que exista fuera del dominio de fallos de la implantación.

Los almacenes en la nube deben tener una copia de seguridad o una réplica en otra región para una mayor capacidad de recuperación y durabilidad. Los almacenes replicados también pueden implementarse mediante el almacenamiento en archivo o en frío para reducir el coste total.

Cuándo realizar una copia de seguridad

La frecuencia con la que se realiza una copia de seguridad depende de varios factores, el más importante de los cuales es el tiempo que tarda en completarse. Ya que los procesos de copia de seguridad pueden afectar a la utilización de los recursos del sistema, las copias de seguridad completas suelen programarse fuera de las horas de mayor actividad. Para los diferentes tipos de copia de seguridad, la frecuencia con la que se realiza la copia de seguridad del sistema puede variar en una implementación de ArcGIS Enterprise.

Por ejemplo, la copia de seguridad de una geodatabase corporativa de producción puede realizarse de forma incremental cada 15 minutos para un objetivo de punto de recuperación bajo. Los datos más importantes deben almacenarse en esta instancia de la base de datos para reducir la cantidad de pérdidas potenciales de datos. Para una implementación de ArcGIS Enterprise con muchos servicios referenciados y contenido estático, la frecuencia con la que se pueden realizar las copias de seguridad podría ser diaria o semanal, mientras que para las implementaciones con un uso intensivo de los servicios de entidades alojadas y la creación frecuente de mapas web y aplicaciones se debería establecer como objetivo un tiempo más breve entre las copias de seguridad.

El tiempo de conservación de los archivos de las copias de seguridad depende de la cantidad de espacio de disco libre que tenga y del grado de flexibilidad que necesite en sus opciones de recuperación. Para obtener más información, consulte copias de seguridad de ArcGIS Enterprise.

Validar copias de seguridad

Deben supervisarse las copias de seguridad para comprobar que se completan correctamente y alertar a los administradores cuando se produzca un fallo. Para la herramienta webgisdr, el código de salida de la ejecución de la secuencia de comandos se puede utilizar como indicador de si una copia de seguridad se ha completado correctamente. Un cero representa una copia de seguridad correcta, mientras que cualquier código distinto de cero indica un fallo. Existen varias herramientas de alerta que pueden integrarse para permitir las notificaciones por correo electrónico o SMS al equipo responsable de la integridad de las copias de seguridad. Numerosas herramientas de copia de seguridad de terceros proporcionan una funcionalidad similar o pueden integrarse con otros servicios para proporcionar alertas.

Otro aspecto importante de la validación del plan de BC/DR de una organización es realizar un simulacro de restauración con una cadencia semestral. Esto ayuda a los administradores a asegurarse de que, en caso de desastre, están preparados para restaurar a partir de las copias de seguridad funcionales y validar el plan de restauración descrito a continuación.

Restaurar

Revise las siguientes prácticas recomendadas para restaurar su organización de ArcGIS Enterprise mediante las copias de seguridad que ha creado.

Qué restaurar

Cuando un administrador tiene varios tipos de copias de seguridad a su disposición, es posible restaurar componentes de una manera más granular que revertir la implementación completa. Si se borra la caché de un servicio de mapas o imágenes, solo habrá que recuperar esos archivos a partir de una copia de seguridad. Asimismo, si se elimina accidentalmente una tabla de una geodatabase corporativa, esa base de datos puede recuperarse sin afectar a otros componentes.

Si se realizan ediciones erróneas en una capa de entidades alojada y es necesario revertir los datos, un administrador tiene la opción de restaurar únicamente el data store relacionales sin restaurar toda la implementación de ArcGIS Enterprise. Esto reduce el impacto que la restauración tiene en otros datos almacenados dentro de la base de datos, pero si hubo servicios alojados creados durante ese tiempo, podría causar que el sitio de ArcGIS Server se vuelva inconsistente con las tablas de la base de datos restauradas y requerir la limpieza manual y la republicación de los servicios afectados.

En otras ocasiones, puede producirse una interrupción importante, como la de un centro de datos o una región en la nube, que requiera la restauración de la implementación de ArcGIS Enterprise completa, así como de cualquier fuente de datos externa. Este sería el ejemplo más extremo y requiere una planificación adecuada para garantizar la completa funcionalidad del entorno restaurado.

Cómo restaurar

Cuando una implementación de ArcGIS Enterprise experimenta una interrupción generalizada, existen múltiples opciones de recuperación que dependen de los tipos de copias de seguridad disponibles. La replicación a un sitio cercano mediante la utilidad webgisdr es el método más significativo para reducir el tiempo de recuperación de la implementación, mientras que tener un sitio en espera frío disponible para iniciar y restaurar puede facilitar tanto los simulacros de recuperación como reducir el tiempo general de recuperación.

A la hora de decidir la ruta de recuperación, debe intentarse primero la opción con los objetivos de punto y tiempo de recuperación más cortos. Esto permitiría la retroalimentación más rápida sobre el nivel de éxito de la restauración. Contar con un administrador que se sienta cómodo con la estrategia de copia de seguridad y que haya probado las restauraciones con regularidad en el pasado también puede acortar el tiempo de recuperación en caso de desastre.

Puesto que ArcGIS Enterprise cuenta con varios niveles en los componentes internos y externos, el orden en el que se restauran esos componentes influye en la estabilidad de la implementación tras una restauración. Todas las fuentes de datos referenciadas deben estar disponibles en primer lugar y debe verificarse que son accesibles desde el entorno de ArcGIS Enterprise, incluidas las instancias de la base de datos y los archivos compartidos externos, antes de restaurar las máquinas y los componentes de ArcGIS Enterprise.

Una vez que las dependencias circundantes están en marcha, la implementación de ArcGIS Enterprise debe restaurarse a un estado consistente. De esta manera se evitan los escenarios en los que el sitio del servidor de alojamiento puede tener un servicio de entidades alojado publicado, pero al data store relacional le falta la tabla de datos dependiente, o la organización puede tener un elemento para un servicio que ya no está presente en uno de los sitios federados.

Validación posterior a la restauración

Una vez finalizada la operación de restauración, se debe realizar una validación de los datos críticos para la empresa y de la funcionalidad generalizada de la implementación de ArcGIS Enterprise. Esto puede lograrse mediante la creación de listas de comprobación para que los centros de negocio y los departamentos verifiquen su contenido más importante, o automatizarse mediante scripts. El enfoque de esta validación mediante el uso de scripts automatizados permite una mayor confianza en que la restauración fue correcta en menos tiempo que una verificación manual de elementos y servicios.