Configurar e planejar a implantação do serviço de backup e DR

Nesta página, descrevemos como fazer a ativação inicial do serviço Backup and DR e configurar as opções do seu projeto.

Componentes da arquitetura do Backup e DR

A arquitetura do serviço de Backup e DR é fornecida pelos seguintes componentes:

• Console de gerenciamento: o console de gerenciamento 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 que gerencia qualquer número de dispositivos de backup/recuperação. O console de gerenciamento é implantado no projeto de administração de backup e tem alta disponibilidade na região implantada, oferecendo resiliência contra interrupções de zona.

• 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 sua empresa. Os dispositivos de backup/recuperação são implantados na entidade de carga de trabalho para cargas de trabalho na nuvem.

• Agentes de backup e DR: o agente de backup e DR chama as APIs nativas do aplicativo para capturar dados de maneira eficiente dos aplicativos de produção de forma incremental e fornece a percepção do aplicativo 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 do Backup and DR não será necessário.

O console de gerenciamento é ativado em uma rede VPC de 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 dispositivos, entre os dispositivos e entre os dispositivos e os agentes host é protegida pela autenticação TLS mútua.

Considerações de implementação

Confira algumas considerações importantes que afetam a implantação do serviço de Backup e DR:

• Quais são os requisitos de objetivo do tempo de recuperação (RTO) da sua organização? O RTO é o período máximo em que você pode ficar sem seus dados. Por exemplo, se o RTO for de 4 horas,você precisará acessar os dados em até 4 horas após um desastre.

• Você precisa centralizar o gerenciamento de backups? Você precisa decidir se quer gerenciar seus backups de forma centralizada ou não.

  • O gerenciamento centralizado de backups significa que você tem um único console de gerenciamento para gerenciar backups de todas as suas cargas de trabalho em todas as linhas de negócios. Essa pode ser uma maneira mais eficiente de gerenciar backups, já que você só precisa gerenciar um único console de gerenciamento.
  • O gerenciamento descentralizado de backup significa que você tem um console de gerenciamento separado para cada linha de negócios. O modo de operação varia de organização para organização.

• Qual é seu caso de uso de backup? Você precisa de backups para recuperação de desastres em caso de desastre em uma região de produção ou é suficiente proteger seus dados localmente? Se você precisar de capacidade de recuperação de desastres, considere backups entre regiões. Isso significa armazenar seus backups em vários locais para que, se um deles for afetado por um desastre, seus dados ainda estejam acessíveis.

As cargas de trabalho estão em uma única região

A melhor estratégia de backup em uma região depende das suas necessidades.

Se você não precisa de recuperação de desastres (DR)

Para ter o melhor desempenho e reduzir os custos, implante o console de gerenciamento e os dispositivos de backup/recuperação na mesma região em que as cargas de trabalho estão sendo executadas. Armazene as imagens de backup na mesma região que as cargas de trabalho.

Se você também quiser ter cópias de backup fora do local, armazene os backups em uma região diferente ou use o armazenamento birregional ou multirregional. Armazenar backups em uma região diferente gera cobranças de rede e armazenamento.

Se você precisar de backup e DR

Para ter o melhor desempenho e menor custo, implante um console de gerenciamento na mesma região da carga de trabalho de produção e um segundo console de gerenciamento na região que pode ser usada para recuperação de desastres.

Implante dispositivos de backup/recuperação na região da carga de trabalho de produção e na região de recuperação de DR para minimizar o objetivo de tempo de recuperação (RTO). Isso garante que um ambiente de DR esteja totalmente pré-provisionado e disponível em caso de desastre.

Armazene imagens de backup na região de produção e uma cópia na região de recuperação de desastres (DR, na sigla em inglês) ou use armazenamento birregional ou multirregional. A cópia de backup da região de produção pode atender às necessidades rotineiras de backup com um desempenho mais rápido. Os dados copiados para sua região de DR podem ser usados para recuperar as cargas de trabalho caso a região de produção fique inativa.

As cargas de trabalho estão em várias regiões

A melhor estratégia de backup entre regiões depende das suas necessidades.

Se você não precisa de recuperação de desastres (DR)

Para ter o desempenho mais rápido e o menor custo, implante o console de gerenciamento em uma das regiões em que suas cargas de trabalho estão sendo executadas. Isso permite o gerenciamento centralizado em todas as cargas de trabalho e regiões.

Implante um ou mais dispositivos de backup/recuperação em cada região em que as cargas de trabalho estão sendo executadas. Armazene os backups na mesma região que as cargas de trabalho.

Se você também quiser ter cópias de backup fora do local, armazene os backups em uma região diferente ou use o armazenamento birregional ou multirregional. Armazenar backups em uma região ou multirregião diferente gera cobranças de rede e armazenamento.

Se você precisar de backup e DR

Implante um console de gerenciamento em cada uma das regiões de carga de trabalho de produção e outro na região de DR.

Implante dispositivos de backup/recuperação nas regiões de carga de trabalho de produção e na região de DR para minimizar o objetivo de tempo de recuperação (RTO). Isso garante que um ambiente de DR esteja totalmente pré-provisionado e disponível em caso de desastre.

Armazene backups na região da carga de trabalho de produção e uma cópia na região de DR ou use armazenamento birregional ou multirregional. A cópia de backup da região de produção pode ser usada para atender às necessidades de backup.

Uma imagem de backup no DR pode ser usada para recuperar cargas de trabalho se a região de produção estiver inativa.

Configurar o serviço de Backup e DR no console Google Cloud

Acesse o console Google Cloud para ativar a API do serviço de backup e DR e configurar as permissões da sua conta:

Ativar o Backup e DR do Google Cloud

Tipos de dispositivos de backup/recuperação

O serviç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. Você pode escolher o tipo de eletrodoméstico 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 é colocado em serviço, ele é executado continuamente, sempre pronto para executar e reexecutar backups, restaurações e outros trabalhos a qualquer momento.

O serviço de Backup e DR oferece os seguintes tipos de dispositivos:

• Padrão para VMs do Compute Engine ou bancos de dados SAP HANA: selecione essa opção se quiser fazer backup apenas de instâncias do Compute Engine ou bancos de dados SAP HANA usando Persistent Disk. Por padrão, esse dispositivo adiciona um tipo de máquina e2-standard-4 com uma capacidade mínima Persistent Disk de 10 GB. Esse dispositivo pode gerenciar até 5.000 VMs do Compute Engine.
• Standard para VMs do VMware e outros bancos de dados ou recursos: selecione essa opção se quiser uma configuração padrão que ofereça desempenho ideal para fazer backup de bancos de dados, VMs do VMware e outros recursos. Por padrão, esse appliance adiciona um tipo de máquina n2-standard-16. Isso adiciona 4 TB de capacidade de disco balanceada como a capacidade mínima. Esse dispositivo pode gerenciar até 1.500 aplicativos.

• Básico para VMs do VMware e outros bancos de dados ou recursos: selecione essa opção se quiser uma configuração básica que ofereça desempenho moderado para fazer backup de bancos de dados, VMs do VMware e outros recursos. Por padrão, esse appliance adiciona um tipo de máquina e2-standard-16. Esse dispositivo pode gerenciar até 1.500 aplicativos. Você pode escolher qualquer um dos seguintes tipos de disco para armazenar seus dados.

  • Disco permanente 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 do 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. Recomendado para VMs do Google Cloud VMware Engine, bancos de dados ou aplicativos de sistema de arquivos com E/S média a alta, além de VMs do Compute Engine. Isso adiciona 4 TB de capacidade de Persistent Disk como a capacidade mínima.
  • Disco permanente SSD: selecione esse tipo de armazenamento se quiser ter armazenamento em blocos rápido. 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 de Persistent Disk como a capacidade mínima.

Quando você implanta um appliance, uma conta de serviço é criada automaticamente, seja qual for o tipo de appliance. É possível conferir 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 my-service-account@my-project.iam.gserviceaccount.com, em que appliance-name é o nome de um dispositivo e projectid é o ID do seu projeto Google Cloud .

Escolher um tipo de armazenamento

O dispositivo de backup/recuperação armazena dados de backup no pool de snapshots do dispositivo local. Você pode copiar para o armazenamento de objetos para retenção de longo prazo. OGoogle Cloud oferece os três tipos de armazenamento de objetos local a seguir:

• Disco permanente de capacidade mínima: as imagens de backup são armazenadas como snapshots do Persistent Disk que não consomem o armazenamento local do dispositivo de backup/recuperação.

• Disco permanente padrão: esse tipo de armazenamento oferece armazenamento em blocos eficiente, começando com um Persistent Disk de 4 TB. Recomendado para VMware Engines e apps de banco de dados ou sistema de arquivos com E/S média a alta.

• Disco permanente SSD: esse tipo de armazenamento oferece armazenamento em blocos rápido, começando com um Persistent Disk de 4 TB. Recomendado para VMs do VMware Engine e apps de banco de dados ou sistema de arquivos com E/S muito alta. Google Cloud

É possível expandir a capacidade dos pools de disco mais tarde.

É possível mover backups com necessidades de retenção de longo prazo para o armazenamento Google Cloud Standard, Nearline e Coldline, dependendo da sua necessidade esperada de acessar os dados.

Topologia de rede recomendada para o serviço de Backup e DR

Google Cloud recomenda o uso da VPC compartilhada ao implantar o serviço de Backup e DR. A VPC compartilhada permite que uma organização conecte recursos de vários projetos a uma rede VPC comum para que eles possam se comunicar de maneira segura e eficiente usando IPs internos dessa rede. Quando você usa a VPC compartilhada, é preciso designar um projeto como host e anexar um ou mais projetos de serviço. As redes VPC no host são chamadas de redes VPC compartilhadas. Recursos qualificados de projetos de serviço podem usar sub-redes na rede VPC compartilhada.

Com a VPC compartilhada, os administradores da organização delegam responsabilidades administrativas, como a criação e o gerenciamento de instâncias, aos administradores de projetos de serviço enquanto mantêm o controle centralizado dos recursos de rede, como sub-redes, rotas e firewalls.

O console de gerenciamento é 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. O objetivo principal dessa conexão é que o console de gerenciamento e os dispositivos de backup/recuperação troquem metadados. O tráfego de backup não atravessa esse link. No entanto, um console de gerenciamento precisa se comunicar com todos os dispositivos de backup/recuperação implantados em qualquer rede.

Práticas recomendadas para VPC compartilhada

Recomendamos as seguintes práticas recomendadas:

• Conexão com o console de gerenciamento: é melhor conectar a rede do provedor de serviços a uma VPC compartilhada na sua rede. Todo o tráfego do console de gerenciamento flui por essa VPC e, portanto, pelo projeto host. O provisionamento da conectividade com o serviço de backup e DR por uma VPC compartilhada também permite uma conexão perfeita entre projetos em que as cargas de trabalho estão sendo executadas (projetos de serviço) e o serviço de backup e DR.

• Localização do dispositivo de backup/recuperação: os dispositivos de backup/recuperação precisam ser implantados em uma sub-rede com o Acesso privado do Google ativado para conectividade com o console de gerenciamento. Há duas estratégias recomendadas para selecionar os projetos dos dispositivos de backup/recuperação:

  • No projeto host central: nessa estratégia, o serviço de Backup e DR é tratado como um serviço central de TI. A equipe central de backup governa o provisionamento do serviço. Assim, todos os dispositivos de backup/recuperação são provisionados no projeto host, permitindo que os administradores centrais consolidem todos os recursos de backup em um projeto central. Essa abordagem consolida todos os recursos relacionados a backup e o faturamento deles em um único projeto.

  • Em projetos de serviço: essa estratégia é adequada para equipes mais descentralizadas, em que os projetos de serviço são criados e o gerenciamento deles é delegado a equipes distribuídas. Nesse cenário, a prática recomendada é provisionar a VPC para projetos de serviço downstream. Os dispositivos de backup/recuperação são instalados nos projetos de serviço dessas VPCs. Isso permite a colocalização da carga de trabalho e do dispositivo de backup/recuperação em um único projeto.

  • Acesso privado do Google: é recomendável ativar o Acesso privado do Google para cada sub-rede em que você instala um dispositivo de backup/recuperação. Isso garante que o dispositivo de backup/recuperação possa se comunicar com APIs, como Compute Engine, Cloud Storage e Cloud Logging, o que é importante para o funcionamento do monitoramento e dos alertas. Para simplificar e melhorar as conexões com as APIs Google Cloud , configure a resolução de DNS para private.googleapis.com, conforme documentado na seção Resumo das opções de configuração. Além disso, configure as regras de firewall dos dispositivos de backup/recuperação para permitir conexões com o intervalo CIDR 199.36.153.8/30 na porta TCP 443.

Configurações de firewall

As seguintes regras de firewall necessárias para entrada no serviço de backup e DR são adicionadas automaticamente.

Para mais detalhes sobre como configurar essa regra, consulte Preparar para implantar o serviço de backup e DR.

Para qualquer host que esteja executando o agente do Backup and DR, adicione manualmente a seguinte porta TCP para permitir a conectividade com uma regra de firewall de entrada.

Para hosts que usam NFS para tráfego de backup ou hosts ESX executados no VMware Engine que usam NFS para montagens, adicione manualmente as seguintes portas TCP e UDP para permitir a conectividade com uma regra de firewall de entrada.

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 compatíveis com o console de gerenciamento e os dispositivos de backup/recuperação.

Regiões compatíveis com o console de gerenciamento

Embora o serviço de 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 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
	europe-north1	Finlândia	Baixo CO2
	europe-southwest1	Madri	Baixo CO2
	europe-west1	Bélgica	Baixo CO2
	europe-west2	Londres	CO2 baixo
	europe-west3	Frankfurt	Baixo CO2
	europe-west4	Países Baixos	Baixo CO2
	europe-west6	Zurique	Baixo CO2
	europe-west8	Milão
	europe-west9	Paris	Baixo CO2
	europe-west10	Berlim	Baixo CO2
	europe-west12	Turim
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, Montreal e Osaka têm três zonas instaladas em um ou dois data centers físicos. Em caso de desastre, os dados armazenados nessas regiões podem ser perdidos.

Regiões compatíveis com o dispositivo de backup/recuperação

Os dispositivos de backup/recuperação podem ser implantados em qualquer Google Cloud zona.

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 appliance de backup/recuperação foi implantado, o serviço de Backup e DR vai executar o fluxo de trabalho na região us-central1. O appliance 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 essa 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 appliance de backup/recuperação.

A seguir

• Preparar a implantação do serviço de backup e DR