En esta página, se describe cómo realizar la activación inicial del servicio de copia de seguridad y DR y configurar parámetros para tu proyecto.
Componentes de la arquitectura de Backup and DR
La arquitectura del servicio de copia de seguridad y DR se entrega a través de los siguientes componentes:
Consola de administración: La consola de administración funciona como el plano de administración de 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 o recuperación. La consola de administración se implementa en el proyecto de administración de copias de seguridad y tiene alta disponibilidad dentro de la región implementada, lo que garantiza la resiliencia contra las interrupciones zonales.
Dispositivos de copia de seguridad o recuperación: El dispositivo de copia de seguridad o recuperación es el agente de migración 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 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 el conocimiento 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 copia de seguridad y DR.
La consola de administración se activa en una red de VPC de productor de servicios. Esta VPC del productor de servicios se comunica con tu proyecto a través del acceso privado a Google.
Consideraciones sobre la implementación
A continuación, se presentan algunas consideraciones importantes que afectan la forma en que implementas el servicio de copia de seguridad y 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 negocio. Esta puede ser una forma más eficiente de administrar las copias de seguridad, ya que solo debes administrar una sola consola de administración.
- La administración de copias de seguridad descentralizada 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 prepararte ante un desastre en una región de producción, o es suficiente con proteger tus datos de forma local? Si necesitas la capacidad de recuperación ante desastres, debes considerar las copias de seguridad entre regiones. Esto significa almacenar tus copias de seguridad en varias ubicaciones, de modo que, si una ubicación se ve afectada por un desastre, aún se pueda acceder a tus datos.
Las cargas de trabajo se encuentran en una sola región
La mejor estrategia de copia de seguridad dentro de una región depende de tus necesidades.
Si no necesitas la recuperación ante desastres (DR)
Para obtener el rendimiento más rápido y un costo más bajo, 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 tus 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 una región diferente o usar el almacenamiento dual o multirregional. Almacenar copias de seguridad en una región diferente genera cargos de red y almacenamiento.
Si necesitas copia de seguridad y DR
Para obtener el rendimiento más rápido y un costo más bajo, 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 de antemano 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 DR recuperación ante desastres, o usa el almacenamiento dual o multirregional. La copia de seguridad de la región de producción puede satisfacer las necesidades de copia 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
La mejor estrategia de copia de seguridad en todas las regiones depende de tus necesidades.
Si no necesitas la recuperación ante desastres (DR)
Para obtener el rendimiento más rápido y un costo más bajo, implementa la consola de administración en una de las regiones en las que se ejecutan tus cargas de trabajo. Esto permite una administración centralizada en todas las cargas de trabajo y regiones.
Implementa uno o más dispositivos de copia de seguridad o recuperación en cada región donde se ejecutan 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 una región diferente o usar el almacenamiento dual o multirregional. Almacenar copias de seguridad en una región o multirregión diferente genera cargos de red y almacenamiento.
Si necesitas copia de seguridad y DR
Implementa una consola de administración en cada una de las regiones de cargas 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 cargas 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 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 DR, o usa el almacenamiento multirregional o birregional. 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 copia de seguridad en la DR para recuperar cargas de trabajo si la región de producción está inactiva.
Cómo configurar el servicio de copia de seguridad y 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:
Cómo activar la copia de seguridad y DR de Google Cloud
Tipos de dispositivos de copia de seguridad y recuperación
El servicio de copia de seguridad y DR proporciona tipos de dispositivos optimizados para diferentes cargas de trabajo, como VMs de Compute Engine, VMs 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 de forma continua para siempre, siempre listo para ejecutar y volver a ejecutar copias de seguridad, restablecimientos y otras tareas 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 el 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 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 e2-standard-16. Este dispositivo puede administrar hasta 1,500 aplicaciones. Puedes elegir cualquiera de los siguientes tipos de discos para almacenar tus datos.
- Disco persistente de capacidad mínima: Esta opción proporciona una capacidad mínima de disco 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 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 la 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, las bases de datos o las 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 la capacidad mínima del disco.
Cuando implementas un dispositivo, se crea una cuenta de servicio automáticamente 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 de 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 locales:
Disco persistente 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. Esto se recomienda para VMware Engines y 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. Esto se recomienda para las VMs de VMware Engine de Google Cloudy las aplicaciones de base de datos o sistema de archivos con E/S muy altas.
Puedes expandir la capacidad de tus grupos de discos más adelante.
Puedes mover copias de seguridad con necesidades de retención a largo plazo a Google Cloud Standard, Nearline y Coldline según tu necesidad esperada para acceder a los datos.
Topología de red recomendada para el servicio de copia de seguridad y DR
Google Cloud recomienda el uso de VPC compartida durante la implementación del servicio de copia de seguridad y 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 puedan comunicar entre sí de forma segura y eficiente mediante 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 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 del proyecto 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 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 objetivo principal de esta conexión es que la consola de administración y los dispositivos de copia de seguridad o 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 de la VPC compartida
Se recomiendan las siguientes prácticas recomendadas:
Conexión a la consola de administración: Es mejor 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. Aprovisionar la conectividad al servicio de copia de seguridad y 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 copia de seguridad y DR.
Ubicación del dispositivo de copia de seguridad o recuperación: Los dispositivos de copia de seguridad o recuperación deben implementarse 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 de host central: En esta estrategia, el servicio de Backup and DR se considera un servicio central de TI. El equipo central de copias de seguridad rige el aprovisionamiento del servicio. Por lo tanto, todos los dispositivos de copia de seguridad o 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 a equipos distribuidos. En esta situación, la práctica recomendada es aprovisionar la VPC para los proyectos de servicio descendentes. Los dispositivos de copia de seguridad o recuperación se instalan en los proyectos de servicio dentro de estas VPC. Esto permite la colocalización 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 o recuperación pueda comunicarse con APIs, como Compute Engine, Cloud Storage y Cloud Logging, lo que es importante para que funcionen las alertas y la supervisión. 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 o recuperación para permitir conexiones al rango CIDR199.36.153.8/30en el puerto TCP443.
Configuraciones de firewall
Las siguientes reglas de firewall obligatorias para la entrada al servicio de Backup and DR se agregan automáticamente.
| Objetivo | Fuente | Objetivo | Puerto (TCP) |
|---|---|---|---|
| Tráfico de asistencia (compatibilidad con el dispositivo) | Host que ejecuta el cliente SSH | Dispositivo de copia de seguridad o recuperación | 26 |
| Copia de seguridad de iSCSI (host a dispositivo) | Host que ejecuta el agente de Backup and DR | Dispositivo de copia de seguridad o recuperación | 3260 |
| Tráfico de StreamSnap (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 de Copia de seguridad y DR.
Para cualquier host que ejecute el agente de copia de seguridad y 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 (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 copia de seguridad o de los hosts ESX que se ejecutan en VMware Engine y 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) |
|---|---|---|---|
| Activación o copia de seguridad de NFS | Agente que se ejecuta en el host o activación del host de ESXi | 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 y DR.
Regiones admitidas
En la siguiente sección, se enumeran las regiones compatibles con la consola de administración y los dispositivos de copia de seguridad o recuperación.
Regiones admitidas de la Consola del administrador
Si bien el servicio de copia de seguridad y 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. Ten en cuenta que no puedes mover la consola de administración a una región diferente.
| Área geográfica | Nombre de la región | Descripción de la región | |
|---|---|---|---|
| América | |||
us-central1 |
Iowa |
 CO2 bajo
|
|
us-east1 |
Carolina del Sur | ||
us-east4 |
Virginia del Norte | ||
us-east5 |
Columbus | ||
us-west1 |
Oregón |
CO2 bajo |
|
us-west2 |
Los Ángeles | ||
us-west4 |
Las Vegas | ||
southamerica-east1 |
São Paulo |
CO2 bajo
|
|
| Europa | |||
europe-west1 |
Bélgica |
CO2 bajo
|
|
europe-west2 |
Londres |
CO2 bajo
|
|
europe-west3 |
Fráncfort |
CO2 bajo
|
|
europe-west4 |
Países Bajos |
CO2 bajo
|
|
| Asia-Pacífico | |||
asia-east1 |
Taiwán | ||
asia-southeast1 |
Singapur | ||
australia-southeast1 |
Sídney | ||
| India | |||
asia-south1 |
Bombay | ||
asia-south2 |
Delhi |
Regiones admitidas para dispositivos de copia de seguridad y recuperación
Los dispositivos de copia de seguridad y recuperación del servicio de DR 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 es compatible con 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 copia de seguridad y DR ejecutará el flujo de trabajo de forma predeterminada en la región us-central1 (el dispositivo en sí se crea en la región seleccionada). Si tienes una
política de la organización que está configurada para evitar la creación de recursos en otras regiones,
debes actualizar temporalmente la política de la organización para permitir la creación de
recursos en la región us-central1. Puedes restringir la región us-central1 después de la implementación del dispositivo de copia de seguridad o recuperación.