Práticas recomendadas de política de plano de backup

Seguir essas práticas recomendadas ajuda a evitar alguns dos erros mais comuns que os usuários cometem ao criar e modificar modelos de políticas.

É necessário configurar os modelos de políticas de acordo com os objetivos de ponto de recuperação (RPOs) e de tempo de recuperação (RTOs). Com o tempo, talvez seja necessário fazer mudanças nesses modelos.

Captura inicial de backup de dados

Na primeira vez que uma política em um modelo de política cria um backup dos dados de um aplicativo, ela faz o backup de todos os dados. Os backups subsequentes serão incrementais.

Para proteger vários aplicativos com um modelo de política, aplique o modelo de política a apenas alguns dos aplicativos. Depois que a captura inicial de dados for concluída, aplique o modelo de política a mais aplicativos. Repita o processo até que o modelo de política seja aplicado a todos os aplicativos.

Redimensionar volumes

Se você redimensionar um volume que contém dados protegidos, para alguns tipos de aplicativo, na próxima vez que a política de snapshots para esse volume for executada, ele poderá realizar uma operação de backup completa, independentemente de quantas vezes os dados desse volume foram salvos em backup no passado. Isso inclui VMDKs VMWare redimensionados e backups baseados em agentes de aplicativos Microsoft Windows e Linux que não estão no LVM.

Se você precisar redimensionar um volume para esses tipos de aplicativo afetados, considere o impacto que a captura de todos os dados terá nos servidores de aplicativos, na rede e no dispositivo de backup/recuperação.

Simultaneidade de jobs

Por padrão, um dispositivo de backup/recuperação pode executar seis jobs de snapshot simultaneamente. Se você tiver mais do que o número permitido de jobs programados para o mesmo período, o agendador de políticas vai iniciar o máximo de jobs permitidos e colocar os outros na fila.

Como o design de rede, o layout de dados e as classes de armazenamento de cada usuário são diferentes, teste a simultaneidade até atingir o número ideal de jobs simultâneos.

Programações de políticas

O Console de gerenciamento oferece suporte a dois métodos para especificar uma programação de políticas ao configurar uma política:

  • Com janela. Define uma programação de backup de snapshot discreta de acordo com uma frequência e janela de tempo específicas. Por exemplo, faça um backup a cada 30 minutos, diariamente, das 9h às 17h UTC. É possível instruir o dispositivo de backup/recuperação para executar vários jobs de backup em um intervalo de frequência especificado ou uma vez durante uma janela de tempo especificada.
  • Continuamente. Define uma programação contínua de backup de snapshot. Por exemplo, executa um trabalho de backup a cada oito horas, iniciando o primeiro às 01:00 UTC. Nessa programação de políticas, os jobs são executados continuamente (24 horas por dia) no intervalo de tempo especificado.

Cálculo da frequência

O período é o tempo entre as execuções programadas, e a frequência é o número de jobs executados por unidade de tempo. Por exemplo, se uma programação exigir que os jobs sejam executados a cada 4 horas, o período será de 4 horas e a frequência esperada será de 6 vezes por dia. Se um job levar uma hora para ser concluído e a política tiver uma frequência de 12 horas, o job da política será executado novamente 11 horas após a conclusão do job anterior.

Selecione uma frequência que atenda aos seus objetivos de ponto de recuperação (RPOs) e permita tempo suficiente para que um job seja concluído.

  • A frequência mínima recomendada para uma política de snapshots é de 1 hora (RPO local).
  • Uma política do StreamSnap pode apontar para qualquer política de snapshot com frequência de 1 hora ou mais (RPO remoto).

Proteção de registro de banco de dados em uma política de plano de backup

Ao criar uma política de snapshots para um banco de dados, você tem a opção de capturar os arquivos de registro com uma frequência especificada. A frequência em que os registros do banco de dados são capturados é definida separadamente da do banco de dados. Por exemplo, um banco de dados pode ser capturado todos os dias, e os logs dele a cada hora.

A frequência do backup de registro do banco de dados é definida em minutos, e a frequência em que os registros são capturados não pode exceder a frequência em que o banco de dados associado é capturado. Por exemplo, se a frequência de captura de um banco de dados for a cada 24 horas, a frequência de captura de arquivos de registro precisa ser menor que 24 horas.

A frequência e a retenção são definidas nas configurações avançadas da política de snapshots do banco de dados. A captura de registros é feita sem considerar os limites do dia, a janela ou a frequência em que o banco de dados associado é capturado.

Você ativa o recurso de proteção de registro nas configurações avançadas Ativar o backup de registro do banco de dados em uma política de snapshot do plano de backup. A frequência e a retenção também são definidas nas configurações avançadas de uma política de plano de backup.

O espaço físico necessário para acomodar os registros de um banco de dados é gerenciado automaticamente pelo console de gerenciamento. No mínimo, o console de gerenciamento vai avaliar os tamanhos de registro típicos e o período de armazenamento deles e adicionar espaço conforme necessário.

Para ativar o backup de registro e gerenciar os requisitos de armazenamento de registros de banco de dados de maneira mais eficiente, consulte esta tabela.

Configuração Entrada
Trunca ou exclui o registro após o backup Obrigatório definir como "Sim" para limpar o registro de produção. Para gerenciar a exclusão de registros, selecione esta opção. Isso vai executar a limpeza de registros no final de cada backup de registro. O padrão é "Não truncar".

Se uma política com Enable database log backup estiver definida como Não e se Truncate or purge log after backup estiver definido como Sim, a limpeza de registro será executada no final de cada backup do banco de dados, limpando todos os registros.
Período de retenção de backup de registro O backup de registro em "Backup and DR staging disk" será retido para o valor definido aqui. A retenção de registro de backup pode ser diferente da retenção de snapshot.
Tamanho do crescimento do disco de registro de aprovisionamento Defina uma porcentagem para aumentar o disco de preparação de backup de registro quando necessário.
Taxa de mudança estimada Estimar a porcentagem de mudança diária dos dados do banco de dados.
Compactar o backup de registro do banco de dados Use isso para ativar o backup de registro do banco de dados no modo de compactação usando a API do banco de dados no nível do app.
Ativar o backup de registro do banco de dados A opção Ativar o backup de registro do banco de dados permite que a política de plano de backup faça backup de um banco de dados e de todos os arquivos de registro associados. Os registros são armazenados em backup quando o job de backup de registro é executado. As opções são Sim ou Não. Quando definido como "Sim", as opções relacionadas são ativadas.
RPO Quando a opção "Ativar o backup de registro do banco de dados" está definida como "Sim", o RPO define a frequência do backup de registro do banco de dados. A frequência é definida em minutos e não pode exceder o intervalo de backup do banco de dados.
Replicar registros (Uso da tecnologia StreamSnap) Quando a opção "Ativar o backup de registro de banco de dados" está definida como "Ativar", a configuração avançada "Replicate Logs" permite que os backups de registro de banco de dados sejam replicados para um dispositivo de recuperação/backup remoto. Para que um job de replicação de backup de registro seja executado, é necessário incluir uma política de replicação do StreamSnap no modelo, além de um perfil de recurso que especifique um dispositivo de backup/recuperação remoto. Além disso, pelo menos uma replicação bem-sucedida do banco de dados precisa ser concluída. Em seguida, use o backup de registro no site remoto para qualquer imagem de banco de dados dentro do intervalo de retenção do backup de registro replicado. Essa função é ativada por padrão.

A replicação de registro usa a tecnologia StreamSnap para realizar a replicação entre os dispositivos de backup/recuperação locais e remotos. A replicação de registro vai diretamente do pool de snapshots local para o pool de snapshots no dispositivo remoto.

Observação: a replicação de registros não ocorre até que o banco de dados seja protegido e a imagem de backup do banco de dados seja replicada para o dispositivo remoto de backup/recuperação.
Enviar registros para o OnVault Pool Se definido como "Sim", os registros serão replicados para um ou mais pools de armazenamento do OnVault, permitindo recuperações de ponto no tempo de um pool do OnVault em outro site.

Prioridade e programação de jobs

Todas as atividades são executadas como jobs. Os jobs são executados de acordo com as programações configuradas quando as políticas foram criadas.

Alguns jobs levam muito mais tempo do que outros. Os jobs de expiração são rápidos. Os jobs de snapshot dependem de variáveis, como o tamanho do aplicativo ou da VM e a quantidade de dados que mudaram desde o último snapshot. O snapshot inicial de qualquer aplicativo ou VM é composto por dados totalmente novos, portanto, pode levar muito tempo.

O programador de políticas identifica quando uma ou mais políticas aplicadas a aplicativos devem ser executadas e inicia um job que coloca a política em uma fila quando o horário de início programado ocorre. Para cada tipo de política, há um mecanismo de ritmo para garantir que o sistema não fique sobrecarregado com jobs em execução. Esse mecanismo de ritmo usa slots de job para alcançar esse estado estável, o que significa que, mesmo que um job precise começar em um horário específico, ele só será executado quando um slot de job estiver disponível.

Se vários aplicativos forem programados para serem executados ao mesmo tempo com a mesma prioridade de job, a seleção do aplicativo a ser executado será aleatória para garantir a justiça entre todos os aplicativos que têm a mesma prioridade.

Novas tentativas de jobs

Quando um job falha, o programador tenta executar o job novamente de forma automática. Na primeira vez que o job falhar, o programador vai aguardar 4 minutos antes de deixá-lo disponível para repetição. Após três tentativas de job com falha, o job é marcado como "Falha" e não é mais tentado novamente. A próxima tentativa de job será feita de acordo com a programação da política.

O programador vai tratar uma nova tentativa de execução como qualquer outro job disponível. Se houver mais jobs disponíveis do que slots para acomodá-los, os jobs serão colocados em fila. Isso pode fazer com que uma nova tentativa falhe ao iniciar na janela e o job seja marcado como com falha.

As tentativas de repetição de jobs são informadas no Monitor. Para identificar as novas tentativas de jobs, o Monitor anexa primeiro a, depois b e, por fim, c ao nome de cada job de nova tentativa.

A seguir