En esta página se describe cómo activar inicialmente el servicio de copia de seguridad y recuperación ante desastres, así como configurar tu proyecto.
Componentes de la arquitectura de Backup and DR
La arquitectura del servicio de copia de seguridad y recuperación tras fallos se ofrece a través de los siguientes componentes:
Consola de gestión: la consola de gestión sirve como plano de gestión de tus dispositivos de copia de seguridad y recuperación. Cada implementación de Backup y DR incluye una única consola de gestión que gestiona cualquier número de dispositivos de copia de seguridad o recuperación. La consola de gestión se despliega en el proyecto de administración de copias de seguridad y tiene una alta disponibilidad en la región desplegada, lo que proporciona resiliencia frente a las interrupciones de zonas.
Dispositivos de copia de seguridad y recuperación: el dispositivo de copia de seguridad y recuperación es el encargado de mover los datos, ya que captura, mueve y gestiona de forma eficiente el ciclo de vida de los datos de copia de seguridad de tu empresa. Los dispositivos de copia de seguridad y recuperación se implementan en la entidad de carga de trabajo para las cargas de trabajo en la nube.
Agentes de copia de seguridad y recuperación tras fallos: el agente de copia de seguridad y recuperación tras fallos llama a las APIs nativas de la aplicación para capturar datos de forma eficiente de las aplicaciones de producción de forma incremental y proporciona información sobre la aplicación en el momento de la recuperación. El agente se instala en los hosts de las aplicaciones que se van a proteger. Si solo proteges toda la VM o un subconjunto de sus discos, no es necesario el agente de Backup and DR.
La consola de gestión se activa en una red de VPC de productor de servicios. La VPC del productor de servicios se comunica con tu proyecto mediante el acceso privado de Google.
La comunicación entre el servidor de gestión y los dispositivos, entre los dispositivos y entre los dispositivos y los agentes host está protegida mediante la autenticación TLS mutua.
Consideraciones de implementación
A continuación, se indican algunas consideraciones importantes que afectan a la forma en que implementas el servicio Backup and DR:
¿Cuáles son los requisitos de tiempo de recuperación (RTO) de tu organización? El tiempo de recuperación es el tiempo máximo que puedes permitirte estar sin tus datos. Por ejemplo, si tu RTO es de 4 horas,debes poder acceder a tus datos en un plazo de 4 horas después de un desastre.
¿Necesitas centralizar la gestión de tus copias de seguridad? Debes decidir si quieres gestionar tus copias de seguridad de forma centralizada o no.
- La gestión centralizada de copias de seguridad significa que tienes una única consola de gestión para gestionar las copias de seguridad de todas tus cargas de trabajo en todas las líneas de negocio. Esta puede ser una forma más eficiente de gestionar las copias de seguridad, ya que solo tienes que gestionar una única consola de administración.
- La gestión de copias de seguridad descentralizada significa que tienes una consola de gestión independiente para cada línea de negocio. El modo de funcionamiento varía de una organización a otra.
¿Cuál es tu caso práctico de copia de seguridad? ¿Necesitas copias de seguridad para estar preparado ante desastres en caso de que se produzca un desastre en una región de producción, o es suficiente con proteger tus datos de forma local? Si necesitas una función de recuperación tras fallos, debes plantearte usar copias de seguridad interregionales. Esto significa almacenar tus copias de seguridad en varias ubicaciones para que, si una de ellas se ve afectada por un desastre, tus datos sigan estando accesibles.
Las cargas de trabajo están en una sola región
La mejor estrategia de copia de seguridad en una región depende de tus necesidades.
Si no necesitas la recuperación tras fallos
Para obtener el mejor rendimiento y reducir los costes, despliega la consola de gestión y los dispositivos de copia de seguridad y recuperación en la misma región en la que se ejecutan tus cargas de trabajo. Almacena las imágenes de backup en la misma región que tus cargas de trabajo.
Si también quieres tener copias de seguridad externas, puedes almacenar copias de seguridad en otra región o usar el almacenamiento birregional o multirregional. Almacenar copias de seguridad en una región diferente conlleva cargos de red y de almacenamiento.
Si necesitas tanto una copia de seguridad como un plan de recuperación ante desastres
Para obtener el mejor rendimiento y reducir los costes, implementa una consola de gestión en la misma región que la carga de trabajo de producción y una segunda consola de gestión en la región que puedes usar para la recuperación tras desastres.
Implementa dispositivos de copia de seguridad y recuperación tanto en la región de la carga de trabajo de producción como en la región de recuperación tras desastres para minimizar el objetivo de tiempo de recuperación (RTO). De esta forma, se asegura de que un entorno de recuperación ante desastres esté totalmente aprovisionado y disponible en caso de desastre.
Almacena imágenes de copia de seguridad en la región de producción y una copia en la región de recuperación tras desastres, o bien usa el almacenamiento birregional o multirregional. La copia de seguridad de la región de producción puede satisfacer las necesidades de copias de seguridad rutinarias con un rendimiento más rápido. Los datos copiados en tu región de recuperación ante desastres se pueden usar para recuperar tus cargas de trabajo en caso de que la región de producción no funcione.
Las cargas de trabajo están en varias regiones
La mejor estrategia de copia de seguridad entre regiones depende de tus necesidades.
Si no necesitas la recuperación tras fallos
Para obtener el mejor rendimiento y reducir los costes, despliega la consola de gestión en una de las regiones en las que se ejecutan tus cargas de trabajo. Esto permite una gestión centralizada de todas las cargas de trabajo y regiones.
Despliega uno o varios dispositivos de copia de seguridad o recuperación en cada región en la que se ejecuten las cargas de trabajo. Almacena tus copias de seguridad en la misma región que tus cargas de trabajo.
Si también quieres tener copias de seguridad externas, puedes almacenar copias de seguridad en otra región o usar el almacenamiento birregional o multirregional. Almacenar copias de seguridad en otra región o multirregión conlleva cargos de red y de almacenamiento.
Si necesitas tanto una copia de seguridad como un plan de recuperación ante desastres
Implementa una consola de gestión en cada una de las regiones de la carga de trabajo de producción y otra en la región de recuperación ante desastres.
Implementa dispositivos de copia de seguridad y recuperación en las regiones de la carga de trabajo de producción y en la región de recuperación tras desastres para minimizar el objetivo de tiempo de recuperación (RTO). De esta forma, se asegura de que el entorno de recuperación tras desastres esté totalmente aprovisionado y disponible en caso de desastre.
Almacena las copias de seguridad en la región de la carga de trabajo de producción y una copia en la región de recuperación tras desastres, o bien usa el almacenamiento birregional o multirregional. La copia de seguridad de la región de producción se puede usar para satisfacer las necesidades de copia de seguridad.
Se puede usar una imagen de backup en la recuperación ante desastres para recuperar cargas de trabajo si la región de producción está inactiva.
Configurar el servicio de copia de seguridad y recuperación ante desastres en la consola de Google Cloud
Ve a la consola Google Cloud para activar la API del servicio Backup and DR y configurar los permisos de tu cuenta:
Activar el servicio de copia de seguridad y recuperación tras fallos de Google Cloud
Tipos de dispositivos de copia de seguridad o de recuperación
El servicio de copia de seguridad y recuperación tras fallos ofrece tipos de dispositivos optimizados para diferentes cargas de trabajo: máquinas virtuales de Compute Engine, máquinas virtuales de VMware, bases de datos y sistemas de archivos. Puedes elegir el tipo de dispositivo que mejor se adapte a tus necesidades. Es importante seleccionar el mejor tipo de dispositivo para tus cargas de trabajo. Una vez que el dispositivo de copia de seguridad o recuperación está en servicio, se ejecuta continuamente y siempre está listo para ejecutar y volver a ejecutar copias de seguridad, restauraciones y otros trabajos en cualquier momento.
El servicio de copia de seguridad y recuperación tras fallos ofrece los siguientes tipos de dispositivos:
- Estándar para VMs de Compute Engine o bases de datos de SAP HANA: selecciona esta opción si quieres crear copias de seguridad solo de instancias de Compute Engine o de bases de datos de SAP HANA con Persistent Disk. De forma predeterminada, este dispositivo añade un tipo de máquina e2-standard-4 con una capacidad mínima de disco persistente de 10 GB. Este dispositivo puede gestionar hasta 5000 máquinas virtuales de Compute Engine.
- Estándar para VMs de VMware y otras bases de datos o recursos: selecciona esta opción si quieres una configuración estándar que admita un rendimiento óptimo para crear copias de seguridad de bases de datos, VMs de VMware y otros recursos. De forma predeterminada, este dispositivo añade un tipo de máquina n2-standard-16. De esta forma, se añade una capacidad de disco equilibrada de 4 TB como capacidad mínima de disco. Este dispositivo puede gestionar hasta 1500 aplicaciones.
Básico para VMs de VMware y otras bases de datos o recursos: selecciona esta opción si quieres tener una configuración básica que admita un rendimiento moderado para hacer copias de seguridad de bases de datos, VMs de VMware y otros recursos. De forma predeterminada, este dispositivo añade un tipo de máquina e2-standard-16. Este dispositivo puede gestionar hasta 1500 aplicaciones. Puedes elegir cualquiera de los siguientes tipos de disco para almacenar tus datos.
- Disco persistente con capacidad mínima: esta opción ofrece una capacidad de disco mínima de 10 GB. En este tipo de almacenamiento, las copias de seguridad se almacenan como capturas de disco persistente y no consumen el almacenamiento local del dispositivo de copia de seguridad o recuperación.
- Disco persistente estándar: selecciona este tipo de almacenamiento si quieres tener un almacenamiento en bloques eficiente. Se recomienda para máquinas virtuales de Google Cloud VMware Engine, bases de datos o aplicaciones de sistemas de archivos con E/S de media a alta, además de para máquinas virtuales de Compute Engine. De esta forma, se añade una capacidad de 4 TB de Persistent Disk como capacidad mínima del disco.
- Disco persistente SSD: selecciona este tipo de almacenamiento si quieres tener un almacenamiento en bloques rápido. Se recomienda para aplicaciones de bases de datos, sistemas de archivos o VMware Engine de Google Cloud con una E/S muy alta, además de para máquinas virtuales de Compute Engine. De esta forma, se añade una capacidad de 4 TB de Persistent Disk como capacidad mínima del disco.
Cuando implementas un dispositivo, se crea automáticamente una cuenta de servicio, independientemente del tipo de dispositivo. Puedes ver la cuenta de servicio en la página Cuenta de servicio.
El nombre de la cuenta de servicio aparece en el formato de dirección de correo my-service-account@my-project.iam.gserviceaccount.com, donde appliance-name es el nombre de un dispositivo y projectid es el ID de tu proyecto. Google Cloud
Elegir un tipo de almacenamiento
El dispositivo de copia de seguridad o recuperación almacena los datos de copia de seguridad en el grupo de instantáneas del dispositivo local. Puedes copiarlo en el almacenamiento de objetos para conservarlo a largo plazo. Google Cloud ofrece los tres tipos siguientes de almacenamiento de objetos local:
Persistent Disk con capacidad mínima: las imágenes de copia de seguridad se almacenan como instantáneas de Persistent Disk que no consumen el almacenamiento local del dispositivo de copia de seguridad o recuperación.
Disco persistente estándar: este tipo de almacenamiento ofrece un almacenamiento en bloques eficiente, que empieza con un disco persistente de 4 TB. Se recomienda para motores de VMware y aplicaciones de bases de datos o sistemas de archivos con E/S de media a alta.
Persistent Disk SSD: este tipo de almacenamiento ofrece almacenamiento en bloques rápido, a partir de un Persistent Disk de 4 TB. Se recomienda para Google Cloud máquinas virtuales de VMware Engine y aplicaciones de bases de datos o sistemas de archivos con E/S muy elevadas.
Puedes ampliar la capacidad de tus grupos de discos más adelante.
Puedes mover las copias de seguridad que necesiten conservarse durante mucho tiempo a Google Cloud Standard, Nearline y Coldline Storage en función de la frecuencia con la que preveas acceder a los datos.
Topología de red recomendada para el servicio de copia de seguridad y recuperación tras desastres
Google Cloud recomienda usar VPC compartida al implementar el servicio de copia de seguridad y recuperación tras fallos. La VPC compartida permite a una organización conectar recursos de varios proyectos a una red VPC (VPC) común para que puedan comunicarse entre sí de forma segura y eficiente mediante IPs internas de esa red. Cuando usas la VPC compartida, designas un proyecto como proyecto host y le asocias uno o varios proyectos de servicio. Las redes de VPC del proyecto del host se denominan redes de VPC compartidas. Los recursos aptos de los proyectos de servicio pueden usar subredes de la red de VPC compartida.
La VPC compartida permite a los administradores de la organización delegar responsabilidades administrativas, como la creación y gestión de instancias, en los administradores de proyectos de servicio, al tiempo que se mantiene el control centralizado de los recursos de red, como las subredes, las rutas y los cortafuegos.
La consola de gestión se activa en una red de VPC de productor de servicios. La VPC de este productor de servicios se comunica con tu proyecto mediante el acceso privado de Google. El objetivo principal de esta conexión es que la consola de gestión y los dispositivos de copia de seguridad y recuperación intercambien metadatos. El tráfico de copia de seguridad no atraviesa este enlace. Sin embargo, una consola de gestión debe comunicarse con todos los dispositivos de copia de seguridad o recuperación que se hayan implementado en cualquier red.
Prácticas recomendadas de VPC compartida
Te recomendamos que sigas estas prácticas recomendadas:
Conectarse a la consola de gestión: lo más recomendable es conectar la red del proveedor de servicios a una VPC compartida de tu red. Todo el tráfico de la consola de gestión fluye a través de esta VPC y, por lo tanto, a través del proyecto host. Al aprovisionar la conectividad con el servicio de Backup y DR a través de una VPC compartida, también se habilita una conexión fluida entre los proyectos en los que se ejecutan las cargas de trabajo (proyectos de servicio) y el servicio de Backup y DR.
Ubicación del dispositivo de copia de seguridad o recuperación: los dispositivos de copia de seguridad o recuperación deben desplegarse en una subred que tenga habilitado el acceso privado de Google para conectarse a la consola de gestión. Hay dos estrategias recomendadas para seleccionar los proyectos de los dispositivos de copia de seguridad o recuperación:
En el proyecto host central: en esta estrategia, el servicio de copia de seguridad y recuperación tras fallos se trata como un servicio central del departamento de TI. El equipo central de copias de seguridad se encarga del aprovisionamiento del servicio. Por lo tanto, todos los dispositivos de copia de seguridad y recuperación se aprovisionan en el proyecto host, lo que permite a los administradores centrales consolidar todos los recursos de copia de seguridad en un proyecto central. Este enfoque tiene la ventaja de consolidar todos los recursos relacionados con las copias de seguridad y su facturación en un solo proyecto.
En proyectos de servicio: esta estrategia es adecuada para equipos más descentralizados en los que se crean proyectos de servicio y su gestión se delega en equipos distribuidos. En este caso, la práctica recomendada es aprovisionar una VPC para los proyectos de servicio de nivel inferior. Los dispositivos de copia de seguridad y recuperación se instalan en los proyectos de servicio de estas VPCs. Esto permite la colocación conjunta de la carga de trabajo y el dispositivo de copia de seguridad o recuperación en un mismo proyecto.
Acceso privado de Google: es una práctica recomendada habilitar Acceso privado de Google en cada subred en la que instales un dispositivo de copia de seguridad o recuperación. De esta forma, el dispositivo de copia de seguridad y recuperación puede comunicarse con APIs, como Compute Engine, Cloud Storage y Cloud Logging, lo que es importante para que funcionen la monitorización y las alertas. Para simplificar y mejorar las conexiones a las APIs de Google Cloud , considera la posibilidad de configurar la resolución de DNS para
private.googleapis.com, tal como se describe en la sección Resumen de las opciones de configuración. Además, configura las reglas de cortafuegos de los dispositivos de copia de seguridad o recuperación para permitir las conexiones con el intervalo CIDR199.36.153.8/30en el puerto TCP443.
Configuraciones de cortafuegos
Las siguientes reglas de cortafuegos obligatorias para el tráfico entrante al servicio Backup and DR se añaden automáticamente.
| Finalidad | Fuente | Objetivo | Puerto (TCP) |
|---|---|---|---|
| Tráfico de asistencia (asistencia a electrodomésticos) | Host que ejecuta el cliente SSH | Dispositivo de copia de seguridad o de recuperación | 26 |
| Copia de seguridad iSCSI (del host al dispositivo) | Host que ejecuta el agente de Backup y DR | Dispositivo de copia de seguridad o de recuperación | 3260 |
| Tráfico de StreamSnap (de un dispositivo a otro) | Dispositivo de copia de seguridad o de recuperación | Dispositivo de copia de seguridad o de recuperación | 5107 |
| Conectividad del dispositivo de copia de seguridad o de recuperación a la consola de gestión | IP o subred del dispositivo de copia de seguridad o de recuperación | *.backupdr.googleusercontent.com | 443 |
Para obtener más información sobre cómo configurar esta regla, consulta el artículo Preparar la implementación del servicio Backup and DR.
En el caso de los hosts que ejecuten el agente de Backup and DR, debes añadir manualmente el siguiente puerto TCP para permitir la conectividad con una regla de cortafuegos de entrada.
| Finalidad | Fuente | Objetivo | Puerto (TCP) |
|---|---|---|---|
| Tráfico del agente (del dispositivo al host) | Dispositivo de copia de seguridad o de recuperación | Host que ejecuta el agente de Backup y DR | 5106 |
En el caso de los hosts que usan NFS para el tráfico de copias de seguridad o de los hosts ESX que se ejecutan en VMware Engine y que usan NFS para los montajes, debes añadir manualmente los siguientes puertos TCP y UDP para permitir la conectividad con una regla de cortafuegos de entrada.
| Finalidad | Fuente | Objetivo | Puerto (TCP/UDP) |
|---|---|---|---|
| Copia de seguridad o montaje de NFS | Host que ejecuta el agente o host ESXi que ejecuta el montaje | Dispositivo de copia de seguridad o de recuperación | 111, 756, 2049, 4001, 4045 |
Para ver una lista de los permisos que se usan durante esta operación, consulta la referencia de permisos de instalación de copias de seguridad y recuperación ante desastres.
Regiones disponibles
En la siguiente sección se indican las regiones admitidas para la consola de administración y los dispositivos de copia de seguridad y recuperación.
Regiones admitidas en la consola de administración
Aunque el servicio de copia de seguridad y recuperación ante desastres se puede usar para crear copias de seguridad de las cargas de trabajo admitidas en cualquier región deGoogle Cloud , la consola de gestión solo se puede activar en las siguientes regiones:
| Zona geográfica | Nombre de la región | Descripción de la región | |
|---|---|---|---|
| Norteamérica | |||
northamerica-northeast1 * |
Montreal |
 CO2 bajo
|
|
northamerica-northeast2 |
Toronto |
CO2 bajo
|
|
us-central1 |
Iowa |
CO2 bajo
|
|
us-east1 |
Carolina del Sur | ||
us-east4 |
Virginia del Norte | ||
us-east5 |
Columbus | ||
us-south1 |
Dallas |
CO2 bajo
|
|
us-west1 |
Oregón |
CO2 bajo |
|
us-west2 |
Los Ángeles | ||
us-west3 |
Salt Lake City | ||
us-west4 |
Las Vegas | ||
northamerica-south1 * |
Querétaro | ||
| Sudamérica | |||
southamerica-east1 |
São Paulo |
CO2 bajo
|
|
southamerica-west1 |
Santiago |
CO2 bajo
|
|
| Europa | |||
europe-central2 |
Varsovia | ||
europe-north1 |
Finlandia |
CO2 bajo
|
|
europe-southwest1 |
Madrid |
CO2 bajo
|
|
europe-west1 |
Bélgica |
CO2 bajo
|
|
europe-west2 |
Londres |
CO2 bajo
|
|
europe-west3 |
Fráncfort | ||
europe-west4 |
Países Bajos |
CO2 bajo
|
|
europe-west6 |
Zúrich |
CO2 bajo
|
|
europe-west8 |
Milán | ||
europe-west9 |
París |
CO2 bajo
|
|
europe-west10 |
Berlín |
CO2 bajo
|
|
europe-west12 |
Turín | ||
| Oriente Medio | |||
me-central1 |
Doha | ||
me-central2 |
Dammam | ||
me-west1 |
Israel | ||
| África | |||
africa-south1 |
Johannesburgo | ||
| Asia‑Pacífico | |||
asia-east1 |
Taiwán | ||
asia-east2 |
Hong Kong | ||
asia-northeast1 |
Tokio | ||
asia-northeast2 * |
Osaka | ||
asia-northeast3 |
Seúl | ||
asia-southeast1 |
Singapur | ||
asia-southeast2 |
Yakarta | ||
australia-southeast1 |
Sídney | ||
australia-southeast2 |
Melbourne | ||
| India | |||
asia-south1 |
Bombay | ||
asia-south2 |
Deli |
* Querétaro, Montreal y Osaka tienen tres zonas alojadas en uno o dos centros de datos físicos. En el caso poco probable de que se produzca un desastre, los datos almacenados en estas regiones pueden perderse.
Regiones admitidas para dispositivos de copia de seguridad o de recuperación
Los dispositivos de copia de seguridad o recuperación se pueden implementar en cualquier Google Cloud zona.
El servicio de flujo de trabajo para llevar a cabo la implementación del dispositivo de copia de seguridad o recuperación está disponible en las regiones indicadas. Si el servicio Workflow no está disponible en una región en la que se haya implementado tu dispositivo de copia de seguridad o recuperación, el servicio Backup and DR ejecutará el flujo de trabajo de forma predeterminada en la región us-central1 (el dispositivo se creará en la región que hayas seleccionado). Si tienes una política de organización configurada para impedir la creación de recursos en otras regiones, debes actualizarla temporalmente para permitir la creación de recursos en la región us-central1. Puedes restringir la región de us-central1
después de implementar el dispositivo de copia de seguridad o recuperación.