As SKUs usadas para faturar as cobranças de armazenamento do serviço de Backup e DR dependem se o recurso protegido está sendo protegido em um vault de backup ou em um armazenamento autogerenciado.

Se um recurso estiver protegido em um backup vault, as cobranças de armazenamento serão faturadas ao projeto em que o backup vault foi criado, usando os SKUs do serviço de Backup e DR e com os preços definidos na tabela abaixo.

Se um recurso for protegido em um armazenamento autogerenciado (por exemplo, um bucket do Cloud Storage ou um snapshot do disco permanente), as cobranças de armazenamento serão feitas usando os SKUs correspondentes. Para mais detalhes sobre os preços do Cloud Storage, consulte Preços do Cloud Storage. Para mais detalhes sobre os preços de snapshots do Persistent Disk, consulte Preços de snapshots do Cloud Persistent Disk.

Cada projeto no Google Cloud tem uma conta de faturamento que é usada para definir quem paga pelo uso de recursos e APIs do Google Cloud nesse projeto. O projeto e as SKUs usados para o faturamento do serviço de Backup e DR são determinados pelo tipo de recurso protegido.

Proteção de disco independente (disco permanente e hiperdisco) em um cofre de backup (inclui proteção via Terraform e Google Cloud CLI)

As cobranças de gerenciamento de discos (permanentes ou hiperdiscos) sob proteção ativa em um cofre de backup são faturadas ao projeto em que o disco protegido está localizado. A tabela a seguir lista as SKUs e os pontos de preço para proteção de disco em um cofre de backup.

Proteção de VM do Compute Engine em um cofre de backup (inclui proteção via Terraform e Google Cloud CLI)

As cobranças de gerenciamento de VMs sob proteção ativa em um cofre de backup são faturadas ao projeto em que a VM protegida está localizada. A tabela a seguir lista as SKUs e os preços para proteção em um cofre de backup.

Se uma VM não estiver mais sob proteção ativa, mas tiver dados de backup em um cofre de backup, as cobranças de gerenciamento serão faturadas conforme descrito aqui.

Proteção de VM do Compute Engine em armazenamento autogerenciado

As cobranças de gerenciamento para proteção em armazenamento autogerenciado são faturadas ao projeto em que o serviço de Backup e DR foi ativado e de onde o console de gerenciamento foi implantado. Isso é independente das zonas, regiões ou projetos em que os dispositivos de backup/recuperação estão localizados. A tabela a seguir lista as SKUs e os preços para proteção no armazenamento autogerenciado.

As VMs do VMware Engine são protegidas pelo console de gerenciamento do serviço de Backup e DR. As cobranças de gerenciamento de recursos sob proteção ativa pelo console de gerenciamento do serviço de backup e DR são faturadas ao projeto em que o serviço de backup e DR foi ativado e de onde o console de gerenciamento foi implantado. Isso é independente das zonas, regiões ou projetos em que os dispositivos de backup/recuperação estão localizados.

O preço do backup do VMware Engine é baseado no consumo e no termo de compromisso. As opções incluem sob demanda ou descontos por compromisso de uso para termos de um e três anos.

A tabela a seguir lista os SKUs e os preços para proteger nós ve1-standard-72 e nós somente de armazenamento ve1-standard-72 do VMware Engine em um cofre de backup ou em um armazenamento autogerenciado.

A tabela a seguir lista as SKUs e os preços para proteger nós do VMware Engine ve2 em um cofre de backup ou em um armazenamento autogerenciado.

Se uma VM não estiver mais sob proteção ativa, mas tiver dados de backup em um cofre de backup, as cobranças de gerenciamento serão faturadas conforme descrito aqui.

Os bancos de dados do SQL Server autogerenciados são protegidos pelo console de gerenciamento do serviço de Backup e DR. As cobranças de gerenciamento dos recursos sob proteção ativa pelo console de gerenciamento do serviço de backup e DR são feitas no projeto em que o serviço de backup e DR foi ativado e de onde o console de gerenciamento foi implantado. Isso é independente das zonas, regiões ou projetos em que os dispositivos de backup/recuperação estão localizados.

A tabela a seguir lista as SKUs e os preços para proteção em um cofre de backup.

Se o SQL Server não estiver mais sob proteção ativa, mas tiver dados de backup em um backup vault, as cobranças de gerenciamento serão faturadas conforme descrito aqui.

A tabela a seguir lista as SKUs e os preços para proteção no armazenamento autogerenciado.

Os bancos de dados Oracle autogerenciados são protegidos pelo console de gerenciamento do serviço de Backup e DR. As cobranças de gerenciamento dos recursos sob proteção ativa pelo console de gerenciamento do serviço de backup e DR são feitas no projeto em que o serviço de backup e DR foi ativado e de onde o console de gerenciamento foi implantado. Isso é independente das zonas, regiões ou projetos em que os dispositivos de backup/recuperação estão localizados.

O preço do backup do Oracle em um vault de backup é baseado no consumo e no termo de compromisso. As opções incluem sob demanda ou descontos por compromisso de uso para termos de um e três anos. A tabela a seguir lista os SKUs e os pontos de preço para a proteção em um cofre de backup.

Se o Oracle não estiver mais sob proteção ativa, mas tiver dados de backup em um vault de backup, as cobranças de gerenciamento serão cobradas conforme descrito aqui.

A tabela a seguir lista as SKUs e os preços para proteção no armazenamento autogerenciado.

Os bancos de dados SAP HANA autogerenciados são protegidos pelo console de gerenciamento do serviço de backup e DR. As cobranças de gerenciamento dos recursos sob proteção ativa pelo console de gerenciamento do serviço de backup e DR são feitas no projeto em que o serviço de backup e DR foi ativado e de onde o console de gerenciamento foi implantado. Isso é independente das zonas, regiões ou projetos em que os dispositivos de backup/recuperação estão localizados. A tabela a seguir lista as SKUs e os preços para proteção no armazenamento autogerenciado.

O serviço de Backup e DR também oferece proteção para outros recursos pelo console de gerenciamento do serviço de Backup e DR, conforme listado abaixo (por exemplo, sistemas de arquivos, bancos de dados MySQL etc.). As cobranças de gerenciamento desses recursos sob proteção ativa pelo console de gerenciamento do serviço de backup e DR são faturadas ao projeto em que o serviço de backup e DR foi ativado e de onde o console de gerenciamento foi implantado. Isso é independente das zonas, regiões ou projetos em que os dispositivos de backup/recuperação estão localizados. A tabela a seguir lista as SKUs e os preços para proteção no armazenamento autogerenciado.

Se um recurso não estiver mais sob proteção ativa (ou seja, a proteção do recurso está "inativa") em um determinado cofre de backup, mas ainda tiver dados de backup nesse cofre, as cobranças de gerenciamento serão faturadas ao projeto em que o cofre de backup foi criado e usando o SKU e o preço listados abaixo.

Observe também os seguintes cenários em que a proteção de recursos será considerada "inativa":

• Consulte o comportamento de faturamento associado à desativação da API
• Para recursos protegidos por um dispositivo de backup/recuperação:
• Se o dispositivo de backup/recuperação não se comunicar com o cofre de backup por 24 horas, a proteção de recursos do cofre de backup associado será considerada "inativa".

Para calcular as cobranças de gerenciamento, o Backup e DR mede o uso com base no tamanho real da carga de trabalho no front-end ou no tamanho da carga de trabalho que está gerenciando. A unidade de medida é gibibyte (GiB). Um gibibyte = 1024 * 1024 * 1024 bytes.

Se a carga de trabalho gerenciada informar o tamanho do volume dos dados, o Backup e DR vai considerar esse tamanho (por exemplo, o cálculo de uso do VMware será consistente com o tamanho informado da VM no vCenter).

Se você gerenciar 10 TiB de dados da Oracle distribuídos em vários bancos de dados, os relatórios de uso do Backup and DR vão indicar 10 * 1.024 GiB de uso de dados.

Observação:a medição do uso do Backup and DR não considera a frequência da captura de dados, onde as cópias são armazenadas, quantas cópias são feitas, a taxa de alteração dos dados, o período de retenção ou quanto armazenamento é ocupado pelas cópias.

Medição do uso do Compute Engine ao fazer backup no armazenamento autogerenciado

Ao fazer backup para armazenamento autogerenciado, o Backup e DR mede o uso de backups de VMs do Compute Engine com base na quantidade de armazenamento de PD anexado a uma VM do Compute Engine no momento do backup. O Backup e DR permite excluir volumes de PD do backup. Nesses casos, apenas os volumes identificados para backup são usados para medir o uso.

Por exemplo, se dois volumes de PD de um TiB e dois TiB estiverem anexados a uma VM do Compute Engine e você configurar o SLT de backup para excluir o volume de 2 TiB, o uso da VM será medido como um TiB.

Além disso, se a VM de 1 TiB aumentar ou diminuir, o Backup e DR vai medir o uso com base no tamanho do volume no momento do backup mais recente.

Medição de uso do Compute Engine ao fazer backup em um vault de backup

Ao fazer backup em um cofre de backup, o Backup e DR mede o uso da VM do Compute Engine conforme descrito abaixo

• As cobranças de gerenciamento são baseadas no tamanho da VM do Compute Engine no momento do backup. Por exemplo, se uma VM tiver um total de 1 TiB de armazenamento anexado, as cobranças de gerenciamento serão para 1 TiB, independentemente do armazenamento usado.
• Além disso, se a VM de 1 TiB aumentar ou diminuir, o Backup e DR vai medir o uso com base no tamanho da VM no momento do backup mais recente.

Medição do uso ao fazer backup de discos independentes (permanentes e hiperdiscos) em um backup vault

Para backups armazenados em um vault de backup, o Backup e DR calcula o uso de discos permanentes/Hyper independentes da seguinte forma:

• As taxas de gerenciamento são determinadas pelo tamanho do disco permanente/hiperdisco no momento de cada backup. Isso significa que um disco de 1 TiB vai gerar cobranças de gerenciamento para 1 TiB, independentemente do armazenamento real usado.
• Além disso, o Backup and DR vai recalcular o uso com base no tamanho atual do disco durante o backup mais recente, mesmo que o tamanho do disco da VM tenha mudado desde o backup anterior.

Medição de uso para o VMware Engine sem agente

Para nós ve1 e ve2 do VMware Engine

O preço é calculado com base no número e no tipo de nós ESXi que estão sendo protegidos. Um nó ESXi é considerado protegido se uma ou mais VMs anexadas a ele estiverem sendo protegidas pelo serviço de backup e DR.

A seguir, um exemplo que demonstra o processo de faturamento do VMware Engine:

• Preço para fazer backup de um único nó ve1 do VMware Engine (somente backups de VM) na região us-central1 por um mês = (preço de tabela para fazer backup do nó/ hora) X (número de horas em que o nó está ativo por dia) X (número de dias em um mês).
• Considerando que o nó do VMware Engine está ativo por 24 horas, há 30 dias em um mês e o preço para fazer backup de um nó será de US $0, 46 X 24 X 30 = US$331.

Para nós ve2, o preço é baseado no número e no tipo (mega, grande, padrão, pequeno) de nós ESXi que estão sendo protegidos.

O preço se refere apenas à proteção do VMware Engine: backups de todas as VMs. Ele não inclui cobranças de gerenciamento de backup para backups baseados em agente, como cobranças por backups consistentes do aplicativo para agentes SAP HANA, SQL Server, MySQL, Postgres, File System etc. Para estimar as cobranças de backups baseados em agente, consulte Medição de uso para backup baseado em agente.

Para nós somente de armazenamento do VMware Engine ve1 e ve2

O preço da proteção de um nó somente de armazenamento ve1/ve2 do VMware Engine é determinado pelo número de nós somente de armazenamento ve1/ve2 do VMware Engine adicionados a um cluster que tenha pelo menos um ou mais nós protegidos ve1/ve2 do VMware Engine.

Se você tiver um cluster com nós protegidos do VMware Engine ve1/ve2 e adicionar nós somente de armazenamento do VMware Engine ve1/ve2 ao mesmo cluster, todos os nós somente de armazenamento no cluster serão considerados protegidos por padrão, e você vai pagar pela proteção de todos eles. Não é possível excluir a proteção de nós somente de armazenamento do VMware Engine ve1/ve2 em um cluster que tenha pelo menos um ou mais nós protegidos do VMware Engine ve1/ve2.

Por exemplo, considere que você tem um cluster atual de 20 nós e está protegendo 10 deles usando o serviço de backup e DR. Se você adicionar 3 nós somente de armazenamento ao cluster, todos os 3 nós somente de armazenamento serão considerados protegidos, e você será cobrado pela proteção de 10 + 3 = 13 nós ve1 do VMware Engine.

Se você não estiver protegendo nenhum nó ve1/ve2 do VMware Engine em um cluster, os nós somente de armazenamento ve1/ve2 do VMware Engine não poderão ser protegidos nesse caso.

O Backup e DR mede o uso do backup baseado em agente no tamanho real da carga de trabalho. Por exemplo, se um backup de banco de dados do SQL Server usa o agente do Backup and DR e se a soma dos arquivos de dados de um SQL Server é de cinco TiB em um volume de sete TiB, o uso é medido como cinco TiB.

Medição de uso para backup baseado em agente de bancos de dados

Para cargas de trabalho do Oracle e SQL Server, apenas os bancos de dados protegidos são contados para o uso. Ele não considera arquivos de registros:

• Oracle. O tamanho alocado dos arquivos de banco de dados sob proteção é contabilizado no uso. O tamanho alocado inclui arquivos de dados e arquivos de controle.
• Microsoft SQL Server. O tamanho total de todos os arquivos de banco de dados, incluindo arquivos .MDF, .LDF e .NDF sob proteção, é contabilizado no uso.
• Proteção de banco de dados com o rastreamento de blocos alterados (CBT) do Linux. O Backup e DR oferece suporte a backups eficientes de vários bancos de dados com rastreamento de blocos alterados. Esse modo de backup depende de arquivos de dados e de registros de banco de dados que residem em volumes gerenciados pelo Logical Volume Manager (LVM) do Linux. Para essa classe de cargas de trabalho, o uso é medido como o tamanho real usado do banco de dados em proteção, usando as seguintes consultas:
• Db2: call get_dbsize_info(?,?,?,-1);
• MariaDB: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='';
• MySQL: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='';
• PostgreSQL: SELECT pg_database_size('$db');
• SAP ASE: sp_spaceused;
• SAP IQ: sp_iqdbsize * block_size;
• SAP HANA: select sum(TOTAL_SIZE) from sys_databases.M_VOLUME_FILES where file_type='DATA'
• SAP MaxDB: dbmcli -d $DBSID $MAXDB_KEY info DATA
• Proteção baseada em dump SQL sem CBT do Linux. O Backup e DR oferece suporte a backups tradicionais baseados em despejo de SQL. Nesse modo, o uso é medido como o tamanho do banco de dados, conforme informado pelo banco de dados no momento do backup.

Fatores que influenciam a medição do uso

Fatores que influenciam a medição do uso em cenários fora da banda:

• Volumes compactados. Quando o volume tem a compactação ativada, o uso conta os valores pós-compactação. Por exemplo, se um volume de 2 TiB tiver 2,5 TiB de dados que são compactados em 1,8 TiB, a contagem de uso será de 1,8 TiB, não de 2,5 TiB.
• Volumes otimizados para Windows. Para volumes otimizados para Windows, o Backup e DR reidrata o volume para backup, e a contagem de uso será o valor reidratado. Por exemplo, se um volume otimizado para Windows de 1 TiB contém 800 GiB de dados e, quando reidratado para backup, acaba sendo 1,1 TiB, o uso é de 1,1 TiB.
• Tamanhos de bloco. Para discos de preparo, o Backup and DR mede o uso com base no tamanho do bloco do disco de preparo. Se o tamanho do bloco do volume de origem e o tamanho do bloco do disco de preparo forem iguais, os valores de uso vão corresponder exatamente ao volume de origem. Se o tamanho do bloco usado no disco de preparo for diferente do volume de origem, haverá uma pequena diferença porque o cálculo de uso é feito no disco de preparo.
• Grupos de consistência. A contagem de uso de um grupo de consistência é a soma de todos os tamanhos de carga de trabalho no grupo de consistência. As cargas de trabalho são medidas individualmente e somadas.

Medição de uso para cópias virtuais

O Backup e DR mede o uso de cópias virtuais a partir do momento em que uma cópia virtual de uma carga de trabalho é criada. A quantidade de uso é baseada no tamanho do aplicativo no momento do último backup. À medida que novos backups são realizados, a quantidade de uso é atualizada para refletir o tamanho atual do aplicativo. A maneira mais comum de criar cópias virtuais é com trabalhos de montagem. Há outros tipos de jobs, como prep-mount e reprovision, que também podem criar uma cópia virtual. As cobranças de uso são proporcionais ao tempo em que a cópia virtual é usada (do momento da montagem bem-sucedida até o momento da desmontagem, medido em incrementos de 1 hora).

Considere o exemplo de um banco de dados do SQL Server de 500 GiB. Os backups desse banco de dados geram uma cobrança de uso de backup associada a 500 GiB. Além disso, considere que uma cópia virtual desse banco de dados é provisionada em um servidor de teste ao meio-dia do primeiro dia do mês a partir do backup mais recente. No dia 10 do mês, o banco de dados de origem diminui para 400 GiB. No dia 20 do mês, a cópia virtual é desmontada do servidor de teste às 11h. Nesse cenário, uma cobrança de uso de cópia virtual de 500 GiB é feita por 12 horas no dia 1º e 24 horas por dia do dia 2 até o horário do backup no dia 10. A cobrança de uso da cópia virtual muda para 400 GiB no dia 10 (no momento do backup) e continua até o dia 20 do mês. O uso da cópia virtual no dia 20 vai contar apenas 11 horas, e não o dia inteiro. O valor de uso não muda com dados adicionais gravados na cópia virtual.

Se os dados forem transferidos de um cofre de backup quando a origem e o destino estiverem em locais diferentes do Google Cloud, poderão ser aplicadas cobranças de transferência de dados entre regiões.

As cobranças de transferência de dados entre regiões se aplicam atualmente a transferências associadas a VMs do VMware Engine, bancos de dados Oracle, bancos de dados SQL Server e discos.

As cobranças de transferência de dados entre regiões para VMs do VMware Engine, bancos de dados Oracle e bancos de dados SQL Server serão cobradas no projeto em que o cofre de backup está localizado, usando os SKUs do Backup e DR listados abaixo.

As cobranças de transferência de dados entre regiões para discos serão faturadas ao projeto de destino da transferência de dados e serão aplicadas ao tamanho dos dados que estão sendo transferidos.

• Para restaurações de disco, o projeto de destino é o projeto do recurso restaurado. O faturamento será feito pela SKU de transferência de dados inter-regional do Compute Engine correspondente.

As cobranças de transferência de dados entre regiões para VMs do Compute Engine serão aplicadas no futuro. Os clientes do Backup and DR vão receber um aviso prévio antes do início das cobranças de transferência de dados entre regiões para VMs do Compute Engine.

O preço da transferência de dados entre regiões com base no uso é mostrado na tabela abaixo e é medido por GiB de dados transferidos.

Podem ser aplicadas cobranças de upload para a criação de backups multirregionais. Podem ser aplicadas cobranças de download para a restauração de backups multirregionais.

As cobranças de upload e download se aplicam atualmente a transferências associadas a discos e ao tamanho dos dados transferidos.

Detalhes adicionais:

• Os encargos de upload e download são cobrados das SKUs correspondentes que têm locais geográficos que contêm o local multirregional.
• Quando as cobranças de upload/download são aplicadas a uma transferência de dados entre locais, as cobranças de transferência de dados entre regiões não são aplicadas.
• Faturamento do projeto
• As cobranças de upload são faturadas, pela SKU do serviço de Backup e DR correspondente, ao projeto em que o vault de backup multirregional foi criado.
• As cobranças de download são faturadas, pela SKU de download do serviço do Compute Engine correspondente, ao projeto de destino em que os dados foram restaurados.

Exemplos de casos de uso:

• "Fazer backup de um disco na região "us-central1" em um cofre de backup multirregional no local "us"
• Haveria cobranças de upload multirregional.
• A cobrança seria feita usando a SKU de upload multirregional "América do Norte" do serviço de Backup e DR.
• As cobranças de upload seriam faturadas no projeto em que o backup vault foi criado.
• Não haveria cobranças de transferência de dados entre regiões.
• Restaurar um backup de disco multirregional "us" para um recurso localizado na região "us-central1".
• Seriam aplicadas cobranças de download em várias regiões.
• O faturamento seria feito usando a SKU correspondente do Compute Engine (confira os detalhes de preços do Compute Engine aqui)
• As cobranças de download serão faturadas no projeto de destino em que o recurso restaurado foi criado.
• Não haveria cobranças de transferência de dados entre regiões.
• Restaurar um backup de disco multirregional "us" para um recurso localizado na região "europe-west1".
• Não haveria cobranças de download multirregional.
• As cobranças de transferência de dados entre regiões seriam aplicadas.
• O faturamento seria feito usando a SKU correspondente do Compute Engine (confira os detalhes de preços do Compute Engine aqui).
• As cobranças de transferência de dados entre regiões seriam faturadas ao projeto de destino em que o recurso restaurado foi criado.

As cobranças de upload e download para VMs do Compute Engine serão aplicadas no futuro. Os clientes do Backup and DR serão avisados com antecedência antes do início das cobranças de upload e download para VMs do Compute Engine.

Desativação da API no projeto que contém um backup vault

Quando a API do serviço de Backup e DR é desativada em um projeto que contém um backup vault, o comportamento de faturamento é o seguinte:

• A cobrança do armazenamento vai continuar até que os backups expirem de acordo com a programação de expiração definida pelo usuário.
• Para VMs do Compute Engine protegidas em backup vaults
• O faturamento de gerenciamento da proteção ativa vai continuar sendo cobrado (no projeto em que o recurso protegido está localizado) por 30 dias. Após 30 dias consecutivos no estado desativado, a proteção dos recursos armazenados será considerada inativa.
• Nos casos em que os dados de backup existem em um backup vault, mas o recurso associado não está mais sob proteção ativa, o faturamento de gerenciamento para recursos que não estão mais sob proteção ativa será aplicado.

Desativação da API em um projeto que contém VMs do Compute Engine protegidas em um cofre de backup

Quando a API do serviço de Backup e DR é desativada em um projeto que contém um recurso protegido em um vault de backup, o comportamento de faturamento é o seguinte:

• A cobrança do armazenamento vai continuar até que os backups expirem de acordo com a programação de expiração definida pelo usuário.
• O faturamento de gerenciamento da proteção ativa vai parar. Após 30 dias consecutivos no estado desativado, a proteção dos recursos armazenados será considerada inativa.
• Nos casos em que os dados de backup existem em um backup vault, mas o recurso associado não está mais sob proteção ativa, o faturamento de gerenciamento para recursos que não estão mais sob proteção ativa será aplicado.

O dispositivo de backup/recuperação é executado como uma VM do Compute Engine em um projeto escolhido pelo cliente. Os dispositivos do serviço de Backup e DR vêm em três configurações diferentes, conforme listado em Configurar e planejar a implantação do serviço de backup e recuperação de desastres. As cobranças padrão de instâncias do Compute Engine se aplicam à execução desses dispositivos.