Para los sistemas empresariales con expectativas, requisitos o compromisos de disponibilidad, es fundamental contar con un planteamiento de copias de seguridad y recuperación ante desastres (DR) claramente definido, ejecutable y bien probado. El diseño de una estrategia de copias de seguridad o de un planteamiento de recuperación ante desastres requiere que las organizaciones comprendan primero el alcance y las dependencias de sus sistemas, antes de establecer cuidadosamente los objetivos de la recuperación, conocer los recursos informáticos disponibles y considerar el proceso de recuperación, desde el desencadenamiento de una copia de seguridad o restauración hasta la viabilidad del apoyo del personal y las repercusiones para los usuarios.
La importancia o el rol de las copias de seguridad se relaciona principalmente con la criticidad empresarial de un sistema, y con los flujos de trabajo que admite y las categorías de datos que se almacenan en él. Algunos sistemas, como un servidor de desarrollo o uno utilizado por un equipo pequeño, pueden no necesitar una estrategia de copias de seguridad, mientras que otros sistemas pueden utilizar planteamientos de copias de seguridad y DR principalmente para probar los procesos e informar de la aplicación correcta de los mismos a un sistema de producción.
Este tema proporciona una vista general del proceso de copia de seguridad y recuperación ante desastres, incluidas las implicaciones para los componentes del software ArcGIS y las opciones disponibles para admitir un planteamiento de copia de seguridad o recuperación ante desastres para diversas aplicaciones ArcGIS.
El proceso de hacer una copia de seguridad de un sistema, dato o componente de hardware siempre ha sido importante para los sistemas informáticos. Aunque, históricamente, las copias de seguridad se implementaban generalmente a nivel de almacenamiento, la proliferación de los servicios en la nube ha introducido varias opciones nuevas relacionadas con las copias de seguridad, principalmente la necesidad de realizar copias de seguridad de datos alojados en la nube y de sistemas SaaS, junto con nuevas ubicaciones y proveedores que pueden utilizarse para almacenar copias de seguridad a nivel de datos.
Las consideraciones para las copias de seguridad incluyen una definición cuidadosa de lo siguiente:
Además, el método utilizado para restaurar un sistema a partir de una copia de seguridad también es importante, así como el impacto que tiene en sus usuarios.
Históricamente, solo se realizaban copias de seguridad fiables de los sistemas o datos empresariales más críticos, por lo que el alcance de las copias de seguridad se centraba en los sistemas, servidores o bases de datos más importantes. Con el coste moderno del almacenamiento significativamente más bajo que en el pasado, el alcance de las copias de seguridad se ha expandido drásticamente, tendiendo hacia las copias de seguridad de todo el sistema en lugar de hacer copias de seguridad selectivas de un componente de la aplicación o de un tipo de datos.
Los métodos utilizados para crear copias de seguridad pueden variar mucho, desde formatos de copia de seguridad específicos de una aplicación, como un volcado binario de la base de datos, hasta imágenes de equipos virtuales, pasando por copias de seguridad de configuraciones o copias de seguridad compuestas que pueden combinar el estado de una aplicación con datos y el propio código de la aplicación. El método utilizado para crear copias de seguridad puede tener un impacto significativo en el tiempo que se tarda en crear una copia de seguridad, la frecuencia con la que se puede ejecutar y cómo se restaura. Las copias de seguridad también pueden diferir en cómo se crean y en lo bien que capturan el estado de un sistema en funcionamiento. Existen tres tipos principales de copias de seguridad a tener en cuenta en los sistemas ArcGIS:
La frecuencia con la que se realizan las copias de seguridad de un sistema y el momento de inicio en el que se producen también son consideraciones importantes. Hacer copias de seguridad con demasiada frecuencia puede suponer un coste excesivo o un aumento de las interrupciones del sistema, mientras que hacerlas con muy poca frecuencia podría significar una pérdida de datos inaceptable entre un evento de interrupción y la copia de seguridad más reciente. La mayoría de las copias de seguridad están diseñadas para evitar interrumpir a los usuarios en algún nivel, pero el momento en que se realiza una copia de seguridad puede afectar a los datos y flujos de trabajo que se capturan en la misma. Por lo general, las copias de seguridad se realizan durante las «horas de descanso» de un sistema (si existen) para capturar la mayor parte de los datos y la información del día anterior, en lugar de en mitad de una jornada laboral, donde la copia de seguridad podría capturar solo una parte de un proceso más largo o de un dataset más grande en el que se está trabajando activamente.
La razón por la que existe un proceso de copia de seguridad puede parecer evidente, por ejemplo, para restaurar el estado de un sistema, pero las copias de seguridad se utilizan además para una variedad de casos de uso matizados. Algunas copias de seguridad están vinculadas a actualizaciones del sistema, de modo que si se descubre un problema con la actualización, el sistema puede volver a un estado conocido. La misma consideración impulsa los procesos de copia de seguridad vinculados a un cambio disruptivo del sistema como la eliminación de un servidor o la adición de un nuevo componente. Algunas copias de seguridad se crean solo para el peor escenario posible, de modo que cuando se produzca ese desastre se puedan utilizar para recuperarse de él. Otros se utilizan para crear la instantánea del estado de un entorno y crear un nuevo entorno inferior a modo de copia, o para promover contenido en la otra dirección desde un entorno inferior hacia un sistema superior de nivel de producción.
La recuperación ante desastres o DR es un tema que suele estar estrechamente ligado a un proceso de copia de seguridad y restauración, pero no son sinónimos. La DR se refiere específicamente a «qué hacemos para recuperarnos tras un desastre», el proceso que requeriría la recuperación y la definición de lo que significan tanto «desastre» como «recuperación» en el contexto específico de una organización. Los desastres suelen referirse a interrupciones importantes de los sistemas informáticos, ya sean causados por problemas de hardware, medioambientales o de configuración del usuario, que provocan una interrupción significativa del tiempo de actividad, la disponibilidad o la funcionalidad de un sistema.
Uno de los primeros pasos para establecer un proceso de DR es saber qué constituye un «desastre» que requiera un proceso de recuperación ante desastres. Definir esto con cuidado es importante, ya que una definición demasiado sensible (como una solicitud fallida a un sistema primario) puede conducir a frecuentes acciones de conmutación por error de DR, pero esperar hasta que una interrupción haya superado las cuatro horas de duración podría ser demasiado permisivo y dar lugar a una amplia interrupción del usuario. Al final, definir «qué constituye un desastre» para que un sistema pueda tomar medidas para iniciar una recuperación o una conmutación por error, implica una toma de decisiones tanto automatizada como administrada por personas y dependerá de las definiciones organizativas de conceptos como disponibilidad, criticidad y tiempo de actividad. Ejemplos comunes de un «iniciador» de DR serían la pérdida de acceso a un centro de datos, un fallo de almacenamiento, fallos en el hipervisor de las máquinas virtuales, un corte de DNS o un problema de conectividad de red, e incluso la corrupción de datos o un ataque de ransomware a un sistema.
Otra definición clave en el proceso de DR es el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO) de la organización. El RPO equivale a la cantidad de datos que perdemos en un escenario de desastre y se refiere al tipo de copias de seguridad que se crean y a la frecuencia con la que se realizan copias de seguridad de los datos o las configuraciones. Un RPO de cuatro horas significaría que, en el peor de los casos, se pierden cuatro horas de datos o trabajo cuando se produce una interrupción a nivel de DR, y la organización se siente cómoda con la posibilidad de perder esas 4 horas de datos o entradas en un proceso de DR. Aunque un RPO bajo parece un planteamiento obvio, en la mayoría de los sistemas la complejidad de las copias de seguridad y la posibilidad de interrumpir a los usuarios hacen que un RPO bajo tenga un coste demasiado elevado en recursos, almacenamiento o impacto en los usuarios.
RTO significa el tiempo que transcurre hasta que volvemos a estar operativos y se refiere al tiempo que se tarda en restaurar las copias de seguridad en un sistema de DR, crear un nuevo sistema desde cero o implementar recursos automáticamente para recuperarse de un desastre. El RTO suele ser inferior al RPO, ya que es posible que ya exista un sistema de conmutación por error, o componentes de uno, y la capacidad de cambiar a ese sistema solo requiere un cambio de DNS o de red. Definir y lograr un RPO y un RTO realistas son dos partes importantes de la creación de una estrategia de DR y de conseguir el acuerdo de las partes interesadas en cuanto a las implicaciones de costes y flujos de trabajo de la implementación de esta estrategia.
Un planteamiento habitual para responder a un escenario de catástrofe es conmutar el tráfico a un sistema de conmutación por error, que existe para asumir el tráfico cuando un sistema primario identifica o experimenta problemas. Este planteamiento tiene varios requisitos importantes que repercuten en los costes y el flujo de trabajo:
Otro planteamiento de DR consiste en utilizar las copias de seguridad para regenerar un sistema, lo que puede dar lugar a un RTO más largo, pero reduce el coste continuo, ya que no se mantiene un sistema de conmutación por error en todo momento. Esto puede implicar realizar copias de seguridad de las máquinas virtuales o una copia de seguridad a nivel de aplicación, y luego regenerar el sistema, ya sea automáticamente mediante la automatización de la infraestructura como código y la implementación de software, o manualmente con un equipo experimentado, antes de que se restaure la copia de seguridad, el tráfico vuelva al sistema y los usuarios puedan restaurar las cargas de trabajo en el sistema.
Los procesos de DR también pueden tener implicaciones o planteamientos más amplios que no sean exclusivos del sistema empresarial construido con ArcGIS. Por ejemplo, todo un centro de datos puede tener una estrategia de DR que utilice la replicación de máquinas virtuales para mantener un conjunto de máquinas virtuales en un centro de datos separado, y cuando se identifique una interrupción con un componente de almacenamiento o hipervisor, todos los usuarios podrían cambiar para acceder al centro de datos secundario.
Los procesos de DR también deben tener en cuenta lo que ocurre después de una recuperación. Si hay un sistema o centro de datos primario y un evento de DR provoca un fallo en un sistema secundario, ¿es el planteamiento estándar volver a conmutar el tráfico a los sistemas primarios una vez resuelta la interrupción? ¿O el sistema en espera se convierte ahora en el primario y el sistema original se configura como en espera para respaldar la siguiente situación de DR? Ambos escenarios tienen valor y definir lo que ocurre una vez resuelto el incidente es una parte importante para completar la estrategia y el planteamiento de DR.
En los sistemas ArcGIS, existen varios planteamientos para iniciar un proceso de copia de seguridad que están integrados en el software ArcGIS. Las copias de seguridad de un único componente, que solo respaldan el contenido y el estado de una única aplicación, están disponibles para los componentes de ArcGIS Enterprise, incluidos Portal for ArcGIS, ArcGIS Server y ArcGIS Data Store. Estas copias de seguridad de componentes específicos no están pensadas principalmente para fines de DR, sino para realizar copias de seguridad y restaurarlas en su sitio; para fines de DR se recomienda la herramienta WebGISDR. Cada componente tiene un planteamiento de copia de seguridad diferente, incluidos:
Varios roles de ArcGIS Server no suelen tener estado y todas las configuraciones relevantes se almacenan como elementos del portal y, por lo general, no necesitan copias de seguridad. Incluye el Notebook Server, el Business Analyst Enterprise Server (GeoEnrichment Server) y el servidor de análisis de ráster. Por lo general, cada uno de estos componentes puede volver a crearse a partir de un equipo en blanco o de una imagen instalada, en lugar de restaurar la implementación específica, ya que el contenido se almacena en ArcGIS Enterprise. La única consideración más allá de esto serían los escenarios en los que se ha implementado código personalizado o bibliotecas de terceros en el sistema para habilitar un flujo de trabajo basado en Python u otro proceso.
Más allá de la funcionalidad de copia de seguridad específica de cada componente, ArcGIS Enterprise también dispone de una herramienta de copia de seguridad multicomponente denominada herramienta de recuperación ante desastres del SIG en la Web (WebGISDR para abreviar) que puede realizar copias de seguridad del estado de varios componentes diferentes de ArcGIS Enterprise al mismo tiempo.
La herramienta WebGISDR se describe con todo detalle en la documentación de ArcGIS Enterprise, pero es importante señalar que esta herramienta da prioridad a la coherencia y el estado de la aplicación colectiva frente a la velocidad de las copias de seguridad o la flexibilidad del proceso. En la práctica, esto significa que la herramienta intenta capturar el estado del sistema exactamente en el momento en que se ejecutó la solicitud. Si se publican más datos o contenido mientras se realiza la copia de seguridad, no aparecerán en ninguno de los archivos de la copia de seguridad y no se podrán restaurar en un sistema de recuperación de fallos. Este enfoque es sinónimo de un énfasis en la RPO en lugar de la RTO, priorizando la integridad funcional de un sistema sobre la rapidez con la que se puede restaurar el sistema (lo que puede provocar errores de configuración o datos erróneos).
Más allá de las copias de seguridad específicas de la aplicación ArcGIS, existen otros métodos que pueden una organización puede sugerir o preferir, que pueden ser nativos de un componente específico o de un proveedor de infraestructuras. Estos métodos pueden ser adecuados para una copia de seguridad de ArcGIS o un proceso de recuperación ante desastres, pero deben evaluarse y considerarse cuidadosamente, ya que su uso también puede resultar perjudicial para un sistema.
Por ejemplo, las instantáneas de máquinas virtuales son un planteamiento habitual para realizar copias de seguridad de un sistema, pero pueden introducir retos complicados si el método para la instantánea incluye un reinicio repentino del equipo, o capturar solo el estado de los datos, ya que las operaciones o configuraciones en proceso podrían no capturarse o capturarse parcialmente, lo que podría conducir a un estado inesperado y corrupto cuando se produzca la restauración o recuperación.
Las estrategias de copia de seguridad basadas en máquinas virtuales mueven en ocasiones recursos de máquinas virtuales entre dos fuentes de datos para evitar una interrupción. En estos escenarios, asegúrese de que los alojados en ArcGIS Server y ArcGIS Pro acceden a una base de datos en su propio centro de datos y no realizan peticiones al centro de datos original, ya que esto introducirá una latencia que afectará negativamente a la experiencia del usuario.
Las herramientas de copia de seguridad y de recuperación ante desastres basadas en la nube, como Microsoft Azure Site Recovery, pueden ser compatibles con los sistemas ArcGIS Enterprise cuando se planifican cuidadosamente para que la resolución de DNS, la conectividad de la base de datos y la conectividad del cliente al sistema se mantengan en el caso de una operación de recuperación del sitio. Estos planteamientos de copia de seguridad operan a un nivel de acceso a la máquina virtual relativamente bajo, por lo que no ofrecen garantías de coherencia de la aplicación. Esto significa que, aunque el sistema de recuperación suele restaurarse y funcionar correctamente, en algunos casos podrían producirse incoherencias a nivel de aplicación, es decir, un proceso de publicación en curso o una edición de un servicio de entidades realizada durante el proceso de copia de seguridad. Hay formas de planificar esto, como tomar instantáneas de la máquina virtual durante periodos de menor actividad, pero en general la orientación de «planificar, probar y considerar cuidadosamente las implicaciones» se aplica a estos planteamientos de herramientas externas.
Los proveedores de bases de datos que crean las bases de datos relacionales con las que trabaja ArcGIS (ya sea como geodatabase corporativa o como origen de una capa de consulta) proporcionan sus propias opciones de copia de seguridad específicas de la base de datos, que normalmente pueden crear una copia de seguridad basada en archivos del contenido y las configuraciones de la base de datos para restaurarla en un nuevo sistema o implementación cuando sea necesario.
ArcGIS Online, como oferta y sistema SaaS, debe plantearse de otro modo desde la perspectiva de las copias de seguridad y la recuperación. Como parte de la estabilidad del sistema, Esri gestiona los requisitos de copia de seguridad y recuperación en caso de interrupciones del hardware y del sistema, sin intervención del usuario, y el acuerdo de nivel de servicio con ArcGIS Online refleja este compromiso. ArcGIS Online no proporciona actualmente un método para que los usuarios creen copias de seguridad de toda la organización o copias de seguridad del contenido, y las organizaciones tendrán que definir una estrategia para sus propias copias de seguridad adicionales del contenido o las configuraciones en ArcGIS Online a través de una variedad de patrones, entre los que se incluyen:
Tenga en cuenta que los partners de Esri también han creado soluciones de copia de seguridad que pueden consultarse o adquirirse a través de ArcGIS Marketplace.
ArcGIS Online ha introducido recientemente la funcionalidad de papelera de reciclaje, que almacenará el contenido eliminado durante un periodo de 14 días (de forma predeterminada) antes de eliminarlo definitivamente. El contenido de la papelera de reciclaje puede restaurarse a su estado y ubicación anteriores con un sencillo flujo de trabajo. Esto ayudará a evitar que se elimine contenido que esté interrelacionado con otro, pero que no esté claramente identificado como dependiente de ese otro contenido.
Para los datos fundacionales del servicio de entidades alojado, utilice la funcionalidad Rastreo de cambios para almacenar el contenido de las filas anteriores a medida que se realizan las ediciones. Se puede acceder a estas versiones anteriores mediante la operación Extraer cambios.