La backup vault es un recurso regional administrado por Google que proporciona almacenamiento aislado, inmutable e imborrable para las copias de seguridad. Organiza los datos en una jerarquía de bóvedas, fuentes de datos y copias de seguridad, lo que protege los datos contra la eliminación accidental o maliciosa a través de períodos de retención aplicados y el aislamiento de identidades a nivel del proyecto.
En este documento, se explica cómo funcionan las backup vaults, incluido el modelo de recursos jerárquico, las cargas de trabajo compatibles, los modelos de copia de seguridad, la compatibilidad de ubicación, la disponibilidad y los requisitos de nombres.
Jerarquía de recursos
Los datos dentro de Backup and DR se organizan en una jerarquía de tres niveles dentro de la backup vault:
Backup vault: Es un contenedor de nivel superior que aplica políticas de retención mínimas globales.
Fuente de datos: Es un recurso secundario que representa una entidad protegida específica (por ejemplo, una instancia de Compute Engine). El sistema lo crea automáticamente cuando se realiza la primera copia de seguridad.
Copia de seguridad: Es un recurso secundario de una fuente de datos que representa una copia de seguridad discreta con un punto de recuperación de un momento determinado específico.
En el siguiente diagrama, se muestra el modelo de recursos de la bóveda de copia de seguridad:
Limitaciones
En esta página, se describen las bóvedas de copias de seguridad para los recursos administrados a través de la consola deGoogle Cloud (como Compute Engine o Cloud SQL). Si usas la consola de administración de dispositivos para cargas de trabajo como Oracle o Google Cloud VMware Engine, consulta Descripción general de los almacenes de copias de seguridad administrados desde la consola de administración de dispositivos.
Los clústeres de AlloyDB y las instancias de Filestore en backup vaults no son compatibles con las multirregiones.
Backup and DR no impone ninguna restricción en las ubicaciones de destino compatibles cuando se restablece una carga de trabajo desde una copia de seguridad de la backup vault.
Es posible que se apliquen tarifas de transferencia de red según las ubicaciones de tu backup vault y la carga de trabajo de origen. Para obtener más información, consulta Precios de Backup and DR.
Recursos admitidos
| Tipo de carga de trabajo | Administración |
|---|---|
| Instancia de Compute Engine | Consola deGoogle Cloud |
| Disco de Compute Engine | Consola deGoogle Cloud |
| Instancia de Filestore | Consola deGoogle Cloud |
| Instancia de Cloud SQL | Consola deGoogle Cloud |
| Clúster de AlloyDB | Consola deGoogle Cloud |
| Google Cloud VMware Engine, base de datos de Oracle y base de datos de SQL Server | Consola de administración del dispositivo |
Modelos de copia de seguridad para recursos
| Modelo centralizado | Modelo descentralizado | |
|---|---|---|
| Google Cloud console | Consolida la administración de copias de seguridad creando backup vaults y planes de copias de seguridad en un proyecto de administrador central. Los administradores pueden usar estos planes administrados de forma centralizada para proteger los recursos en varios proyectos de servicio o usar permisos de IAM para delegar el acceso al plan de copia de seguridad a los propietarios de las aplicaciones. |
Aísla la administración de copias de seguridad creando un backup vault y un plan de copia de seguridad independientes dentro de cada proyecto. Este enfoque es ideal para organizaciones descentralizadas en las que los equipos de aplicaciones individuales son responsables de crear copias de seguridad de sus propios recursos. |
| Consola de administración del dispositivo | Consolida la administración de copias de seguridad implementando la consola de administración de dispositivos y creando backup vaults en un proyecto de administrador central. Los administradores configuran las políticas de copia de seguridad en la consola de administración central para proteger los recursos, como las VMs de Google Cloud VMware Engine, en varios proyectos de servicio. |
Aísla la administración de copias de seguridad implementando una consola de administración de dispositivos y un backup vault independientes para cada proyecto o línea de negocio. Este enfoque es ideal para organizaciones descentralizadas en las que las responsabilidades de administración de copias de seguridad se dividen entre varios equipos. |
Ubicaciones admitidas de la backup vault
Puedes crear una backup vault en la misma región que la carga de trabajo de origen (regional), en una región diferente de la carga de trabajo de origen (interregional) o en varias regiones (multirregional).
Regiones y regiones cruzadas admitidas
Puedes crear backup vaults en las siguientes regiones y regiones cruzadas:
| Á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 |
CO2 bajo
|
|
europe-north1 |
Finlandia |
CO2 bajo
|
|
europe-north2 |
Estocolmo |
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 |
CO2 bajo
|
|
europe-west9 |
París |
CO2 bajo
|
|
europe-west10 |
Berlín | ||
europe-west12 |
Turín |
CO2 bajo
|
|
| 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 (northamerica-south1), Montreal (northamerica-northeast1) y Osaka (asia-northeast2) no admiten la separación de zonas. Esto significa que las múltiples zonas dentro de cada una de estas regiones pueden no estar ubicadas en campus de centros de datos físicamente separados. Por lo tanto, un solo desastre físico localizado podría afectar a varias zonas dentro de la misma región, lo que aumenta el riesgo de pérdida de datos en comparación con las regiones que admiten la separación de zonas.
Multirregiones admitidas
Puedes crear backup vaults en las siguientes multirregiones:
| Nombre de la multirregión | Descripción |
|---|---|
ASIA |
Centros de datos en Asia |
EU |
Centros de datos en la Unión Europea |
US |
Centros de datos en Estados Unidos |
Compatibilidad de la ubicación de la carga de trabajo
En la siguiente tabla, se describen las ubicaciones de las bóvedas de copias de seguridad compatibles para cada carga de trabajo admitida cuando se usan bóvedas de copias de seguridad regionales y entre regiones. Ten en cuenta que los planes de copia de seguridad en la consola de Google Cloud deben crearse en la misma región que la carga de trabajo de origen.
| Carga de trabajo | La backup vault debe estar en la misma región que la carga de trabajo de origen | Asistencia regional | Compatibilidad multirregional | Compatibilidad entre regiones |
|---|---|---|---|---|
| Instancia de Compute Engine | No | |||
| Disco de Compute Engine | No | |||
| Instancia de Cloud SQL | Sí | |||
| Clúster de AlloyDB | Sí | |||
| Instancia de Filestore | No | |||
| Google Cloud VMware Engine, base de datos de Oracle y base de datos de SQL Server | No |
Compatibilidad multirregional
Se deben cumplir los siguientes requisitos para usar multirregiones:
Si una carga de trabajo admite backup vaults multirregionales, la ubicación de la carga de trabajo de origen debe ser compatible con la ubicación de la backup vault multirregional.
Solo puedes crear copias de seguridad de los recursos en las regiones que comparten el mismo prefijo. Por ejemplo, los recursos de las regiones con el prefijo
asiasolo se pueden copiar en la multirregiónasia.
En la siguiente tabla, se describen las ubicaciones de backup vault compatibles para cada carga de trabajo admitida cuando se usan backup vaults multirregionales:
| Tipo de carga de trabajo | ¿Admite el uso de backup vaults multirregionales? | Backup vaults multirregionales compatibles |
|---|---|---|
| Instancia de Compute Engine | asia, eu, us |
|
| Disco de Compute Engine | asia, eu, us |
|
| Instancia de Filestore | N/A | |
| Instancia de Cloud SQL | asia, eu, us |
|
| Clúster de AlloyDB | N/A | |
| Google Cloud VMware Engine, base de datos de Oracle y base de datos de SQL Server | N/A |
Disponibilidad
Las backup vaults creadas en ubicaciones regionales y entre regiones proporcionan resiliencia contra una interrupción en una sola zona. Los datos de la copia de seguridad se almacenan de forma redundante en al menos dos zonas separadas.
Las backup vaults creadas en ubicaciones multirregionales proporcionan resiliencia contra una interrupción en una sola región. Los datos de la copia de seguridad se almacenan de forma redundante en al menos dos regiones independientes.
Compara las backup vaults multirregionales y entre regiones
| Criterios | Copias de seguridad multirregionales | Copias de seguridad entre regiones |
|---|---|---|
| Creación de copias de seguridad | Automatizada por Google en dos regiones de un continente. | Autonomía para definir de forma explícita una región en la que se creará la copia de seguridad |
| Caso de uso | Alta disponibilidad y simplicidad operativa | Cumplimiento estricto, leyes de residencia de datos o sitios de recuperación ante desastres específicos, dentro y fuera de los límites regionales de origen. |
| Administración | Baja sobrecarga Bóveda única, balanceo automatizado | Sobrecarga media. Requiere configurar una vinculación de destino específica. |
| Claves de encriptación administradas por el cliente (CMEK) | La backup vault multirregional debe usar la CMEK de la misma región que la backup vault. | La backup vault interregional debe usar la CMEK de la misma región que la backup vault. |
| Implicaciones de costos | Cargo por carga y descarga multirregional, cuando corresponda. Cargo por almacenamiento de copias de seguridad para la backup vault multirregional. Cargo por administración. | Cargos por transferencia de datos entre regiones. Cargo por almacenamiento de copias de seguridad. Cargo por administración. |
| Cargas de trabajo admitidas |
|
|
Nombres de backup vaults
Los nombres de tus almacenes de copias de seguridad deben cumplir con los siguientes requisitos:
Los nombres de las bóvedas de copias de seguridad solo pueden contener letras en minúscula, caracteres numéricos y guiones (
-). No se permiten espacios.Los nombres de las backup vaults deben comenzar y terminar con un número o una letra.
Los nombres de las backup vaults deben contener entre 3 y 63 caracteres. Los nombres con puntos pueden tener hasta 222 caracteres, pero cada componente separado por un punto no puede tener más de 63 caracteres.
Los nombres de los backup vaults no se pueden representar como una dirección IP en notación decimal punteada. Por ejemplo,
192.0.2.255.
Evitar la eliminación de la copia de seguridad
Para proteger tus datos de la eliminación accidental o maliciosa, tú (el administrador) configuras un período de retención obligatorio para tu backup vault. Una vez configuradas, las copias de seguridad son completamente inmutables: ni tú, ni ningún otro usuario, ni Google pueden borrarlas de forma manual hasta que haya transcurrido la duración especificada.
Puedes controlar la retención aplicada con tres parámetros de configuración principales de Vault:
- Retención mínima aplicada: Cuando creas una bóveda, debes establecer un período de retención de referencia (entre 1 día y 99 años). Esto crea un precio mínimo obligatorio para toda la bóveda:
No se puede borrar ninguna copia de seguridad antes de que transcurra este tiempo. Cualquier plan de copia de seguridad que almacene datos en esta vault debe tener un período de retención de copias de seguridad igual o superior a este mínimo.
Heredar la retención de la regla de copia de seguridad: En lugar de depender únicamente del mínimo de referencia de la vault, puedes configurarla para que adopte el período de retención exacto definido en tus planes de copia de seguridad específicos. Debes habilitar este parámetro de configuración durante la creación de la vault.
Si el mínimo de tu vault es de 3 días, pero la retención de tu plan de copia de seguridad es de 7 días, la copia de seguridad se bloqueará durante los 7 días completos. Resultado: Se evita por completo la eliminación manual. Las copias de seguridad solo se borran automáticamente una vez que vence la duración específica del plan de copia de seguridad.
Bloquea el período de retención aplicado: Para cumplir con requisitos de cumplimiento estrictos, puedes bloquear de forma permanente la configuración de retención mínima aplicada.
Cuando estableces un bloqueo, seleccionas una fecha de entrada en vigencia. Antes de la fecha de entrada en vigencia, puedes ajustar el período de retención mínimo hacia arriba o hacia abajo para corregir errores. Después de la fecha de entrada en vigencia, nadie (ni siquiera un propietario del proyecto) puede disminuir el período de retención. Solo puedes aumentarla.
Restricción de acceso a la backup vault
La configuración de restricciones de acceso de una backup vault te permite controlar las fuentes desde las que se pueden crear copias de seguridad de los datos o restablecerlos desde una backup vault. Este parámetro de configuración determina los tipos de recursos que puedes almacenar en una backup vault.
Puedes seleccionar uno de los siguientes parámetros de configuración de restricción de acceso para una bóveda de copia de seguridad. Ten en cuenta que este parámetro de configuración es permanente y no se puede cambiar.
Restringir el acceso a la organización actual: Las operaciones de copia de seguridad y restablecimiento solo se admiten dentro de tu organización actual. Esta selección hace que la bóveda de copias de seguridad sea compatible con los recursos administrados a través de la consola de Google Cloud , como las instancias de Compute Engine, pero no con los recursos administrados a través de la consola de administración del dispositivo.
Restringir el acceso al proyecto actual: Las operaciones de copia de seguridad y restablecimiento solo se admiten en tu proyecto actual. Esta selección hace que la bóveda de copia de seguridad sea compatible con los recursos administrados a través de la consola deGoogle Cloud (por ejemplo, las instancias de Compute Engine), pero no con los recursos administrados a través de la consola de administración del dispositivo.
Restringir el acceso a la organización actual y permitir el acceso sin restricciones a los dispositivos de copia de seguridad: Para los recursos administrados a través de la consola de Google Cloud , las operaciones de copia de seguridad y restablecimiento solo se admiten dentro de tu organización actual. También se admiten los recursos administrados a través de la consola de administración del dispositivo (por ejemplo, las VMs de Google Cloud VMware Engine), pero las operaciones de copia de seguridad y restablecimiento de esos recursos no se restringen a tu organización actual. Esta selección hace que la bóveda de copias de seguridad sea compatible con los recursos administrados a través de la consola deGoogle Cloud y con los recursos administrados a través de la consola de administración del dispositivo.
Permitir acceso sin restricciones: Permite operaciones de copia de seguridad y restablecimiento desde o hacia cualquier proyecto u organización. Esta selección hace que la backup vault sea compatible con los recursos administrados a través de la consola de Google Cloud y con los recursos administrados a través de la consola de administración del dispositivo.
Encriptación
De forma predeterminada, Google Cloud encripta los datos de forma automática cuando están en reposo con Google-owned and Google-managed encryption keys. Si tienes requisitos normativos o de cumplimiento específicos relacionados con las claves que protegen tus datos, puedes usar claves de encriptación administradas por el cliente (CMEK) para tus copias de seguridad. Consulta Claves de encriptación administradas por el cliente (CMEK).
¿Qué sigue?
- Automatiza la protección de las instancias de Compute Engine
- Crea y administra una backup vault en la consola de Google Cloud
- Crea copias de seguridad de discos en un backup vault