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

Nesta página, descrevemos como realizar a ativação inicial do serviço de backup e DR e configurar o 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 plano de gerenciamento dos seus dispositivos de backup/recuperação. Cada implantação de 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, garantindo 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 de forma eficiente 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.

  Aviso: o tipo de máquina ou a configuração do dispositivo de backup/recuperação (CPU, memória) não podem ser alterados após a implantação sem consultar o suporte.
  Além disso, não renomeie o appliance de backup/recuperação após a implantação, pois isso pode inutilizá-lo. Não é possível renomear o dispositivo.

• Agentes de backup e DR: o agente de backup e DR chama as APIs nativas do aplicativo para capturar dados de forma eficiente de aplicativos de produção de maneira incremental e oferecer a consciência do aplicativo no momento da recuperação. O agente é instalado em hosts de aplicativos em que os aplicativos a serem protegidos residem. Se você estiver protegendo apenas a VM inteira ou um subconjunto dos discos, o agente de backup e DR não será necessário.

O console de gerenciamento é ativado em uma rede VPC produtor de serviços. Essa VPC de produtor de serviços se comunica com seu projeto usando o Acesso particular ao Google.

Considerações de implementação

Confira a seguir 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 tempo máximo 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 backup? Você precisa decidir se quer gerenciar seus backups de forma centralizada ou não.

  • O gerenciamento de backup centralizado significa que você tem um único console de gerenciamento para gerenciar backups de todas as 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 backups 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 a preparação de 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. Assim, se um local for afetado por um desastre, os dados ainda estarão 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 precisar de recuperação de desastres (DR)

Para ter a melhor performance e o menor custo, 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 das cargas de trabalho.

Se você também quiser ter cópias de backup off-site, armazene-as em uma região diferente ou use armazenamento dual ou multirregional. O armazenamento de backups em uma região diferente gera cobranças de rede e de armazenamento.

Se você precisar de backup e DR

Para ter a melhor performance e o 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 você pode usar para recuperação de desastres.

Implante dispositivos de backup/recuperação na região 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 seja totalmente provisionado com antecedência e disponível em caso de desastre.

Observação: para otimizar o custo de DR, aguarde a implantação dos dispositivos de backup/recuperação de DR até que você realize a DR.

Armazene imagens de backup na região de produção e uma cópia na região de recuperação de desastre ou use armazenamento dual ou multirregional. A cópia de backup da região de produção pode atender às necessidades de backup de rotina com desempenho mais rápido. Os dados copiados para a região de DR podem ser usados para recuperar as cargas de trabalho caso a região de produção esteja inativa.

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

A melhor estratégia de backup em várias regiões depende das suas necessidades.

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

Observação: uma interrupção regional em que o console de gerenciamento está implantado afeta as operações de backup em outras regiões. Esse é um evento extremamente raro. Se isso não for desejável, use a estratégia em Se você precisar de backup e DR.

Para ter a melhor performance e o menor custo, implante o console de gerenciamento em uma das regiões em que as 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 em execução. Armazene os backups na mesma região das cargas de trabalho.

Se você também quiser ter cópias de backup off-site, armazene-as em uma região diferente ou use armazenamento dual ou multirregional. Armazenar backups em uma região ou multirregional diferente gera cobranças de rede e de 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 console de gerenciamento na região de DR.

Observação: se as regiões de produção e de DR se sobrepõem (por exemplo, a região A é de produção para algumas cargas de trabalho e de DR para outras), é possível usar o mesmo console de gerenciamento para backups de produção e recuperações de DR nessa região.

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 seja totalmente provisionado com antecedência e disponível em caso de desastre.

Observação: para reduzir o custo da DR, você pode implantar os appliances de backup/recuperação mais tarde, quando realizar a DR.

Armazene backups na região de carga de trabalho de produção e uma cópia na região de DR ou use armazenamento dual 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 na 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 do Google Cloud

Acesse o console do Google Cloud para ativar a API Backup and DR Service 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 de 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 dispositivo que melhor atende às suas necessidades. É importante selecionar o melhor tipo de dispositivo para suas cargas de trabalho. Quando o dispositivo de backup/recuperação está em serviço, ele é executado continuamente para sempre, 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 você quiser fazer backup apenas de instâncias do Compute Engine ou bancos de dados SAP HANA usando Persistent Disk. Por padrão, esse appliance 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.
• Padrão 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 suporte a desempenho ideal para fazer backup de bancos de dados, VMs do VMware e outros recursos. Por padrão, esse dispositivo adiciona um tipo de máquina n2-standard-16. Isso adiciona 4 TB de capacidade de disco balanceada como a capacidade mínima de disco. 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 você quiser ter uma configuração básica que ofereça suporte a desempenho moderado para bancos de dados de backup, VMs do VMware e outros recursos. Por padrão, esse dispositivo 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 persistente 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 você quiser ter um armazenamento em blocos eficiente. Isso é recomendado para VMs do Google Cloud VMware Engine, bancos de dados ou apps 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 você quiser ter armazenamento em blocos rápido. Isso é recomendado para o Google Cloud VMware Engine, bancos de dados ou aplicativos de sistemas 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 dispositivo, uma conta de serviço é criada automaticamente, independente do tipo de dispositivo. Você pode 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 [e-mail], em que appliance-name é o nome de um dispositivo e projectid é o ID do seu projeto do Google Cloud .

Escolher um tipo de armazenamento

O dispositivo de backup/recuperação armazena dados de backup no conjunto de snapshots de dispositivo local. Você pode copiá-lo para o armazenamento de objetos para retenção de longo prazo. OGoogle Cloud oferece os três tipos de armazenamento de objetos locais a seguir:

• Disco permanente de capacidade mínima: as imagens de backup são armazenadas como snapshots de 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. Isso é recomendado para motores do VMware e aplicativos de sistema de arquivos ou de banco de dados 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. Isso é recomendado para Google Cloud VMs do VMware Engine e apps de banco de dados ou sistema de arquivos com E/S muito alta.

É 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 Google Cloud com armazenamento padrão, Nearline e Coldline, dependendo da necessidade esperada de acesso aos dados.

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

OGoogle 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 (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.

A VPC compartilhada permite que os administradores da organização deleguem responsabilidades administrativas, como a criação e o gerenciamento de instâncias, para 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 de produtor de serviço VPC. Essa VPC de produtor de serviços se comunica com seu projeto usando o acesso privado do Google. O objetivo principal dessa conexão é permitir que o console de gerenciamento e os aparelhos de backup/recuperação troquem metadados. O tráfego de backup não atravessa este 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 ao 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 para o serviço de backup e DR por meio de uma VPC compartilhada também permite uma conexão seamless entre projetos em que os workloads estão em execução (projetos de serviço) e o serviço de backup e DR.

• Local 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 ao console de gerenciamento. Há duas estratégias recomendadas para selecionar os projetos dos dispositivos de backup/recuperação:

  • No projeto de 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 tem a vantagem de consolidar todos os recursos relacionados ao 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 secundários. O dispositivo de backup/recuperação é instalado 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ê instalar um dispositivo de backup/recuperação. Isso garante que o dispositivo de backup/recuperação possa se comunicar com APIs, como o Compute Engine, o Cloud Storage e o Cloud Logging, o que é importante para que o monitoramento e os alertas funcionem. Para simplificar e melhorar as conexões com as APIs do Google Cloud , considere configurar 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 regras de firewall necessárias a seguir para entrada no serviço de backup e DR são adicionadas automaticamente.

Motivo	Origem	Destino	Porta (TCP)
Suporte ao tráfego (suporte ao dispositivo)	Host com cliente SSH em execução	Dispositivo de backup/recuperação	26
Backup iSCSI (host para dispositivo)	Host em execução com o agente de backup e DR	Dispositivo de backup/recuperação	3260
Tráfego StreamSnap (dispositivo a dispositivo)	Dispositivo de backup/recuperação	Dispositivo de backup/recuperação	5107
Conectividade do dispositivo de backup/recuperação ao console de gerenciamento	IP ou sub-rede do dispositivo de backup/recuperação	*.backupdr.googleusercontent.com	443

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 de backup e DR, é necessário adicionar manualmente a porta TCP a seguir para permitir a conectividade com uma regra de firewall de entrada.

Motivo	Origem	Destino	Porta (TCP)
Tráfego do agente (dispositivo para host)	Dispositivo de backup/recuperação	Host em execução com 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 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.

Motivo	Origem	Destino	Porta (TCP/UDP)
Backup ou montagem do NFS	Host em execução com o agente ou o host ESXi em execução com o mount	Dispositivo de backup/recuperação	111, 756, 2049, 4001, 4045

Para conferir uma lista das permissões usadas durante essa operação, consulte Referência de permissões de instalação de backup e DR.

Regiões compatíveis

A seção a seguir lista as regiões com suporte ao console de gerenciamento e aos dispositivos de backup/recuperação.

Regiões com suporte ao console de gerenciamento

Embora o serviço de backup e DR possa ser usado para fazer backup de workloads com suporte em qualquer Google Cloud , o console de gerenciamento só pode ser ativado nas seguintes regiões. Não é possível mover o console de gerenciamento para uma região diferente.

Área geográfica	Nome da região	Descrição da região
América
	us-central1	Iowa	CO2 baixo
	us-east1	Carolina do Sul
	us-east4	Norte da Virgínia
	us-east5	Columbus
	us-west1	Oregon	Baixo CO2
	us-west2	Los Angeles
	us-west4	Las Vegas
	southamerica-east1	São Paulo	Baixo CO2
Europa
	europe-west1	Bélgica	Baixo CO2
	europe-west2	Londres	CO2 baixo
	europe-west3	Frankfurt	Baixo CO2
	europe-west4	Países Baixos	CO 2 baixo
Ásia-Pacífico
	asia-east1	Taiwan
	asia-southeast1	Singapura
	australia-southeast1	Sydney
Índia
	asia-south1	Mumbai
	asia-south2	Délhi

Regiões com suporte para dispositivos de backup/recuperação

Os dispositivos de backup/recuperação de backup e DR Service 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 tem suporte nas 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 estiver implantado, o serviço de backup e DR vai executar o fluxo de trabalho na região us-central1 (o dispositivo ainda é 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 da organização 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 para implantar o serviço de backup e DR