Precios del servicio de copias de seguridad y DR
En este documento se detallan los precios de Cloud Copia de seguridad y DR.
Información general
El servicio de copia de seguridad y recuperación tras fallos ofrece un modelo de facturación basado en el consumo basado en los siguientes componentes:
Cargo por el almacenamiento de las copias de seguridad. La cantidad de almacenamiento que consumen las imágenes de copia de seguridad.
Cargo por el uso de las copias de seguridad. Cantidad de uso de la orquestación y gestión de copias de seguridad.
Cargo por el almacenamiento de las copias de seguridad
El servicio de copia de seguridad y recuperación tras fallos permite a los usuarios aprovechar toda la riqueza de las ofertas de Cloud Storage para ajustarse al almacenamiento de copias de seguridad en función de la importancia de la carga de trabajo que se protege.
El servicio de copia de seguridad y DR es compatible con el almacenamiento de disco persistente, el almacenamiento estándar, el almacenamiento Nearline, el almacenamiento en frío y el almacenamiento de archivo. Pagas por la cantidad de almacenamiento que consumen las imágenes de copia de seguridad en cada tipo de almacenamiento. Para obtener más información sobre los precios de Cloud Storage, consulta la página correspondiente.
Cargo del dispositivo de copia de seguridad o recuperación
El dispositivo de copia de seguridad/recuperación se ejecuta en una máquina virtual de instancia de computación que se ejecuta en un proyecto seleccionado por el cliente y se aplican los cargos por instancia de Compute Engine estándar. El servicio de copia de seguridad y DR es compatible con los tipos de máquinas de Compute Engine que se indican en la sección sobre cómo configurar y planificar un despliegue del servicio de copia de seguridad y recuperación tras fallos.
Cargo por el uso de copias de seguridad
Cada proyecto de Google Cloud tiene una cuenta de facturación que se utiliza para definir quién paga por el uso de los recursos y las APIs de Google Cloud en ese proyecto. Cuando se activa el servicio de copia de seguridad y recuperación tras fallos en un proyecto, el uso de los cuatro SKUs detallados abajo se facturará a ese proyecto. Esto ocurre independientemente de las zonas o los proyectos en los que se encuentren los dispositivos de copia de seguridad/recuperación.
En la siguiente tabla se muestran los SKUs y los precios cuando usas las funciones de copia de seguridad y recuperación tras fallos.
| Productos/SKUs - Copia de seguridad | Modelo de precios | Meter | Lista de precios |
|---|---|---|---|
| Datos de máquinas virtuales: máquinas virtuales de Compute Engine, máquinas virtuales on-premise y sistemas de archivos | Basado en el uso | Por GiB al mes de capacidad de origen (frontend) con protección | 0,03 USD/GiB al mes |
| SAP HANA, Oracle, SAP ASE, SAP IQ, SAP MaxDB, IBM Db2 | Basado en el uso | Por GiB al mes de capacidad de origen (frontend) con protección | 0,24 USD/GiB al mes |
| Microsoft SQL Server, MySQL, PostgreSQL, MongoDB y MariaDB | Basado en el uso | Por GiB al mes de capacidad de origen (frontend) con protección | 0,09 USD/GiB al mes |
| Copias virtuales (gestión de datos de prueba) | Basado en el uso | Por GiB al mes de la capacidad total clonada virtual | 0,03 USD/GiB al mes |
1 Incluye situaciones en las que se utilizan montajes virtuales para hacer pruebas o restauraciones de copias de seguridad.
Los precios de las copias de seguridad de VMware Engine de Google Cloud se basan en el consumo y en los plazos de compromiso. Entre las opciones se incluyen descuentos bajo demanda o descuentos por compromiso de uso durante periodos de 1 o 3 años.
En la siguiente tabla se enumeran los SKUs y los precios para proteger los nodos ve1-standard-72 de VMware Engine de Google Cloud y los nodos de solo almacenamiento ve1-standard-72.
| Productos/SKUs - Copia de seguridad | Modelo de precios | Meter | Zona o país | Ubicación | Precio según catálogo (bajo demanda) | Compromiso de 1 año (pagos mensuales en USD) | Compromiso de 1 año (pago inicial en USD) | Compromiso de 3 años (pagos mensuales en USD) | Compromiso de 3 años (pago inicial en USD) |
|---|---|---|---|---|---|---|---|---|---|
| Datos de máquinas virtuales: VMware Engine de Google Cloud | Basado en nodos | hora por nodo | asia‑northeast1 | Tokio | 0,53 € | 0,40 USD | 0,37 USD | 0,30 USD | 0,27 USD |
| Basado en nodos | hora por nodo | asia‑south1 | Bombay | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | asia‑southeast1 | Singapur | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | australia‑southeast1 | Sídney | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | europe‑west2 | Londres | 0,53 € | 0,40 USD | 0,37 USD | 0,31 USD | 0,27 USD | |
| Basado en nodos | hora por nodo | europe‑west3 | Fráncfort | 0,53 € | 0,40 USD | 0,37 USD | 0,31 USD | 0,27 USD | |
| Basado en nodos | hora por nodo | europe‑west4 | Países Bajos | 0,53 € | 0,40 USD | 0,37 USD | 0,31 USD | 0,27 USD | |
| Basado en nodos | hora por nodo | europe-west6 | Zúrich | 0,58 USD | 0,44 USD | 0,40 USD | 0,33 USD | 0,29 USD | |
| Basado en nodos | hora por nodo | europe‐west8 | Milán | 0,54 $ | 0,41 € | 0,38 € | 0,31 USD | 0,27 USD | |
| Basado en nodos | hora por nodo | northamerica‑northeast1 | Montreal, Qubec, Norteamérica | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | northamerica-northeast2 | Toronto (Ontario, Norteamérica) | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | southamerica-east1 | Sao Paulo | 0,66 USD | 0,50 USD | 0,46 USD | 0,38 € | 0,33 USD | |
| Basado en nodos | hora por nodo | us-central1 | Council Buffs (Iowa, Norteamérica) | 0,46 USD | 0,35 USD | 0,33 USD | 0,27 USD | 0,23 USD | |
| Basado en nodos | hora por nodo | us‑east4 | Ashburn | 0,46 USD | 0,35 USD | 0,33 USD | 0,27 USD | 0,23 USD | |
| Basado en nodos | hora por nodo | us‑west2 | Los Ángeles | 0,50 USD | 0,38 € | 0,35 USD | 0,29 USD | 0,25 USD | |
| Basado en nodos | hora por nodo | southamerica-west1 | Santiago | 0,64 USD | 0,48 USD | 0,45 USD | 0,37 USD | 0,32 USD | |
| Basado en nodos | hora por nodo | asia‑south2 | Deli | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | yo-west-1 | Tel Aviv | 0,51 € | 0,39 USD | 0,36 USD | 0,29 USD | 0,26 USD | |
| Basado en nodos | hora por nodo | europe‐west‐12 | Turín | 0,54 $ | 0,41 € | 0,38 € | 0,31 USD | 0,27 USD |
¿Cómo se mide el uso de Copia de seguridad y DR?
Las copias de seguridad y la recuperación tras fallos miden el uso en función del tamaño real de la carga de trabajo en el frontend o de la carga de trabajo que gestiona. La unidad de medida es gibibyte (GiB). Un gibibyte = 1024 * 1024 * 1024 bytes.
Si la carga de trabajo de gestión indica el tamaño del volumen de los datos, las funciones de copia de seguridad y recuperación tras fallos tendrán en cuenta el tamaño del volumen indicado (por ejemplo, el cálculo de uso de VMware será coherente con el tamaño notificado de la máquina virtual en vCenter).
Si gestionas 10 TiB de datos de Oracle repartidos en varias bases de datos, el uso de copia de seguridad y recuperación tras fallos indica un uso de datos de 10 * 1024 GiB.
Medición del uso para Compute Engine sin agentes
Las copias de seguridad y la recuperación tras fallos miden el uso de las copias de seguridad de máquinas virtuales de Compute Engine en función de la cantidad de almacenamiento de disco persistente vinculado a una máquina virtual de Compute Engine en el momento de la copia de seguridad. Las copias de seguridad y la recuperación tras fallos te permiten excluir volúmenes de disco persistente de las copias de seguridad. En estos casos, solo se utilizan los volúmenes de los que se debe crear una copia de seguridad para medir el uso.
Por ejemplo, si dos volúmenes de disco persistente de un TiB y dos TiB están vinculados a una máquina virtual de Compute Engine y configuras el SLT de copia de seguridad para excluir el volumen de 2 TiB, el uso de la máquina virtual se mide en un TiB.
Además, si la máquina virtual de 1 TiB crece o disminuye, las copias de seguridad y DR miden el uso en función del tamaño del volumen en el momento de la última copia de seguridad.
Medición del uso para VMware Engine sin agentes de Google Cloud
El precio de VMware Engine de Google Cloud se calcula según los nodos ve1 de VMware Engine de Google Cloud y los nodos de solo almacenamiento de VMware Engine ve1 de Google Cloud.
Para el nodo VMware Engine ve1 de Google Cloud
El precio se calcula en función del número de nodos ESXi que están protegidos. Un nodo ESXi se considera protegido si una o más de las máquinas virtuales conectadas a él están protegidas por el servicio de copia de seguridad y recuperación tras fallos.
A continuación se muestra un ejemplo del proceso de facturación de VMware Engine de Google Cloud:
Precio de las copias de seguridad de un solo nodo de VMware Engine de Google Cloud (solo copias de seguridad de máquinas virtuales) en la región us-central1 durante un mes =
(Precio según catálogo para hacer una copia de seguridad del nodo por hora) X (El nodo de un día está activo) X (Número de días en un mes).
Si el nodo de VMware Engine de Google Cloud está activo durante 24 horas, el mes tiene 30 días y el precio de crear una copia de seguridad de un nodo será de 0, 46 USD x 24 x 30 = 331 USD.
Solo se aplica a los precios para proteger las copias de seguridad de VMware Engine de Google Cloud, es decir, de toda la máquina virtual. No se incluyen los cargos por la gestión de copias de seguridad basadas en agentes, como los cargos por copias de seguridad coherentes de aplicaciones de SAP HANA, SQL Server, MySQL, Postgres, agentes de sistemas de archivos, etc. Para estimar los cargos por copias de seguridad basadas en agentes, consulta la medición del uso para copias de seguridad basadas en agentes.
Para nodo de solo almacenamiento de VMware Engine ve1 de Google Cloud
El precio de la protección de los nodos de solo almacenamiento de VMware Engine ve1 de Google Cloud se determina por el número de nodos de solo almacenamiento de VMware Engine ve1 de Google Cloud que se añadan a un clúster que tenga al menos uno o más nodos protegidos de VMware Engine ve1 de Google Cloud.
Si tienes un clúster con nodos protegidos de VMware Engine ve1 de Google Cloud y añades nodos de solo almacenamiento de VMware Engine ve1 de Google Cloud al mismo clúster, todos los nodos solo de almacenamiento del clúster se considerarán protegidos de forma predeterminada y se te cobrará por protegerlos todos. No puedes excluir la protección de los nodos de solo almacenamiento de VMware Engine ve1 de Google Cloud en un clúster que tenga al menos uno o más nodos protegidos de VMware Engine ve1 de Google Cloud.
Por ejemplo, imagina que tienes un clúster de 20 nodos y que vas a proteger 10 de ellos con el servicio de copia de seguridad y recuperación tras fallos. Si añades 3 nodos de solo almacenamiento al clúster, se considerarán protegidos los 3 y se te cobrará por proteger 10 + 3 = 13 nodos de VMware Engine ve1 de Google Cloud.
Si no vas a proteger ningún nodo de VMware Engine ve1 de Google Cloud de un clúster, los nodos de la versión 1 de VMware Engine de Google Cloud no se podrán proteger en ese caso.
Medición del uso para copias de seguridad basadas en agentes
Estas funciones miden el uso de las copias de seguridad basadas en agentes en función del tamaño real de la carga de trabajo. Por ejemplo, si la copia de seguridad de una base de datos de SQL Server usa un agente de copia de seguridad y recuperación tras fallos, y la suma de los archivos de datos de un servidor SQL Server es de cinco TiB y un volumen de siete TiB, el uso se mide en cinco TiB.
Medición del uso para copias de seguridad de bases de datos basadas en agentes
En el caso de las cargas de trabajo de Oracle y SQL Server, solo se tienen en cuenta para el uso las bases de datos protegidas. No tiene en cuenta los archivos de registro:
- Oracle: El tamaño asignado de los archivos de la base de datos protegida se tiene en cuenta para el uso. El tamaño asignado incluye archivos de datos y archivos de control.
- Microsoft SQL Server. El tamaño total de todos los archivos de la base de datos, incluidos los archivos .MDF, .LDF y .NDF protegidos, se tiene en cuenta para su uso.
Protección de bases de datos con el seguimiento de cambios de bloques (CBT) de Linux. La función de copia de seguridad y recuperación tras fallos permite crear copias de seguridad eficientes de varias bases de datos con seguimiento de bloques de cambios. Este modo de copia de seguridad se basa en el registro de la base de datos y en los archivos de datos para residir en volúmenes gestionados de Linux Logical Volume Manager (LVM). El uso de esta clase de cargas de trabajo se mide como el tamaño real utilizado de la base de datos protegida mediante las siguientes consultas:
Db2: llama a get_dbsize_info(?,?,?,-1);
MariaDB: SELECT SUM(data_length + index_length) FROM information_schema.TABLES donde table_schema='
'; MySQL: SELECT SUM(data_length + index_length) FROM information_schema.TABLES donde table_schema='
'; PostgreSQL: SELECT pg_database_size('$db');
SAP ASE: sp_spaceused;
SAP IQ: sp_iqdbsize * block_size;
SAP HANA: selecciona sum(TOTAL_SIZE) de sys_databases.M_VOLUME_FILES donde file_type='DATA'
SAP MaxDB: dbmcli -d $DBSID $MAXDB_KEY info DATA
Protección basada en volcados de SQL sin CBT de Linux. Las copias de seguridad y la recuperación tras fallos son compatibles con las copias de seguridad tradicionales basadas en volcados de SQL. En este modo, el uso se mide como el tamaño de la base de datos según lo registrado en el momento de la copia de seguridad.
Medición del uso de copias virtuales
Las copias de seguridad y la recuperación tras fallos miden el uso de las copias virtuales, a partir del momento en que se crea dicha copia. La cantidad de uso se basa en el tamaño de la aplicación en el momento de la última copia de seguridad. A medida que se realizan nuevas copias de seguridad, el uso se actualiza para reflejar el tamaño actual de la aplicación. La forma más habitual de crear copias virtuales es mediante tareas de montaje. Hay otros tipos de tareas, como preparación para montar y volver a aprovisionar, que también pueden crear una copia virtual. Los cargos por uso se prorratean en función del tiempo durante el que se esté usando la copia virtual (desde que se realiza la activación correctamente hasta que se desactiva, se miden en incrementos de 1 hora).
Fíjate en el ejemplo de una base de datos de SQL Server con un tamaño de 500 GiB. Las copias de seguridad de esta base de datos conllevan un cargo por uso de 500 GiB. Además, imagina que se aprovisiona una copia virtual de esta base de datos en un servidor de prueba el primer día del mes, a partir del mediodía, a partir de la copia de seguridad más reciente. El día 10 del mes, la base de datos de origen se reduce a 400 GiB. El día 20 del mes, la copia virtual se desmonta del servidor de prueba a las 11:00 a. El cargo por uso de copias virtuales cambia a 400 GiB el día 10 (en el momento de la copia de seguridad) y continúa hasta el día 20 del mes. El uso de la copia virtual durante el día 20 solo contará durante 11 horas, no durante todo el día. La cantidad de uso no cambia cuando se escriben datos adicionales en la copia virtual.
Factores que influyen en la medición del uso
Factores que influyen en la medición del uso en situaciones fuera del marco:
- Volumen comprimido. Si la compresión está habilitada, el uso cuenta los valores posteriores a la compresión. Por ejemplo, si un volumen de 2 TiB tiene 2,5 TiB de datos comprimidos en 1,8 TiB, el uso será 1,8 TiB, no 2,5 TiB.
- Volumen optimizado para Windows. En el caso de los volúmenes optimizados para Windows, las copias de seguridad y la recuperación tras fallos rehidratan el volumen necesario para la copia de seguridad, y el recuento de uso será el valor de rehidratación. Por ejemplo, si un volumen optimizado para Windows de un TiB contiene 800 GiB de datos, cuando se rehidratan para hacer la copia de seguridad termina en 1,1 TiB, el uso es de 1,1 TiB.
- Tamaños de bloques. En el caso de los discos en staging, las funciones de copia de seguridad y recuperación tras fallos miden el uso en función del tamaño de los bloques. Si el tamaño del bloque del volumen de origen y el tamaño del bloque de disco en staging coinciden, los valores de uso coincidirán exactamente con el volumen de origen. Si el tamaño de los bloques que se usa en el disco en staging es distinto del volumen de origen, habrá una pequeña diferencia porque el cálculo del uso se hace en el disco en staging.
- Grupos de coherencia. El recuento de uso de un grupo de coherencia es la suma de todos los tamaños de cargas de trabajo que incluye. Las cargas de trabajo se miden por separado y se suman.
Siguientes pasos
Si tienes alguna duda relacionada con los precios, consulta las preguntas frecuentes.