En esta página, se describe cómo realizar la activación inicial del servicio de Backup and DR y configurar tu proyecto.
Componentes de la arquitectura de Backup and DR
La arquitectura del servicio Backup and DR se entrega a través de los siguientes componentes:
Consola de administración: La consola de administración actúa como plano de administración para tus dispositivos de copia de seguridad o recuperación. Cada implementación de Backup and DR incluye una sola consola de administración que administra cualquier cantidad de dispositivos de copia de seguridad y recuperación. La consola de administración se implementa en el proyecto de administración de copias de seguridad y tiene alta disponibilidad en la región implementada, lo que proporciona resiliencia ante las interrupciones zonales.
Dispositivos de copia de seguridad o recuperación: El dispositivo de copia de seguridad o recuperación es el migrador de datos que captura, mueve y administra de manera eficiente el ciclo de vida de los datos de copia de seguridad dentro de tu empresa. Los dispositivos de copia de seguridad o recuperación se implementan en la entidad de carga de trabajo para las cargas de trabajo en la nube.
Agentes de Backup and DR: El agente de Backup and DR llama a las APIs nativas de la aplicación para capturar datos de manera eficiente de las aplicaciones de producción de forma incremental y proporciona la información de la aplicación en el momento de la recuperación. El agente se instala en los hosts de aplicaciones en los que residen las aplicaciones que se protegerán. Si solo proteges toda la VM o un subconjunto de sus discos, no se requiere el agente de Backup and DR.
La consola de administración se activa en una red de VPC del productor de servicios. La VPC de este productor de servicios se comunica con tu proyecto a través del Acceso privado a Google.
La comunicación entre el servidor de administración y los dispositivos, entre los dispositivos y entre los dispositivos y los agentes del host está protegida por la autenticación TLS mutua.
Consideraciones sobre la implementación
A continuación, se incluyen algunas consideraciones importantes que afectan la forma en que implementas el servicio Backup and DR:
¿Cuáles son los requisitos de objetivo de tiempo de recuperación (RTO) de tu organización? El RTO es la cantidad máxima de tiempo 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 administración de tus copias de seguridad? Debes decidir si deseas administrar tus copias de seguridad de forma centralizada o no.
- La administración centralizada de copias de seguridad significa que tienes una sola consola de administración para administrar las copias de seguridad de todas tus cargas de trabajo en todas las líneas de negocios. Esta puede ser una forma más eficiente de administrar las copias de seguridad, ya que solo necesitas administrar una sola consola de administración.
- La administración descentralizada de copias de seguridad significa que tienes una consola de administración independiente para cada línea de negocio. El modo de operación varía de una organización a otra.
¿Cuál es tu caso de uso de copia de seguridad? ¿Necesitas copias de seguridad para estar preparado ante la recuperación ante desastres en caso de que ocurra un desastre en una región de producción, o es suficiente con proteger tus datos de forma local? Si necesitas capacidad de recuperación ante desastres, debes considerar las copias de seguridad entre regiones. Esto significa almacenar tus copias de seguridad en varias ubicaciones para que, si una ubicación se ve afectada por un desastre, aún puedas acceder a tus datos.
Las cargas de trabajo se encuentran en una sola región
Tu mejor estrategia de copias de seguridad dentro de una región depende de tus necesidades.
Si no necesitas recuperación ante desastres (DR)
Para obtener el mejor rendimiento y un menor costo, implementa la consola de administración y los dispositivos de copia de seguridad o recuperación en la misma región en la que se ejecutan tus cargas de trabajo. Almacena las imágenes de copia de seguridad en la misma región que tus cargas de trabajo.
Si también quieres tener copias de seguridad fuera del sitio, puedes almacenarlas en otra región o usar almacenamiento birregional o multirregional. Almacenar copias de seguridad en una región diferente genera cargos de red y almacenamiento.
Si necesitas una copia de seguridad y una DR
Para obtener el mejor rendimiento y el menor costo, implementa una consola de administración en la misma región que la región de la carga de trabajo de producción y una segunda consola de administración en la región que puedes usar para la recuperación ante desastres.
Implementa dispositivos de copia de seguridad o recuperación en la región de la carga de trabajo de producción y en la región de DR para minimizar el objetivo de tiempo de recuperación (RTO). Esto garantiza que un entorno de DR esté completamente aprovisionado previamente y disponible en caso de desastre.
Almacena imágenes de copias de seguridad en la región de producción y una copia en la región de recuperación ante desastres (DR), o bien usa almacenamiento birregional o multirregional. La copia de seguridad de la región de producción puede satisfacer las necesidades de copias de seguridad de rutina con un rendimiento más rápido. Los datos copiados en tu región de DR 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 se encuentran en varias regiones
Tu mejor estrategia de copias de seguridad en todas las regiones depende de tus necesidades.
Si no necesitas recuperación ante desastres (DR)
Para obtener el mejor rendimiento y un menor costo, implementa la consola de administración en una de las regiones en las que se ejecutan tus cargas de trabajo. Esto permite la administración centralizada en todas las cargas de trabajo y regiones.
Implementa uno o más dispositivos de recuperación o copia de seguridad 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 fuera del sitio, puedes almacenarlas en otra región o usar almacenamiento birregional o multirregional. Almacenar copias de seguridad en una región o multirregión diferente genera cargos de red y almacenamiento.
Si necesitas tanto una copia de seguridad como una DR
Implementa una consola de administración en cada una de las regiones de la carga de trabajo de producción y otra consola de administración en la región de DR.
Implementa dispositivos de copia de seguridad o recuperación en las regiones de carga de trabajo de producción y en la región de DR para minimizar el objetivo de tiempo de recuperación (RTO). Esto garantiza que un entorno de DR esté completamente aprovisionado previamente y disponible en caso de desastre.
Almacena copias de seguridad en la región de la carga de trabajo de producción y una copia en la región de DR, o bien usa almacenamiento birregional o multirregional. La copia de seguridad de la región de producción se puede usar para satisfacer las necesidades de copias de seguridad.
Se puede usar una imagen de copia de seguridad en la DR para recuperar cargas de trabajo si la región de producción está inactiva.
Configura el servicio Backup and DR en la consola de Google Cloud
Ve a la consola de Google Cloud para activar la API de Backup and DR Service y configurar los permisos de tu cuenta:
Activa Backup and DR de Google Cloud
Tipos de dispositivos de copia de seguridad y recuperación
El servicio de Backup and DR proporciona tipos de dispositivos optimizados para diferentes cargas de trabajo: VMs de Compute Engine, VMs de VMware, bases de datos y sistemas de archivos. Puedes elegir el tipo de electrodoméstico 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 y recuperación está en servicio, se ejecuta de forma continua y permanente, y siempre está listo para ejecutar y volver a ejecutar copias de seguridad, restablecimientos y otros trabajos en todo momento.
El servicio Backup and DR proporciona los siguientes tipos de dispositivos:
- Estándar para VMs de Compute Engine o bases de datos de SAP HANA: Selecciona esta opción si deseas crear copias de seguridad solo de instancias de Compute Engine o bases de datos de SAP HANA con Persistent Disk. De forma predeterminada, este dispositivo agrega un tipo de máquina e2-standard-4 con una capacidad mínima de Persistent Disk de 10 GB. Este dispositivo puede administrar hasta 5,000 VMs de Compute Engine.
- Estándar para VMs de VMware y otras bases de datos o recursos: Selecciona esta opción si deseas 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 agrega un tipo de máquina n2-standard-16. Esto agrega 4 TB de capacidad de disco equilibrada como la capacidad mínima del disco. Este dispositivo puede administrar hasta 1,500 aplicaciones.
Básico para VMs de VMware y otras bases de datos o recursos: Selecciona esta opción si deseas tener una configuración básica que admita un rendimiento moderado para realizar copias de seguridad de bases de datos, VMs de VMware y otros recursos. De forma predeterminada, este dispositivo agrega un tipo de máquina e2-standard-16. Este dispositivo puede administrar hasta 1,500 aplicaciones. Puedes elegir cualquiera de los siguientes tipos de discos para almacenar tus datos.
- Persistent Disk de capacidad mínima: Esta opción proporciona una capacidad de disco mínima de 10 GB. En este tipo de almacenamiento, las copias de seguridad se almacenan como instantáneas de Persistent Disk 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 deseas tener un almacenamiento en bloque eficiente. Se recomienda para las VMs de Google Cloud VMware Engine, las bases de datos o las aplicaciones de sistemas de archivos con E/S de nivel medio a alto, además de las VMs de Compute Engine. Esto agrega 4 TB de capacidad de Persistent Disk como capacidad mínima del disco.
- Disco persistente SSD: Selecciona este tipo de almacenamiento si deseas tener un almacenamiento en bloque rápido. Se recomienda para Google Cloud VMware Engine, bases de datos o aplicaciones de sistemas de archivos con E/S muy altas, además de las VMs de Compute Engine. Esto agrega 4 TB de capacidad 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 electrónico my-service-account@my-project.iam.gserviceaccount.com, en el que appliance-name es el nombre de un dispositivo y projectid es el ID de tu proyecto Google Cloud .
Elige 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 la retención a largo plazo.Google Cloud ofrece los siguientes tres tipos de almacenamiento de objetos local:
Persistent Disk de 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 almacenamiento en bloque eficiente, a partir de un Persistent Disk de 4 TB. Se recomienda para los VMware Engines y las aplicaciones de bases de datos o sistemas de archivos con E/S de nivel medio a alto.
Disco persistente SSD: Este tipo de almacenamiento ofrece almacenamiento en bloque rápido, a partir de un Persistent Disk de 4 TB. Se recomienda para las VMs de Google CloudVMware Engine y las aplicaciones de bases de datos o sistemas de archivos con E/S muy altas.
Puedes expandir la capacidad de tus grupos de discos más adelante.
Puedes mover las copias de seguridad con necesidades de retención a largo plazo al almacenamiento Google Cloud Estándar, Nearline y Coldline según la necesidad esperada de acceder a los datos.
Topología de red recomendada para el servicio Backup and DR
Google Cloud recomienda usar la VPC compartida cuando se implementa el servicio Backup and DR. La VPC compartida permite que una organización conecte recursos de varios proyectos a una red de VPC (VPC) común para que se comuniquen entre sí de manera segura y eficiente a través de las IP internas de esa red. Cuando usas una VPC compartida, debes designar un proyecto como host y conectarle uno o más proyectos de servicio. Las redes de VPC en el proyecto host se conocen como redes de VPC compartida. Los recursos aptos de los proyectos de servicio pueden usar subredes en la red de VPC compartida.
La VPC compartida permite que los administradores de la organización deleguen responsabilidades administrativas, como crear y administrar instancias, a los administradores de proyectos de servicio, mientras mantienen un control centralizado sobre los recursos de red, como subredes, rutas y firewalls.
La consola de administración se activa en una VPC de la red de VPC del productor de servicios. Esta VPC del productor de servicios se comunica con tu proyecto a través del Acceso privado a Google. El propósito principal de esta conexión es que la consola de administración y los dispositivos de copia de seguridad y recuperación intercambien metadatos. El tráfico de copia de seguridad no atraviesa este vínculo. Sin embargo, una consola de administración debe comunicarse con todos los dispositivos de copia de seguridad o recuperación implementados en cualquier red.
Prácticas recomendadas para la VPC compartida
Sigue estas prácticas recomendadas:
Conexión a la consola de administración: Lo mejor es conectar la red del proveedor de servicios a una VPC compartida dentro de tu red. Todo el tráfico de la consola de administración fluye a través de esta VPC y, por lo tanto, a través del proyecto host. El aprovisionamiento de la conectividad al servicio de Backup and DR a través de una VPC compartida también permite una conexión fluida entre los proyectos en los que se ejecutan las cargas de trabajo (proyectos de servicio) y el servicio de Backup and DR.
Ubicación del dispositivo de copia de seguridad o recuperación: Los dispositivos de copia de seguridad o recuperación se deben implementar en una subred que tenga habilitado el Acceso privado a Google para la conectividad con la consola de administración. Existen dos estrategias recomendadas para seleccionar los proyectos de los dispositivos de copia de seguridad y recuperación:
En el proyecto host central: En esta estrategia, el servicio Backup and DR se considera un servicio central del departamento de TI. El equipo central de copias de seguridad rige el 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 que los administradores centrales consoliden todos los recursos de copia de seguridad en un proyecto central. Este enfoque tiene el beneficio 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 administración se delega en equipos distribuidos. En esta situación, la práctica recomendada es aprovisionar la VPC para los proyectos de servicio de nivel inferior. Los dispositivos de copia de seguridad o recuperación se instalan en los proyectos de servicio dentro 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 solo proyecto.
Acceso privado a Google: Se recomienda habilitar el acceso privado a Google para cada subred en la que instales un dispositivo de copia de seguridad o recuperación. Esto garantiza que el dispositivo de copia de seguridad y recuperación pueda comunicarse con las APIs, como Compute Engine, Cloud Storage y Cloud Logging, lo que es importante para que funcionen la supervisión y las alertas. Para simplificar y mejorar las conexiones a las APIs de Google Cloud , considera configurar la resolución de DNS para
private.googleapis.comcomo se documenta en la sección Resumen de las opciones de configuración. Además, configura las reglas de firewall de los dispositivos de copia de seguridad y recuperación para permitir conexiones al rango de CIDR199.36.153.8/30en el puerto TCP443.
Configuraciones de firewall
Las siguientes reglas de firewall obligatorias para la entrada en el servicio de Backup and DR se agregan automáticamente.
| Objetivo | Fuente | Objetivo | Puerto (TCP) |
|---|---|---|---|
| Tráfico de asistencia (asistencia al dispositivo) | Host que ejecuta el cliente SSH | Dispositivo de copia de seguridad o recuperación | 26 |
| Copia de seguridad de iSCSI (del host al dispositivo) | Host que ejecuta el agente de Backup and DR | Dispositivo de copia de seguridad o recuperación | 3260 |
| Tráfico de StreamSnap (de dispositivo a dispositivo) | Dispositivo de copia de seguridad o recuperación | Dispositivo de copia de seguridad o recuperación | 5107 |
| Conectividad del dispositivo de copia de seguridad o recuperación a la consola de administración | IP o subred del dispositivo de copia de seguridad o recuperación | *.backupdr.googleusercontent.com | 443 |
Para obtener más detalles sobre cómo configurar esta regla, consulta Prepárate para implementar el servicio Backup and DR.
Para cualquier host que ejecute el agente de Backup and DR, debes agregar manualmente el siguiente puerto TCP para permitir la conectividad con una regla de firewall de entrada.
| Objetivo | Fuente | Objetivo | Puerto (TCP) |
|---|---|---|---|
| Tráfico del agente (del dispositivo al host) | Dispositivo de copia de seguridad o recuperación | Host que ejecuta el agente de Backup and 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 las activaciones, debes agregar manualmente los siguientes puertos TCP y UDP para permitir la conectividad con una regla de firewall de entrada.
| Objetivo | Fuente | Objetivo | Puerto (TCP/UDP) |
|---|---|---|---|
| Copia de seguridad o activación de NFS | Host que ejecuta el agente o host ESXi que ejecuta el montaje | Dispositivo de copia de seguridad o recuperación | 111, 756, 2049, 4001, 4045 |
Para obtener una lista de los permisos que se usan durante esta operación, consulta la referencia de permisos de instalación de Backup and DR.
Regiones admitidas
En la siguiente sección, se enumeran las regiones admitidas para la consola de administración y los dispositivos de copia de seguridad o recuperación.
Regiones admitidas por la consola de administración
Si bien el servicio Backup and DR se puede usar para crear copias de seguridad de cargas de trabajo compatibles en cualquier región deGoogle Cloud , la consola de administración solo se puede activar en las siguientes regiones:
| Área 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 |
CO2 bajo
|
|
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 |
Delhi |
* Querétaro, Montreal y Osaka tienen tres zonas alojadas en uno o dos centros de datos físicos. En el caso poco probable de un desastre, se pueden perder los datos almacenados en estas regiones.
Regiones admitidas para el dispositivo de copia de seguridad y 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 realizar la implementación del dispositivo de copia de seguridad o recuperación se admite en las regiones que se indican. Si el servicio de Workflow no está disponible en una región en la que se implementó tu dispositivo de copia de seguridad o recuperación, el servicio de Backup and DR ejecutará el flujo de trabajo de forma predeterminada en la región de us-central1 (el dispositivo en sí se creará en la región que seleccionaste). Si tienes una política de la organización configurada para evitar 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.