Nesta página, descrevemos os planos de backup, que permitem definir estratégias avançadas para fazer backup das instâncias do Cloud SQL e do Compute Engine e dos discos do Compute Engine.
Em um plano de backup, você pode definir quando e como fazer backup de um recurso. Você pode incluir a frequência do backup, o período de armazenamento do backup e o backup vault local para armazenar backups. Quando você associa um plano de backup a um recurso, o Backup e DR faz backup e mantém os backups desses recursos automaticamente de acordo com a configuração no plano de backup.
Antes de criar um plano de backup, é necessário designar o local de armazenamento dos backups. Para isso, crie um backup vault.
Um plano de backup tem regras de backup, em que o seguinte se aplica:
- Uma ou mais regras de backup podem ser usadas.
É possível definir a frequência de criação de backup: por hora, diária, semanal, mensal ou anual.
- Os backups por hora têm frequências diferentes (com que frequência o job pode ser executado) com base no tipo de recurso de dados que está sendo armazenado. Consulte Intervalos de frequência para backups por hora
- Para backups semanais, escolha um dia da semana para a regra.
- Para backups mensais, escolha um dia específico do mês para a regra. Por exemplo, o dia 15 do mês.
Você pode usar para backups programados ou sob demanda.
Inclui uma janela de backup em que é possível definir o período específico de quando os jobs de backup podem começar. A janela de backup usa o seguinte:
- Formato de relógio de 24 horas, com horários de início e término entre 00 e 24 horas.
- No mínimo, seis horas para a janela.
O plano de backup sempre inclui o disco de inicialização, mesmo que a opção Excluir disco de inicialização esteja marcada na seção Proteção de dados da Configuração da máquina, detalhada em Criar uma instância com outros discos que não são de inicialização.
Intervalos de frequência para backups por hora
Especifica a frequência dos backups por hora. Uma frequência horária de 1 significa que os jobs serão executados a cada 1 hora, do horário de início até o horário de término.
Isso é necessário quando "recurrence_type" é definido como "HOURLY" e não se aplica de outra forma. Um erro de validação vai ocorrer se um valor for fornecido e
recurrence_type não for HOURLY.
Os valores aceitos para cada tipo de recurso são os seguintes:
| Tipo de recurso | Frequência horária |
|---|---|
| Instância do Compute Engine | 4-23 |
| Disco do Compute Engine | 1-23 |
| Instância do Cloud SQL | 6-23 |
| Cluster do AlloyDB para PostgreSQL | 1-23 |
| Instância do Filestore | 1-23 |
Visão geral da retenção de dados no serviço de Backup e DR
O serviço de Backup e DR usa dois tipos de retenção para gerenciar ciclos de vida de backup e segurança:
- Cada backup é mantido por um período atribuído no plano de backup e expira no final desse período. Os backups podem ser excluídos manualmente antes da data de validade definida na configuração Excluir backups após do plano de backup.
Você pode garantir que alguns backups não sejam excluídos por um determinado período armazenando-os em um cofre de backup com um valor "Impedir exclusão por" definido na seção Período de retenção obrigatório da configuração do cofre de backup.
- É possível definir um período de armazenamento obrigatório maior do que a configuração Excluir backups após no plano de backup. Os backups não serão excluídos até que o período de armazenamento obrigatório termine.
- É possível definir o período de armazenamento obrigatório para um backup vault inteiro ou fazer com que o backup vault aplique o valor Excluir backups após no plano de backup para cada recurso de dados protegido no vault.
Consumo de armazenamento de backup
Em um plano de backup, considere o seguinte para o armazenamento de backup.
- Os backups são excluídos automaticamente após o período de armazenamento definido ser atingido.
- O valor padrão para exclusão de backup é herdado do período de armazenamento mínimo do backup vault usado para armazenar esses backups.
- Os períodos de armazenamento de backup não podem ser menores que o período mínimo de armazenamento do backup vault. Eles precisam ser iguais ou maiores.
- Os backups criados com um plano de backup são sempre imutáveis e, portanto, não podem ser modificados ou excluídos durante o período mínimo de armazenamento aplicado do backup vault.
Fazer backup de cargas de trabalho em um backup vault ativado para CMEK
Depois que um backup vault é configurado com CMEK, os backups armazenados nele são protegidos usando a chave especificada. As regras a seguir se aplicam ao associar um plano de backup a um vault com CMEK:
- Workloads com CMEK: se uma workload de origem for protegida por CMEK (por exemplo, uma instância do Compute Engine com discos criptografados por CMEK), ela precisa ser armazenada em backup em um cofre de backup ativado para CMEK. Não é possível fazer backup de um recurso protegido por CMEK em um backup vault que usaGoogle-owned and Google-managed encryption keys.
- Cargas de trabalho com Google-owned and Google-managed encryption keys: se uma carga de trabalho de origem usar Google-owned and Google-managed encryption keys, ela precisa ser armazenada em backup em um backup vault que use Google-owned and Google-managed encryption keys.
Regiões compatíveis com o plano de backup
Os planos de backup só podem ser criados nas regiões em que o Backup e DR está disponível e onde os recursos a serem armazenados estão localizados. Para criar um plano de backup, um backup vault também precisa estar disponível em um local compatível. Para criar um plano de backup nas regiões sem suporte, use os modelos de backup no console de gerenciamento do dispositivo.
O plano de backup está disponível 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-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 | ||
europe-west9 |
Paris |
Baixo CO2
|
|
europe-west10 |
Berlim | ||
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 (northamerica-south1), Montreal (northamerica-northeast1) e Osaka (asia-northeast2) não oferecem suporte à separação de zonas. Isso significa que as várias zonas em 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.
Nomes de planos e regras de backup
Os nomes dos planos de backup e das regras precisam atender aos seguintes requisitos:
- Conter letras minúsculas, caracteres numéricos, traços (
-), sublinhados (_) e pontos (.). Não é permitido usar espaços. - Começar e terminar com um número ou uma letra
- Máximo de 63 caracteres
- Não pode ser representado como um endereço IP na notação decimal com pontos. Exemplo:
192.0.2.255