O Backup e DR permite fazer backup de instâncias do Cloud SQL, clusters do AlloyDB, instâncias do Compute Engine e discos individuais no console doGoogle Cloud . Os procedimentos para fazer backup e restaurar esses recursos podem ser encontrados na documentação deles. Se todas as suas cargas de trabalho se encaixarem nessas categorias, você não precisará de um dispositivo de backup/recuperação.
O Backup e DR para VMs do VMware e bancos de dados SAP HANA, IBM Db2, Oracle e Microsoft SQL Server executados em instâncias do Compute Engine requer um console de gerenciamento de dispositivos de Backup e DR e um ou mais dispositivos de backup/recuperação. Ao usar essa configuração, é necessário escolher o tamanho dos dispositivos de backup/recuperação para que correspondam aos aplicativos que você faz backup. O fluxo dessa configuração envolve a criação de um servidor de gerenciamento, a implantação de appliances e o uso do console de gerenciamento de appliances para configurar programações de backup e definir o que é armazenado em backup e onde.
Para uma visão geral das estratégias que garantem o uso mais eficaz dos dispositivos de backup/recuperação, consulte Considerações sobre a implantação de dispositivos de backup/recuperação.
Nesta página, descrevemos como realizar a ativação inicial do Backup e DR e definir as configurações do projeto.
Componentes da arquitetura do dispositivo de backup/recuperação
A arquitetura do Backup e DR é fornecida pelos seguintes componentes:
Console doGoogle Cloud : o console do Google Cloud inclui o produto de backup e DR para gerenciamento centralizado dos backups em cofre do Persistent Disk, planos de backup para instâncias do Compute Engine e backup aprimorado para o Cloud SQL nesses produtos.
Console de gerenciamento de dispositivos: o console de gerenciamento de dispositivos serve como o plano de gerenciamento para seus dispositivos de backup/recuperação. Cada implantação do Backup e DR inclui um único console de gerenciamento de dispositivos que gerencia qualquer número de dispositivos de backup/recuperação. O console de gerenciamento do dispositivo é implantado no projeto de administração de backup e tem alta disponibilidade na região implantada, oferecendo resiliência contra interrupções zonais.
Dispositivos de backup/recuperação: o dispositivo de backup/recuperação é o movimentador de dados que captura, move e gerencia com eficiência o ciclo de vida dos dados de backup na empresa. Os dispositivos de backup/recuperação são implantados na entidade de carga de trabalho para cargas de trabalho na nuvem. Se você implantar vários dispositivos de backup/recuperação, cada um deles precisará ser associado a uma conta de serviço exclusiva.
Agentes de backup e DR: o agente de backup e DR chama as APIs nativas do aplicativo para capturar dados de aplicativos de produção de maneira eficiente e incremental, além de fornecer reconhecimento de aplicativos no momento da recuperação. O agente é instalado nos hosts de aplicativos em que os aplicativos a serem protegidos residem. Se você estiver protegendo apenas toda a VM ou um subconjunto dos discos dela, o agente de backup e DR não será necessário.
O console de gerenciamento do dispositivo é ativado em uma rede VPC do produtor de serviços. Essa VPC do produtor de serviços se comunica com seu projeto usando o Acesso privado do Google.
A comunicação entre o servidor de gerenciamento e os appliances, entre os appliances e entre os appliances e os agentes de host é protegida pela autenticação TLS mútua.
Configurar o Backup e DR no console do Google Cloud
Acesse o console do Google Cloud para ativar a API backupdr e configurar as permissões da sua conta:
Ativar o Google Cloud Backup e DR
Tipos de dispositivos de backup/recuperação
O Backup e DR oferece tipos de dispositivos otimizados para diferentes cargas de trabalho: VMs do Compute Engine, VMs do VMware, bancos de dados e sistemas de arquivos. Escolha o tipo de dispositivo que melhor atende às suas necessidades. É importante selecionar o melhor tipo de dispositivo para suas cargas de trabalho. Depois que o dispositivo de backup/recuperação estiver em serviço, ele será executado continuamente para sempre, sempre pronto para executar e executar novamente backup, restauração e outros jobs em todos os momentos.
O Backup e DR oferece os seguintes tipos de appliance:
- Standard para VMs do VMware e outros bancos de dados ou recursos: esse tipo de máquina n2-standard-16 oferece desempenho ideal para fazer backup de bancos de dados de produção, VMs do VMware e outros recursos. Esse dispositivo adiciona 4 TB de capacidade de disco equilibrada na implantação, e é possível adicionar mais 63 discos de 4 TB. Esse dispositivo pode gerenciar até 1.500 aplicativos e 5.000 snapshots diários.
- Padrão para VMs do Compute Engine ou bancos de dados SAP HANA: esse tipo de máquina e2-standard-4 é ideal para fazer backup de instâncias do Compute Engine, instâncias do Cloud SQL, clusters do AlloyDB e recursos de dados que usam o Persistent Disk para backups: bancos de dados IBM Db2 e SAP HANA configurados para usar o Persistent Disk. Esse tipo de dispositivo tem uma capacidade mínima Persistent Disk de 10 GB. Esse dispositivo pode gerenciar até 5.000 instâncias do Compute Engine e do Cloud SQL, clusters do AlloyDB e aplicativos de dados baseados em Persistent Disk.
Básico para VMs do VMware e outros bancos de dados ou recursos: esse tipo de máquina e2-standard-16 oferece suporte a um desempenho moderado para fazer backup de bancos de dados, VMs do VMware e outros recursos. Esse dispositivo pode gerenciar até 1.500 aplicativos e 5.000 snapshots diários. Esse dispositivo adiciona 4 TB de capacidade de disco padrão na implantação, e é possível adicionar mais 63 discos de 4 TB dos seguintes tipos:
- Persistent Disk de capacidade mínima: essa opção oferece uma capacidade mínima de disco de 10 GB. Nesse tipo de armazenamento, os backups são armazenados como snapshots Persistent Disk e não consomem o armazenamento local do dispositivo de backup/recuperação.
- Disco permanente padrão: selecione esse tipo de armazenamento se quiser ter um armazenamento em blocos eficiente. Isso é recomendado para VMs do Google Cloud VMware Engine, bancos de dados ou aplicativos de sistema de arquivos com E/S média-alta, além de VMs do Compute Engine. Isso adiciona 4 TB de capacidade Persistent Disk como a capacidade mínima de disco.
- Disco permanente SSD: selecione esse tipo de armazenamento se quiser ter um armazenamento em blocos rápido. Isso é recomendado para o Google Cloud VMware Engine, bancos de dados ou aplicativos de sistema de arquivos com E/S muito alta, além de VMs do Compute Engine. Isso adiciona 4 TB de capacidade Persistent Disk como a capacidade mínima de disco.
Quando você implanta um dispositivo, uma conta de serviço é criada automaticamente, independentemente do tipo de dispositivo. É possível ver a conta de serviço na página Conta de serviço.
O nome da conta de serviço aparece no formato de endereço de e-mail:
APPLIANCE_NAME@PROJECT_ID.iam.gserviceaccount.com
Substitua:
- APPLIANCE_NAME: o nome do dispositivo de backup/recuperação.
- PROJECT_ID: o ID do projeto do Google Cloud (origem).
É possível mover backups com necessidades de retenção de longo prazo para o armazenamento Standard, Nearline e Coldline Storage, dependendo da necessidade esperada de acessar os dados.
Configurações de firewall
As seguintes regras de firewall necessárias para entrada no Backup e DR são adicionadas automaticamente.
| Finalidade | Origem | Destino | Porta (TCP) |
|---|---|---|---|
| Tráfego de suporte (suporte para o dispositivo) | SSH_CLIENT_IP | Dispositivo de backup/recuperação | 26 |
| Backup iSCSI (host para dispositivo) | AGENT_HOST_IP | Dispositivo de backup/recuperação | 3260 |
| Tráfego do StreamSnap (dispositivo para dispositivo) | SOURCE_APPLIANCE_IP | Dispositivo de backup/recuperação | 5107 |
| Conectividade do dispositivo de backup/recuperação com o console de gerenciamento de dispositivos | APPLIANCE_IP | *.backupdr.googleusercontent.com | 443 |
Substitua:
- SSH_CLIENT_IP: o endereço IP do host que executa o cliente SSH.
- AGENT_HOST_IP: o endereço IP do host que executa o agente de backup e DR.
- SOURCE_APPLIANCE_IP: o endereço IP do dispositivo de origem.
- APPLIANCE_IP: o endereço IP ou a sub-rede do dispositivo de backup/recuperação.
Para mais detalhes sobre como configurar essa regra, consulte Preparar para implantar o Backup e DR.
Para qualquer host que esteja executando o agente de backup e DR, é necessário adicionar manualmente a seguinte porta TCP para permitir a conectividade com uma regra de firewall de entrada.
| Finalidade | Origem | Destino | Porta (TCP) |
|---|---|---|---|
| Tráfego do agente (dispositivo para host) | Dispositivo de backup/recuperação | Host que executa o agente de Backup e DR | 5106 |
Para hosts que usam NFS para tráfego de backup ou para hosts ESX em execução no Google Cloud VMware Engine que usam NFS para montagens, é necessário adicionar manualmente as seguintes portas TCP e UDP para permitir a conectividade com uma regra de firewall de entrada.
| Finalidade | Origem | Destino | Porta (TCP/UDP) |
|---|---|---|---|
| Backup ou montagem do NFS | Host que executa o agente ou host ESXi que executa a montagem | Dispositivo de backup/recuperação | 111, 756, 2049, 4001, 4045 |
Para uma lista das permissões usadas durante essa operação, consulte Referência de permissões de instalação do Backup e DR.
Regiões compatíveis
A seção a seguir lista as regiões com disponibilidade do console de gerenciamento de dispositivos e dos dispositivos de backup/recuperação.
Regiões com disponibilidade do console de gerenciamento de dispositivos
Embora o Backup e DR possa ser usado para fazer backup de cargas de trabalho compatíveis em qualquer região doGoogle Cloud , o console de gerenciamento do dispositivo só pode ser ativado nas seguintes regiões:
| Área geográfica | Nome da região | Descrição do local regional | |
|---|---|---|---|
| América do Norte | |||
northamerica-northeast1 * |
Montreal |
 Baixo CO2
|
|
northamerica-northeast2 |
Toronto |
Baixo CO2
|
|
us-central1 |
Iowa |
CO2 baixo
|
|
us-east1 |
Carolina do Sul | ||
us-east4 |
Norte da Virgínia | ||
us-east5 |
Columbus | ||
us-south1 |
Dallas |
Baixo CO2
|
|
us-west1 |
Oregon |
Baixo CO2
|
|
us-west2 |
Los Angeles | ||
us-west3 |
Salt Lake City | ||
us-west4 |
Las Vegas | ||
northamerica-south1 * |
Querétaro | ||
| América do Sul | |||
southamerica-east1 |
São Paulo |
Baixo CO2
|
|
southamerica-west1 |
Santiago |
Baixo CO2
|
|
| Europa | |||
europe-central2 |
Varsóvia |
Baixo CO2
|
|
europe-north1 |
Finlândia |
Baixo CO2
|
|
europe-north2 |
Estocolmo |
Baixo CO2
|
|
europe-southwest1 |
Madri |
Baixo CO2
|
|
europe-west1 |
Bélgica |
Baixo CO2
|
|
europe-west2 |
Londres |
CO2 baixo
|
|
europe-west3 |
Frankfurt | ||
europe-west4 |
Países Baixos |
Baixo CO2
|
|
europe-west6 |
Zurique |
Baixo CO2
|
|
europe-west8 |
Milão |
Baixo CO2
|
|
europe-west9 |
Paris |
Baixo CO2
|
|
europe-west10 |
Berlim | ||
europe-west12 |
Turim |
Baixo CO2
|
|
| Oriente Médio | |||
me-central1 |
Doha | ||
me-central2 |
Damã | ||
me-west1 |
Israel | ||
| África | |||
africa-south1 |
Johannesburgo | ||
| Ásia-Pacífico | |||
asia-east1 |
Taiwan | ||
asia-east2 |
Hong Kong | ||
asia-northeast1 |
Tóquio | ||
asia-northeast2 * |
Osaka | ||
asia-northeast3 |
Seul | ||
asia-southeast1 |
Singapura | ||
asia-southeast2 |
Jacarta | ||
australia-southeast1 |
Sydney | ||
australia-southeast2 |
Melbourne | ||
| Índia | |||
asia-south1 |
Mumbai | ||
asia-south2 |
Délhi |
* Querétaro (northamerica-south1), Montreal (northamerica-northeast1) e Osaka (asia-northeast2) não são compatíveis com a separação de zonas. Isso significa que as várias zonas dentro de cada uma dessas regiões podem não estar localizadas em campi de data center fisicamente separados. Consequentemente, um único desastre físico localizado pode afetar várias zonas na mesma região, aumentando o risco de perda de dados em comparação com regiões que oferecem suporte à separação de zonas.
Regiões com disponibilidade do dispositivo de backup/recuperação
Os dispositivos de backup/recuperação podem ser implantados em qualquer zona doGoogle Cloud .
O serviço de fluxo de trabalho para realizar a implantação do dispositivo de backup/recuperação é compatível com as
regiões listadas. Se o serviço de fluxo de trabalho não estiver
disponível em uma região em que o dispositivo de backup/recuperação está implantado, o
Backup e DR vai executar o fluxo de trabalho por padrão na região us-central1
(o dispositivo em si ainda será criado na região selecionada). Se você tiver uma
política da organização definida para impedir a criação de recursos em outras regiões,
atualize temporariamente a política para permitir a criação de
recursos na região us-central1. É possível restringir a região us-central1
após a implantação do dispositivo de backup/recuperação.