Esta página descreve os planos de backup, que permitem definir estratégias avançadas de backup para fazer backup dos seus recursos. É possível usar planos de backup para fazer backup dos seguintes recursos:
Instâncias do Cloud SQL
Instâncias e discos do Compute Engine
Clusters do AlloyDB para PostgreSQL
Instâncias do Filestore
Em um plano de backup, você pode definir quando e como fazer backup de um recurso. Você pode incluir a frequência e o período de armazenamento do backup, além do local do backup vault 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, é preciso designar o local de armazenamento dos backups criando um backup vault.
Um plano de backup inclui uma ou mais regras de backup. Cada regra de backup define os seguintes parâmetros:
Frequência: é possível programar backups para serem executados por hora, diariamente, semanalmente, mensalmente ou anualmente.
Por hora: a frequência disponível depende do tipo de recurso. Para mais informações, consulte Intervalos de frequência para backups por hora.
Semanal: você pode selecionar um dia específico da semana.
Mensal: você pode selecionar um dia específico do mês (por exemplo, o dia 15).
Tipo de backup: é possível usar regras para backups programados ou iniciar backups sob demanda.
Janela de backup: é possível definir o período em que os jobs de backup podem começar. A janela de backup tem os seguintes requisitos:
Ele precisa usar um formato de relógio de 24 horas, com horários de início e término entre 00 e 24.
Ela precisa ter pelo menos seis horas de duração.
Restrição: um plano de backup sempre inclui o disco de inicialização. Se você selecionar Excluir disco de inicialização na seção Proteção de dados da Configuração da máquina, o plano de backup ainda vai incluir o disco de inicialização. Para mais informações, consulte Criar uma instância com discos extras que não são de inicialização.
Intervalos de frequência para backups de hora em hora
Esta seção especifica a frequência dos backups por hora. Uma frequência horária de 1 significa que os jobs são executados a cada hora, do horário de início até o horário de término.
Se
recurrence_typefor definido comoHOURLY, essa configuração será obrigatória.Se
recurrence_typenão forHOURLY, essa configuração não será aplicável.Se você fornecer um valor para essa configuração e
recurrence_typenão forHOURLY, um erro de validação vai ocorrer.
Os valores aceitos para cada tipo de recurso são os seguintes:
| Tipo de recurso | Frequência horária |
|---|---|
| Instância do Compute Engine | 1-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 |
Para recursos de instância do Compute Engine, consulte as práticas recomendadas para backups por hora.
Backups de registros de banco de dados
Para recursos de banco de dados (como Cloud SQL ou AlloyDB), é possível ativar backups de registros no plano de backup. Isso permite a recuperação pontual (PITR) capturando registros de transações entre pontos de backup completo.
Visão geral da retenção de dados no Backup e DR
O Backup e DR gerencia os ciclos de vida e a segurança dos backups usando dois tipos de retenção:
Período de armazenamento atribuído: definido no plano de backup usando a configuração Excluir backups após.
Os backups são retidos por esse período e expiram ao final dele.
É possível excluir backups manualmente antes dessa data, a menos que a retenção obrigatória impeça isso.
Período de armazenamento obrigatório: definido na configuração do backup vault usando a configuração Impedir exclusão por.
Essa configuração garante que os backups não possam ser excluídos durante o período especificado.
Se o período de armazenamento obrigatório for maior que o período de armazenamento atribuído, os backups não serão excluídos até que o período de armazenamento obrigatório termine.
É possível aplicar um período de armazenamento obrigatório a um backup vault inteiro ou configurar o backup vault para obrigar o período de armazenamento atribuído (Excluir backups após) para cada recurso protegido.
Retenção máxima personalizada sob demanda
Essa configuração define o número máximo de dias em que um backup sob demanda (criado manualmente fora do agendamento automático) pode ser retido. Isso evita que os usuários definam períodos de retenção excessivamente longos para snapshots manuais por engano.
Consumo de armazenamento de backup
Considere as seguintes regras para armazenamento de backup em um plano de backup:
Exclusão automática: os backups são excluídos automaticamente quando o período de armazenamento definido é atingido.
Retenção mínima: o período de armazenamento do backup precisa ser igual ou maior que o período de armazenamento mínima do backup vault.
Padrão herdado: o valor padrão para exclusão de backup é herdado do período mínimo de retenção do backup vault.
Imutabilidade: os backups criados com um plano de backup são imutáveis. Eles não podem ser modificados nem excluídos durante o período mínimo de retenção obrigatória do backup vault.
Fazer backup de cargas de trabalho em um backup vault habilitado para CMEK
Se você configurar um backup vault com CMEK, os backups armazenados nele serão protegidos usando a chave especificada. As regras a seguir se aplicam ao associar um plano de backup a um cofre habilitado para CMEK:
Cargas de trabalho protegidas por CMEK: se uma carga de trabalho de origem for protegida por CMEK (por exemplo, uma instância do Compute Engine com discos criptografados com CMEK), faça backup dela em um backup vault habilitado para CMEK. Não é possível fazer backup de um recurso protegido por CMEK em um backup vault que usa Google-owned and Google-managed encryption keys.
Cargas de trabalho que usam Google-owned and Google-managed encryption keys: se uma carga de trabalho de origem usar Google-owned and Google-managed encryption keys, você precisa fazer backup dela em um backup vault que use Google-owned and Google-managed encryption keys.
Novas tentativas de jobs de backup
Quando um job programado falha, o programador tenta executar o job automaticamente até três vezes.
- Primeira falha: status marcado como "Tentado novamente"; aguarda 4 minutos.
- Segunda falha: a próxima nova tentativa é enfileirada após 16 minutos.
- Terceira falha: nova tentativa final enfileirada após 64 minutos.
- Falha final: após quatro tentativas, o status muda para "Falha". Nenhum outro job é tentado para esse período de programação.
As novas tentativas de jobs são informadas em Monitorar > Jobs. Para identificar
novas tentativas, todos os quatro jobs vão compartilhar o mesmo número de job com um
sufixo exclusivo (por exemplo, Job_12345, Job_12345a, Job_12345b).
Regiões compatíveis com planos 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. Se você precisar criar um plano de backup em uma região sem suporte, use os modelos de backup no console de gerenciamento do appliance.
Os planos de backup são compatíveis com as 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 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 e das regras de backup precisam atender aos seguintes requisitos:
- Conter letras minúsculas, caracteres numéricos, traços (
-), sublinhados (_) e pontos (.). Espaços não são permitidos. - 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