Servicios de copia de seguridad
Nada atemoriza más al personal de TI que las pérdidas de datos. La forma más eficaz de evitar una pérdida de datos consiste en hacer una copia de seguridad de los volúmenes de almacenamiento, máquinas virtuales, bases de datos y demás sistemas que almacenan datos para que sus datos puedan restaurarse. Los proveedores de servicios en la nube ofrecen servicios de copia de seguridad solo con este propósito. En general, estos servicios se pueden usar para hacer copias de seguridad de los datos almacenados tanto de forma local como en la nube, y las copias de seguridad se pueden replicar y distribuir geográficamente para protegerse de eventos que desembocan en pérdidas de datos en un centro de datos o una región completa.
La nube pública proporciona recursos fluidamente en grandes volúmenes, y no en fragmentos grandes de almacenamiento, sino en grupos de almacenamiento altamente escalables. Son como poco tan versátiles (y, en algunos casos, incluso más) como los sistemas de almacenamiento de copia de seguridad y las unidades de cinta, a los que están reemplazando. Además, la nube está brindando a las organizaciones nuevas oportunidades de implementar redundancias, conmutaciones por error y redes de seguridad que muchos nunca podríamos habernos permitido en la época en la que todos los recursos se adquirían mediante capital circulante. Las opciones de almacenamiento en la nube pública cumplen un rol que los centros de datos siempre han necesitado de manera acuciante, pero que ha sido muy difícil de obtener hasta hace bien poco.
Servicios de copia de seguridad basados en la nube
Lo que caracteriza a los servicios de copia de seguridad modernos que prestan los proveedores de servicios en la nube pública (CSP) es la manera en que amplían la infraestructura de sus clientes. Antes de la llegada de estos servicios, la estrategia de copia de seguridad típica de una organización tenía dos niveles: copia de seguridad de los volúmenes de datos que hospedaban bases de datos y copia de seguridad de las imágenes de máquina virtual que hospedaban cargas de trabajo críticas. La teoría tras la copia de seguridad consistía en que, cuando un mal funcionamiento del sistema generaba un error, ello hacía que un servidor se desactivara. El curso de acción inmediato era pues restaurar el estado de ese servidor a partir de una imagen de copia de seguridad.
La infraestructura basada en la nube deja obsoleta esta teoría anterior de copia de seguridad. En los sistemas modernos, los servidores se componen de software, no de hardware. Los servidores virtuales se hospedan en una infraestructura virtual basada en hipervisor (como NSX de VMware) o se ensamblan desde contenedores y se hospedan en sistemas operativos virtualizados. En ambos casos, las imágenes de software de las cargas de trabajo relativas a las aplicaciones y los servicios se administran, actualizan y mantienen protegidas en todo momento. De hecho, los componentes de software activos son en sí réplicas de estos maestros seguros o, en la inclusión en contenedores, son productos de los maestros originales almacenados en repositorios de contenedores y se ensamblan automáticamente según sea necesario. Lo único que ocurre cuando un error de hardware desactiva un nodo de servidor es que los servidores hospedados en ese nodo no estarán disponibles durante un tiempo, mientras que la infraestructura desviará el tráfico para que no pase por ese nodo y hará todo lo posible por reemplazarlo mientras tanto. El administrador de la infraestructura no hará nada que no haya hecho ya en el curso normal de la administración del sistema.
No obstante, como revela una rápida exploración de los centros de datos modernos, no toda la infraestructura moderna está basada en la nube, sino que aún hay servicios hospedados en equipos sin sistema operativo en centros de datos locales. Las redes cliente/servidor, completadas con middleware, todavía abundan. Y en un sistema híbrido, en el que una parte diseñada hace unos años se conecta a otra diseñada hace décadas, sigue siendo necesario almacenar suficiente información sobre la circunscripción de un sistema de forma tal que, si se produjera un desastre, dicho sistema pueda reconstruirse (sin importar cómo, pero siempre de un modo apremiante) en una nueva ubicación con un impacto mínimo en los niveles de servicio. Con las estrategias de copia de seguridad modernas, la nube pública puede ser esa ubicación, aun cuando los sistemas de los que se van a hacer instantáneas no estén en la nube.
AWS Backup
A inicios de 2019, Amazon Web Services rediseñó su servicio de copia de seguridad basado en la nube para los entornos de nube híbrida de los clientes. La esencia del nuevo servicio AWS Backup, cuya consola basada en explorador se muestra en la Figura 2, es un motor de directivas similar al árbitro de las reglas para un firewall. Con este motor, el administrador de copias de seguridad escribe reglas que especifican lo siguiente:
Qué recursos de un sistema requieren una copia de seguridad
Cómo se debe realizarse cada copia de seguridad y con qué frecuencia
Dónde deben almacenarse las imágenes de las copias de seguridad
Cómo se debe supervisar la integridad de las imágenes de copia de seguridad, incluida su frecuencia
Cuánto tiempo deben conservarse las imágenes de copia de seguridad
En qué circunstancias deben realizarse operaciones de recuperación y restauración
El itinerario completo que engloba todas las directivas activas es el plan de copia de seguridad. En él, cada regla hace referencia a los recursos de la nube de AWS que precisan de una copia de seguridad a partir del valor de su etiqueta, que es un nombre arbitrario proporcionado por el administrador. Para incluir un recurso como un volumen de Elastic Block Storage (EBS) en un plan de copia de seguridad, el administrador solo necesita dar a ese recurso un nombre de etiqueta que AWS Backup sea capaz de identificar. Así, el administrador o encargado responsable de un recurso de AWS no tendrá que usar la consola de AWS Backup solamente para establecer un recurso en su ámbito de actuación como parte de un plan de copia de seguridad existente.
![Figure 2: The AWS Backup console. [Courtesy Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Figura 2: Consola de AWS Backup [Cortesía de Amazon]
Se pueden incorporar recursos locales a un plan de copia de seguridad por medio de AWS Storage Gateway. En lo que respecta a AWS Backup, Storage Gateway actúa como un contenedor de API de dispositivos y volúmenes de almacenamiento físico, lo que hace que sean accesibles para los servicios de AWS.
Originalmente, Storage Gateway permitía sustituir los recursos de almacenamiento físico existentes por sus homólogos basados en la nube correspondientes usando la misma interfaz. Por ejemplo, un volumen iSCSI local podría estar incluido en lo que AWS denomina volumen almacenado en caché. Este contenedor hace que el almacenamiento en la nube esté accesible en las aplicaciones locales existentes sin que los clientes tengan que rediseñar esas aplicaciones. Los datos a los que se accede con frecuencia se pueden seguir almacenando en el volumen iSCSI como una memoria caché, lo que reduce la cantidad de latencia empleada. Como alternativa, los cambios recientes en el contenido del volumen de puerta de enlace se pueden almacenar localmente como instantáneas. Pero Storage Gateway también admite volúmenes almacenados, según los cuales el dispositivo local sigue manteniendo una copia local completa del volumen, de la que Storage Gateway crea un reflejo en la nube. El nuevo servicio AWS Backup aprovecha el intercambio de roles de Storage Gateway con volúmenes físicos, lo que convierte la copia local en la copia de seguridad del volumen basado en la nube, al tiempo que se agrega una consola de administración de directivas centralizada con reglas que rigen cómo deben mantenerse ambas réplicas.
Con respecto a la recuperación ante desastres, una ventaja importante que un CSP ofrece es la capacidad de archivar rápidamente los datos críticos de una organización en ubicaciones lejanas para, así, lograr lo que se conoce como redundanciageográfica. AWS opera en centros de datos en la nube en el mayor número de zonas de disponibilidad de cualquier CSP. Anuncia la capacidad nativa de las aplicaciones que hospeda para conmutar por error automáticamente a zonas alternativas, y amplía esta capacidad a la redundancia de copias de seguridad de datos. Pero las zonas de conmutación por error residen en la misma región de AWS; por lo tanto, en una situación de desastre extrema (que las aseguradoras y, por tanto, los administradores de riesgos, tienen muy en cuenta) como puede ser una caída del sistema eléctrico, las zonas de disponibilidad contiguas unas a otras podrían experimentar interrupciones.
Un desarrollador de software (o un operador de TI con experiencia de desarrollador) puede escribir directivas personalizadas de enrutamiento específico de la redundancia geográfica de una organización usando el servicio de enrutamiento de bajo nivel de AWS, Route 53, pero esta técnica requiere mucho esfuerzo. Hace poco, AWS ha puesto en marcha un servicio más accesible denominado AWS Global Accelerator, que es otro motor de directivas que guía el tráfico e indica a Route 53 dónde deben hospedarse los servicios y el almacenamiento.1 Global Accelerator también se puede usar a modo de "megaequilibrador" que permite la distribución de varios sitios de aplicaciones hospedadas (y, con ellas, sus datos críticos) entre zonas de disponibilidad dispersas.
Otra forma de asegurarse de que las copias de seguridad de datos se almacenan en una región a una distancia adecuada, según proponen los técnicos de Amazon, es establecer un depósito (contenedor de copias de seguridad de uso general de AWS) como el destino de la copia de seguridad inicial y, tras ello, replicar ese depósito en una ubicación redundante en cualquier zona de disponibilidad designada. AWS ofrece Cross-Region Replication (CRR) como un servicio independiente.2 AWS establece los precios su servicio de copia de seguridad en términos de volumen, tanto por gigabyte almacenado como por gigabyte restaurado.
Desde un punto de vista de la arquitectura, AWS Backup está diseñado para actuar como un reflejo de los recursos de AWS. La forma de hacer que los recursos locales formen parte de ese plan es a través de una especie de doble puerta trasera. Para ello, primero esos recursos locales se convierten en volúmenes de AWS remotos (remotos desde la perspectiva de Amazon) y, después, Backup se conecta al contenedor que incluye esos recursos locales.
Azure Backup
Azure Backup es igual de capaz de hacer copias de seguridad tanto de los recursos locales (servidores y máquinas virtuales) como de los recursos hospedados en Azure. No tiene como objetivo cambiar la directiva de copia de seguridad existente en el centro de datos, sino que solo reemplaza los discos locales y las unidades de cinta por almacenamiento en la nube. La ubicación basada en la nube de los archivos y volúmenes de copia de seguridad en Azure se denomina almacén de Recovery Services, cuya consola basada en explorador se muestra en la Figura 3. Durante el proceso de instalación de este almacén a través de Azure Portal, el administrador descarga e instala el agente del lado cliente, conocido como agente de Servicios de recuperación de Microsoft Azure o "MARS". En Windows Server, MARS se ejecuta como una aplicación, en gran medida a como lo hacen los complementos de System Center. (Un administrador puede preferir usar System Center Data Protection Manager, donde la funcionalidad MARS ya está integrada). El administrador localiza los volúmenes y servicios de la red cuyos datos requieren una copia de seguridad, y MARS distribuye sus agentes a las direcciones de servidor responsables de esos componentes.
![Figure 3: The console for Azure Recovery Services Vault. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Figura 3: Consola del almacén de Azure Recovery Services [Cortesía de Microsoft]
El modelo de entrega de Azure Backup gira en torno a los objetivos de nivel de servicio de la recuperación ante desastres, que proporcionan unas métricas razonables para determinar el tiempo que una organización puede resistir sin tener acceso al motor de su negocio, así como la cantidad de datos que se puede perder en caso de desastre. Abordaremos estos objetivos específicos (RPO, RTO y retención) en la siguiente lección sobre la recuperación ante desastres.
El tipo de recuperación que concierne a Azure Backup (en contraposición a Azure Site Recovery, que es el servicio de recuperación ante desastres de Microsoft) se centra por completo en la replicación de , y no en la restauración del servicio. Por ejemplo, un cliente puede usar Azure Backup para crear réplicas de archivos de imagen de máquina virtual (VHD), pero la restauración de un VHD lo que hace simplemente es reproducir de nuevo el archivo de imagen archivado en el almacenamiento local, y no reinicia el servidor virtual basado en ese VHD.
Azure Backup cobra solo por el espacio de almacenamiento consumido al mes, sin costo extra alguno por las restauraciones. Su modelo de precios de almacenamiento está directamente ligado a sus opciones de redundancia. Actualmente, Azure ofrece dos opciones: almacenamiento con redundancia local (LRS), que es el menos costoso y que replica los datos tres veces dentro de un centro de datos de Azure, y almacenamiento con redundancia geográfica (GRS), que replica los datos en una región secundaria geográficamente distante de la región primaria.
Copia de seguridad de Google Cloud Storage
Google ofrece una variedad de niveles de almacenamiento en la nube basados en la clase de datos que se almacenen (por ejemplo, archivos de disponibilidad persistente, almacenamiento en bloque de imágenes de máquinas virtuales, almacenamiento de objetos de vídeos...). No comercializa expresamente un servicio de copia de seguridad de la marca en ninguno de estos niveles, si bien es cierto que los servicios de almacenamiento se pueden usar (y, de hecho, se usan) para operaciones de copia de seguridad y recuperación. Google da por hecho que las copias de seguridad estarán entre las principales razones por las que una empresa invertirá en el almacenamiento en la nube en volúmenes elevados.
![Figure 4: The contents of a Google Cloud Storage bucket. [Courtesy Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Figura 4: Contenido de un depósito de Google Cloud Storage [Cortesía de Google]
En su caso, Google llama depósito a su contenedor de almacenamiento de uso general. En la Figura 4 se muestra un paso en el proceso de importación de datos desde el almacenamiento local a un depósito de Google Cloud Storage (GCS). De forma similar a cómo Azure basa su modelo de entrega en torno a tres parámetros clave, los parámetros clave de GCS son los siguientes:
Rendimiento, que en este contexto es sinónimo de disponibilidad (con qué rapidez responderán los servidores a las solicitudes de lectura de datos de los clientes)
Retención, en referencia de nuevo al tiempo que el cliente espera mantener los datos almacenados en la nube
Patrones de acceso, concepto relacionado con la accesibilidad (esto es, con qué frecuencia el cliente espera leer o recuperar los datos almacenados)
Al inicializar un depósito, el cliente de GCS elige su clase de almacenamiento, que especifica su directiva de replicación. Esta elección determina (una vez que el depósito empiece a usarse para las copias de seguridad) cómo van a estar de dispersos los datos almacenados. En la actualidad, GCS ofrece tres opciones de geolocalización:
Región: los datos se almacenan en una única región seleccionada del territorio de servicio de Google.
Región doble: la replicación se realiza en dos territorios de servicio seleccionadas.
Multirregión: los datos se distribuyen de forma redundante entre varios territorios de servicio.
Tras ello, GCS subdivide las clases de almacenamiento en depósito en función de la frecuencia con la que se va a acceder a ellas:
Standard Storage (alta disponibilidad): datos destinados a que las aplicaciones y los usuarios puedan acceder a ellos fácilmente.
Coldline Storage: permite al cliente intercambiar parte de la cuota de almacenamiento mensual por cargos de acceso y transferencia en el caso de los datos a los que se quiere acceder solo varias veces al año.
Nearline Storage: se trata más bien de un intercambio de gama media relativa a los datos a los que se accede aproximadamente una vez al mes.
El enfoque de Google para comercializar su infraestructura en la nube a las empresas es presentar sus servicios como un tipo de dispositivo que no se ve. En este sentido, Google puede haber invertido un esfuerzo doble: ofrecer en qué consiste el dispositivo y, a modo de servicio aparte, cómo usarlo, como si vendieran un horno y, después, comercializaran una suscripción para aprender a cocinar comida como un valor extra.
De este modo, la organización de cliente de GCS selecciona la infraestructura que se necesita para los trabajos que se tienen en mente, y adapta la configuración de esa infraestructura como si fueran características de un dispositivo. (Al igual que AWS y Azure, Google ofrece un dispositivo de montaje en bastidor para centros de datos con el propósito inmediato de lograr una transferencia de alta velocidad entre el almacenamiento local y en la nube). Estas características se pueden ir personalizando con el tiempo en función de cómo cambie el uso de ese almacenamiento. Por ejemplo, supongamos que una empresa de producción de vídeo necesitaba grandes cantidades de almacenamiento de copias de seguridad para las versiones de una película que se está editando. Durante el proceso de edición, esas copias pueden recuperarse con bastante frecuencia, por lo que el cliente puede establecer el depósito en Standard Storage en el territorio Región. Una vez que el vídeo se complete y distribuya públicamente, puede que siga siendo necesario tener las copias a mano durante el próximo año, aunque posiblemente no se acceda a ellas a menudo. En tal caso, el depósito Standard Storage se puede transferir a un depósito Coldline, con un territorio Región doble por motivos de seguridad y archivado.
Referencias
Amazon Web Services, Inc. Traffic management with AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/ (Administración del tráfico con AWS Global Accelerator).
Amazon Web Services, Inc. Overview of Setting Up Replicationhttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html (Información general de la configuración de la replicación).