Esta página descreve como fazer a ativação inicial do serviço de cópia de segurança e recuperação de desastres e configurar as configurações para o seu projeto.
Componentes da arquitetura de cópia de segurança e RD
A arquitetura do serviço de cópia de segurança e RD é fornecida através dos seguintes componentes:
Consola de gestão: a consola de gestão funciona como o plano de gestão para os seus dispositivos de cópia de segurança/recuperação. Cada implementação do Backup and DR inclui uma única consola de gestão que gere qualquer número de dispositivos de cópia de segurança/recuperação. A consola de gestão é implementada no projeto de administração de cópias de segurança e está altamente disponível na região implementada, o que oferece resiliência contra interrupções zonais.
Dispositivos de cópia de segurança/recuperação: o dispositivo de cópia de segurança/recuperação é o responsável pela movimentação de dados que captura, move e gere de forma eficiente o ciclo de vida dos dados de cópia de segurança na sua empresa. Os dispositivos de cópia de segurança/recuperação são implementados na entidade de carga de trabalho para cargas de trabalho na nuvem.
Agentes de cópia de segurança e recuperação de desastres (DR): o agente de cópia de segurança e DR chama as APIs nativas da aplicação para capturar dados de forma eficiente das aplicações de produção de forma incremental para sempre e fornece a deteção de aplicações no momento da recuperação. O agente é instalado em anfitriões de aplicações onde residem as aplicações a proteger. Se estiver a proteger apenas a VM completa ou um subconjunto dos respetivos discos, o agente do Backup and DR não é necessário.
A consola de gestão é ativada numa rede VPC do produtor de serviços. Esta VPC do produtor de serviços comunica com o seu projeto através do acesso privado à Google.
A comunicação entre o servidor de gestão e os aparelhos, entre aparelhos e entre aparelhos e agentes anfitriões é protegida pela autenticação TLS mútua.
Considerações relacionadas com a implementação
Seguem-se algumas considerações importantes que afetam a forma como implementa o serviço de cópia de segurança e recuperação de desastres:
Quais são os requisitos do objetivo de tempo de recuperação (OTR) da sua organização? O RTO é o período máximo durante o qual pode ficar sem os seus dados. Por exemplo, se o seu RTO for de 4 horas,tem de conseguir aceder aos seus dados no prazo de 4 horas após um desastre.
Precisa de centralizar a gestão das suas cópias de segurança? Tem de decidir se quer gerir as suas cópias de segurança de forma centralizada ou não.
- A gestão de cópias de segurança centralizada significa que tem uma única consola de gestão para gerir as cópias de segurança de todas as suas cargas de trabalho em todas as linhas de negócio. Esta pode ser uma forma mais eficiente de gerir as cópias de segurança, uma vez que só precisa de gerir uma única consola de gestão.
- A gestão de cópias de segurança descentralizada significa que tem uma consola de gestão separada para cada linha de negócio. O modo de funcionamento varia de organização para organização.
Qual é o seu exemplo de utilização da cópia de segurança? Precisa de cópias de segurança para estar preparado para a recuperação de desastres no caso de um desastre numa região de produção ou é suficiente proteger os seus dados localmente? Se precisar de capacidade de recuperação de desastres, tem de considerar as cópias de segurança entre regiões. Isto significa armazenar as suas cópias de segurança em vários locais, para que, se um local for afetado por um desastre, os seus dados continuem acessíveis.
As cargas de trabalho estão numa única região
A melhor estratégia de cópia de segurança numa região depende das suas necessidades.
Se não precisar de recuperação de desastres (RD)
Para um desempenho mais rápido e um custo mais baixo, implemente a consola de gestão e os dispositivos de cópia de segurança/recuperação na mesma região onde as suas cargas de trabalho estão a ser executadas. Armazene as imagens de cópia de segurança na mesma região que as suas cargas de trabalho.
Se também quiser ter cópias de segurança fora do local, pode armazenar cópias de segurança numa região diferente ou usar o armazenamento de duas regiões ou multirregional. O armazenamento de cópias de segurança numa região diferente incorre em custos de rede e armazenamento.
Se precisar de cópia de segurança e RD
Para um desempenho mais rápido e um custo mais baixo, implemente uma consola de gestão na mesma região que a região da carga de trabalho de produção e uma segunda consola de gestão na região que pode usar para recuperação de desastres.
Implemente aplicações de cópia de segurança/recuperação na região da carga de trabalho de produção e na região de recuperação de desastres para minimizar o objetivo de tempo de recuperação (RTO). Isto garante que um ambiente de recuperação de desastres está totalmente pré-aprovisionado e disponível em caso de desastre.
Armazene imagens de cópia de segurança na região de produção e uma cópia na região de recuperação de desastres RD ou use armazenamento em duas regiões ou multirregional. A cópia de segurança da região de produção pode satisfazer as necessidades de cópia de segurança de rotina com um desempenho mais rápido. Os dados copiados para a sua região de recuperação de desastres podem ser usados para recuperar as suas 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 cópia de segurança em várias regiões depende das suas necessidades.
Se não precisar de recuperação de desastres (RD)
Para um desempenho mais rápido e um custo mais baixo, implemente a consola de gestão numa das regiões onde as suas cargas de trabalho estão a ser executadas. Isto permite a gestão centralizada em todas as cargas de trabalho e regiões.
Implemente um ou mais dispositivos de cópia de segurança/recuperação em cada região onde as cargas de trabalho estão a ser executadas. Armazene as suas cópias de segurança na mesma região que as suas cargas de trabalho.
Se também quiser ter cópias de segurança fora do local, pode armazenar cópias de segurança numa região diferente ou usar o armazenamento de duas regiões ou multirregional. O armazenamento de cópias de segurança numa região diferente ou em várias regiões incorre em custos de rede e de armazenamento.
Se precisar de cópia de segurança e RD
Implemente uma consola de gestão em cada uma das regiões de carga de trabalho de produção e outra consola de gestão na região de RD.
Implemente aplicações de cópia de segurança/recuperação nas regiões de carga de trabalho de produção e na região de recuperação de desastres para minimizar o objetivo de tempo de recuperação (RTO). Isto garante que um ambiente de recuperação de desastres está totalmente pré-aprovisionado e disponível em caso de desastre.
Armazene cópias de segurança na região da carga de trabalho de produção e uma cópia na região de recuperação de desastres ou use armazenamento em duas regiões ou multirregional. A cópia de segurança da região de produção pode ser usada para satisfazer as necessidades de cópia de segurança.
Pode usar uma imagem de substituição na recuperação de desastres para recuperar cargas de trabalho se a região de produção estiver inativa.
Configure o serviço de cópias de segurança e RD na consola Google Cloud
Aceda à Google Cloud consola para ativar a API Backup and DR Service e configurar as autorizações para a sua conta:
Ative o Google Cloud Backup and DR
Tipos de dispositivos de cópia de segurança/recuperação
O serviço de cópia de segurança e recuperação de desastres oferece tipos de dispositivos otimizados para diferentes cargas de trabalho: VMs do Compute Engine, VMs VMware, bases de dados e sistemas de ficheiros. Pode escolher o tipo de dispositivo que melhor se adequa às suas necessidades. É importante selecionar o melhor tipo de dispositivo para as suas cargas de trabalho. Assim que o dispositivo de cópia de segurança/recuperação estiver em serviço, é executado continuamente para sempre, estando sempre pronto para executar e voltar a executar cópias de segurança, restaurar e outras tarefas em qualquer altura.
O serviço de cópia de segurança e RD oferece os seguintes tipos de dispositivos:
- Padrão para VMs do Compute Engine ou bases de dados SAP HANA: selecione esta opção se quiser fazer uma cópia de segurança apenas de instâncias do Compute Engine ou de bases de dados SAP HANA através do Persistent Disk. Por predefinição, este dispositivo adiciona um tipo de máquina e2-standard-4 com uma capacidade mínima do disco persistente de 10 GB. Este dispositivo pode gerir até 5000 VMs do Compute Engine.
- Padrão para VMs VMware e outras bases de dados ou recursos: selecione esta opção se quiser uma configuração padrão que suporte o desempenho ideal para fazer cópias de segurança de bases de dados, VMs VMware e outros recursos. Por predefinição, este dispositivo adiciona um tipo de máquina n2-standard-16. Isto adiciona 4 TB de capacidade de disco equilibrada como capacidade de disco mínima. Este dispositivo pode gerir até 1500 aplicações.
Básico para VMs VMware e outras bases de dados ou recursos: selecione esta opção se quiser ter uma configuração básica que suporte um desempenho moderado para fazer cópias de segurança de bases de dados, VMs VMware e outros recursos. Por predefinição, este dispositivo adiciona um tipo de máquina e2-standard-16. Este dispositivo pode gerir até 1500 aplicações. Pode escolher qualquer um dos seguintes tipos de disco para armazenar os seus dados.
- Disco persistente de capacidade mínima: esta opção oferece uma capacidade mínima do disco de 10 GB. Neste tipo de armazenamento, as cópias de segurança são armazenadas como instantâneos do Persistent Disk e não consomem o armazenamento local do dispositivo de cópia de segurança/recuperação.
- Disco persistente padrão: selecione este tipo de armazenamento se quiser ter um armazenamento de blocos eficiente. Isto é recomendado para VMs, bases de dados ou aplicações de sistema de ficheiros do Google Cloud VMware Engine com E/S média a elevada, além das VMs do Compute Engine. Isto adiciona 4 TB de capacidade do disco persistente como a capacidade mínima do disco.
- Disco persistente SSD: selecione este tipo de armazenamento se quiser ter armazenamento de blocos rápido. Isto é recomendado para o Google Cloud VMware Engine, bases de dados ou aplicações de sistemas de ficheiros com E/S muito elevadas, além das VMs do Compute Engine. Isto adiciona 4 TB de capacidade do disco persistente como a capacidade mínima do disco.
Quando implementa um dispositivo, é criada automaticamente uma conta de serviço, independentemente do tipo de dispositivo. Pode ver a conta de serviço na página Conta de serviço.
O nome da conta de serviço é apresentado no formato de endereço de email: 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 .
Escolha um tipo de armazenamento
A aplicação de cópia de segurança/recuperação armazena dados de cópia de segurança no conjunto de instantâneos da aplicação local. Pode copiá-lo para o armazenamento de objetos para retenção a longo prazo. Google Cloud oferece os três tipos seguintes de armazenamento de objetos local:
Persistent Disk de capacidade mínima: as imagens de cópia de segurança são armazenadas como instantâneos do Persistent Disk que não consomem o armazenamento local do dispositivo de cópia de segurança/recuperação.
Disco persistente padrão: este tipo de armazenamento oferece armazenamento de blocos eficiente, começando com um disco persistente de 4 TB. Isto é recomendado para motores VMware e aplicações de base de dados ou sistema de ficheiros com E/S média a alta.
Disco persistente SSD: este tipo de armazenamento oferece armazenamento em blocos rápido, começando com um disco persistente de 4 TB. Isto é recomendado para Google Cloud VMs do VMware Engine e aplicações de base de dados ou sistema de ficheiros com E/S muito elevada.
Pode expandir a capacidade dos seus conjuntos de discos mais tarde.
Pode mover as cópias de segurança com necessidades de retenção a longo prazo para o armazenamento Google Cloud Standard, Nearline e Coldline, consoante a sua necessidade esperada de aceder aos dados.
Topologia de rede recomendada para o serviço de cópia de segurança e RD
Google Cloud recomenda a utilização da VPC partilhada durante a implementação do serviço de cópia de segurança e recuperação de desastres. A VPC partilhada permite que uma organização ligue recursos de vários projetos a uma rede VPC (VPC) comum, para que possam comunicar entre si de forma segura e eficiente através de IPs internos dessa rede. Quando usa a VPC partilhada, designa um projeto como um projeto anfitrião e anexa-lhe um ou mais projetos de serviço. As redes VPC no projeto anfitrião são denominadas redes VPC partilhadas. Os recursos elegíveis dos projetos de serviço podem usar sub-redes na rede de VPC partilhada.
A VPC partilhada permite que os administradores da organização deleguem responsabilidades administrativas, como a criação e a gestão de instâncias, aos administradores de projetos de serviço mantendo o controlo centralizado sobre os recursos de rede, como sub-redes, rotas e firewalls.
A consola de gestão é ativada numa rede VPC do produtor de serviços VPC. Esta VPC do produtor de serviços comunica com o seu projeto através do acesso privado à Google. O objetivo principal desta ligação é permitir que a consola de gestão e os dispositivos de cópia de segurança/recuperação troquem metadados. O tráfego de cópia de segurança não atravessa este link. No entanto, uma consola de gestão tem de comunicar com todos os dispositivos de cópia de segurança/recuperação implementados em qualquer rede.
Práticas recomendadas para a VPC partilhada
Recomendamos as seguintes práticas recomendadas:
Estabelecer ligação à consola de gestão: é melhor ligar a rede do fornecedor de serviços a uma VPC partilhada na sua rede. Todo o tráfego da consola de gestão flui através desta VPC e, por conseguinte, através do projeto anfitrião. O aprovisionamento da conetividade ao serviço de cópia de segurança e recuperação de desastres através de uma VPC partilhada também permite uma ligação perfeita entre os projetos onde as cargas de trabalho estão a ser executadas (projetos de serviço) e o serviço de cópia de segurança e recuperação de desastres.
Localização do dispositivo de cópia de segurança/recuperação: os dispositivos de cópia de segurança/recuperação têm de ser implementados numa sub-rede que tenha o acesso privado à Google ativado para a conetividade à consola de gestão. Existem duas estratégias recomendadas para selecionar os projetos para os dispositivos de cópia de segurança/recuperação:
No projeto anfitrião central: nesta estratégia, o serviço de cópia de segurança e recuperação de desastres é tratado como um serviço central de TI. A equipa de cópia de segurança central rege o aprovisionamento do serviço. Como tal, todos os dispositivos de cópia de segurança/recuperação são aprovisionados no projeto anfitrião, o que permite aos administradores centrais consolidar todos os recursos de cópia de segurança num projeto central. Esta abordagem tem a vantagem de consolidar todos os recursos relacionados com a cópia de segurança e a respetiva faturação num único projeto.
Em projetos de serviço: esta estratégia é adequada para equipas mais descentralizadas, onde os projetos de serviço são criados e a respetiva gestão é delegada em equipas distribuídas. Neste cenário, a prática recomendada é aprovisionar a VPC para projetos de serviços a jusante. Os dispositivos de cópia de segurança/recuperação são instalados nos projetos de serviço nestas VPCs. Isto permite a colocação conjunta da carga de trabalho e do dispositivo de cópia de segurança/recuperação num único projeto.
Acesso privado do Google: é uma prática recomendada ativar o Acesso privado do Google para cada sub-rede onde instala um dispositivo de cópia de segurança/recuperação. Isto garante que o dispositivo de cópia de segurança/recuperação pode comunicar com APIs, como o Compute Engine, o Cloud Storage e o Cloud Logging, o que é importante para a monitorização e os alertas funcionarem. Para simplificar e melhorar as ligações às Google Cloud APIs, considere configurar a resolução de DNS para
private.googleapis.com, conforme documentado na secção Resumo das opções de configuração. Além disso, configure as regras de firewall dos dispositivos de cópia de segurança/recuperação para permitir ligações ao intervalo CIDR199.36.153.8/30na porta TCP443.
Configurações da firewall
As seguintes regras de firewall necessárias para a entrada no serviço de cópia de segurança e recuperação de desastres são adicionadas automaticamente.
| Finalidade | Origem | Destino | Porta (TCP) |
|---|---|---|---|
| Tráfego de apoio técnico (apoio técnico ao dispositivo) | Anfitrião que executa o cliente SSH | Dispositivo de cópia de segurança/recuperação | 26 |
| Cópia de segurança iSCSI (do anfitrião para o dispositivo) | Anfitrião que executa o agente de cópia de segurança e RD | Dispositivo de cópia de segurança/recuperação | 3260 |
| Tráfego do StreamSnap (aparelho para aparelho) | Dispositivo de cópia de segurança/recuperação | Dispositivo de cópia de segurança/recuperação | 5107 |
| Conetividade da aplicação de cópia de segurança/recuperação à consola de gestão | IP ou sub-rede do dispositivo de cópia de segurança/recuperação | *.backupdr.googleusercontent.com | 443 |
Para mais detalhes sobre como configurar esta regra, consulte o artigo Prepare-se para implementar o serviço de cópia de segurança e recuperação de desastres.
Para qualquer anfitrião que esteja a executar o agente de cópia de segurança e recuperação de desastres, tem de adicionar manualmente a seguinte porta TCP para permitir a conetividade com uma regra de firewall de entrada.
| Finalidade | Origem | Destino | Porta (TCP) |
|---|---|---|---|
| Tráfego do agente (dispositivo para anfitrião) | Dispositivo de cópia de segurança/recuperação | Anfitrião que executa o agente de cópia de segurança e RD | 5106 |
Para anfitriões que usam NFS para tráfego de cópia de segurança ou para anfitriões ESX em execução no VMware Engine que usam NFS para montagens, tem de adicionar manualmente as seguintes portas TCP e UDP para permitir a conetividade com uma regra de firewall de entrada.
| Finalidade | Origem | Destino | Porta (TCP/UDP) |
|---|---|---|---|
| Cópia de segurança ou montagem NFS | Anfitrião com o agente em execução ou anfitrião ESXi com a montagem em execução | Dispositivo de cópia de segurança/recuperação | 111, 756, 2049, 4001, 4045 |
Para ver uma lista das autorizações usadas durante esta operação, consulte a referência de autorizações de instalação de cópias de segurança e recuperação de desastres.
Regiões suportadas
A secção seguinte apresenta as regiões suportadas pela consola de gestão e pelos dispositivos de cópia de segurança/recuperação.
Regiões suportadas pela consola de gestão
Embora o serviço de cópias de segurança e RD possa ser usado para fazer cópias de segurança de cargas de trabalho suportadas em qualquer Google Cloud região, a consola de gestão só pode ser ativada nas seguintes regiões:
| Área geográfica | Nome da região | Descrição da região | |
|---|---|---|---|
| América do Norte | |||
northamerica-northeast1 * |
Montréal |
 Baixo CO2
|
|
northamerica-northeast2 |
Toronto |
Baixo CO2
|
|
us-central1 |
Iowa |
Baixo CO2
|
|
us-east1 |
Carolina do Sul | ||
us-east4 |
Virgínia do Norte | ||
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 |
Madrid |
Baixo CO2
|
|
europe-west1 |
Bélgica |
Baixo CO2
|
|
europe-west2 |
Londres |
Baixo CO2
|
|
europe-west3 |
Frankfurt | ||
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 | ||
| Médio Oriente | |||
me-central1 |
Doha | ||
me-central2 |
Damã | ||
me-west1 |
Israel | ||
| África | |||
africa-south1 |
Joanesburgo | ||
| Ásia-Pacífico | |||
asia-east1 |
Taiwan | ||
asia-east2 |
Hong Kong | ||
asia-northeast1 |
Tóquio | ||
asia-northeast2 * |
Osaca | ||
asia-northeast3 |
Seul | ||
asia-southeast1 |
Singapura | ||
asia-southeast2 |
Jacarta | ||
australia-southeast1 |
Sydney | ||
australia-southeast2 |
Melbourne | ||
| Índia | |||
asia-south1 |
Mumbai | ||
asia-south2 |
Deli |
* Querétaro, Montreal e Osaka têm cada uma três zonas alojadas num ou dois centros de dados físicos. No caso raro de um desastre, os dados armazenados nestas regiões podem ser perdidos.
Regiões suportadas para a aplicação de cópia de segurança/recuperação
As aplicações de cópia de segurança/recuperação podem ser implementadas em qualquer Google Cloud zona.
O serviço de fluxo de trabalho para realizar a implementação da aplicação de cópia de segurança/recuperação é suportado nas regiões indicadas. Se o serviço Workflow não estiver disponível numa região onde o seu dispositivo de cópia de segurança/recuperação está implementado, o serviço Backup and DR é executado por predefinição na região us-central1 (o próprio dispositivo é criado na região selecionada). Se tiver uma política da organização definida para impedir a criação de recursos noutras regiões, tem de atualizar temporariamente a política da organização para permitir a criação de recursos na região us-central1. Pode restringir a região us-central1 após a implementação do dispositivo de cópia de segurança/recuperação.