Configurar as definições avançadas de política no console de gerenciamento do dispositivo

Nesta página, listamos as configurações avançadas de um modelo de política de configuração de backup. É possível definir as configurações de política avançadas ao criar uma política de backup.

Também é possível ver e alterar as configurações de política de aplicativos específicos exibindo o painel de substituições de política na página Gerenciar plano de backup do aplicativo.

Use as instruções a seguir para acessar a página de configurações da política.

  1. No console de gerenciamento do dispositivo, clique na guia Planos de backup e selecione a opção Modelos no menu suspenso.
  2. Selecione o modelo que você quer gerenciar e clique em Editar no menu suspenso no canto inferior direito da página.
  3. Na página do modelo, no lado direito, clique na seta branca ao lado da política que você quer gerenciar. Na parte de baixo das seleções, clique em Editar política.
  4. Na parte de baixo da seção Criar/editar política, clique em Configurações avançadas da política. Isso abre as configurações avançadas de política detalhadas na tabela a seguir.

  5. Quando terminar, clique em Salvar alterações para atualizar as configurações.

A tabela a seguir detalha as configurações de política avançadas.

               
Configuração avançada Descrição
Consistente com o aplicativo
(aplicável apenas a VMs do Google Cloud VMware Engine e do Compute Engine)		 Selecione uma destas opções:
  • Backup consistente com falhas: é um backup rápido de dados de aplicativos no armazenamento, como se a energia tivesse sido perdida naquele momento. Ele não pausa a E/S de dados do aplicativo. Todos os dados no disco são salvos, e os dados na memória são perdidos. A recuperação de um backup consistente com falhas pode levar mais tempo e introduzir exceções. Talvez seja necessário realizar algumas etapas adicionais de recuperação manual durante a recuperação, dependendo do SO convidado, dos sistemas de arquivos e dos aplicativos. Escolha "consistente com falhas" se o processo consistente com o aplicativo causar problemas para seus aplicativos ou cargas de trabalho devido ao processo de desativação. A consistência com falhas pode resultar em um RTO mais longo devido à necessidade de o sistema de arquivos ou o aplicativo realizar uma recuperação do snapshot inconsistente, e pode até resultar em um snapshot irrecuperável em casos extremos.
  • Fazer backup consistente com o aplicativo: o backup consistente com o aplicativo usa snapshots em modo de espera, que usam ferramentas da VMware ou um ambiente convidado do Google Cloud para colocar o sistema de arquivos da máquina virtual em modo de espera. Uma operação de suspensão temporária aproveita os recursos integrados do sistema operacional Windows para suspender temporariamente sistemas de arquivos e aplicativos compatíveis com o VSS. Ele também aproveita os scripts de congelamento ou descongelamento fornecidos pelo cliente (em todas as plataformas) para obter maior consistência de aplicativos. O resultado é um nível de confiança maior na recuperabilidade do backup, além de tempos de recuperação mais curtos na maioria dos casos. Os backups consistentes com o aplicativo às vezes podem causar uma breve pausa na E/S e, embora seja incomum, alguns aplicativos mais ocupados podem relatar erros de E/S no momento do backup. Às vezes, os backups consistentes com o aplicativo falham se o VMware não consegue interromper a VM dentro de um tempo limite predeterminado durante a operação de snapshot. Use backups consistentes com o aplicativo quando a capacidade de recuperação for mais importante e os aplicativos na VM não forem sensíveis à breve pausa de E/S.
    Leia a seção Criar um snapshot de disco permanente consistente com o aplicativo Linux para mais informações.

    Para montar um snapshot do Windows Compute Engine como uma VM nova ou atual capturada com a opção Consistente com o aplicativo, é preciso mudar o disco do modo somente leitura para o modo de leitura e gravação. Para fazer isso, siga as instruções em Opcional: marque o disco como disponível para leitura e gravação.
  • Fazer backup consistente com falhas na última tentativa: essa opção inicialmente faz backups consistentes com o aplicativo, mas, se um backup consistente com o aplicativo falhar por qualquer motivo, ela fará um backup consistente com falhas.
    •
    Local do snapshot
    (aplicável apenas a instâncias do Compute Engine e do SAP HANA)    		 Selecione a região em que os snapshots do Persistent Disk serão armazenados. Por padrão, a opção multirregional é selecionada (com base no local do disco de origem). Também é possível mudar o local de armazenamento do snapshot para uma região diferente da região do disco de origem. Ao armazenar snapshots em um local diferente do disco de origem, os dados trafegam pela rede entre esses locais e podem gerar taxas de rede. Os snapshots estão sujeitos às mesmas taxas da transferência de dados do Cloud Storage. Saiba mais sobre o snapshot de disco permanente. Para saber os detalhes de preços, consulte preços de disco.
    Tipo de snapshot      
    (aplicável apenas a instâncias do Compute Engine e do SAP HANA)    		Selecione o tipo de snapshot do Persistent Disk a ser usado para backups de instâncias do Compute Engine. Os snapshots fazem backup incremental de dados dos discos permanentes. Durante os backups, um novo snapshot é criado para capturar o estado atual do disco permanente e, posteriormente, pode ser usado para criar um novo disco para montagens ou restaurações. O Compute Engine armazena várias cópias de cada snapshot em vários locais com somas de verificação automáticas para garantir a integridade dos dados. Saiba mais sobre o snapshot de disco permanente. Para saber os detalhes de preços, consulte preços de disco.
  • Padrão: por padrão, o tipo de snapshot padrão é selecionado. Recomendamos usar o tipo padrão se você quiser manter os backups por menos de 90 dias.
  • Arquivo: selecione o tipo de arquivo se quiser manter os backups por um longo período. O período mínimo de faturamento para o snapshot de arquivamento é de 90 dias, independentemente do período de retenção definido na política. Além disso, o tipo de arquivamento também tem uma cobrança de recuperação adicional se usado em um job de montagem ou restauração.
    •       
    Alocação excessiva de disco de preparo
    (em porcentagem)    		 Especifique o espaço extra alocado para o disco de preparo (além do que é realmente necessário) para acomodar o crescimento do aplicativo. Essa configuração varia de zero a 1.000%.
    Caminhos de remoção global Não faça backup desses diretórios (especifique o caminho completo). Consulte também os valores de caminhos de remoção global no nível da política.
    Compactar a replicação do Streamsnap Por padrão, a compactação para replicação do streamsnap está ativada. A compactação aumenta a eficiência da replicação do streamsnap para o dispositivo de backup/recuperação remoto ao transferir dados pela rede, por exemplo, ao replicar backups e vídeos. Quando a compactação está ativada, todos os pacotes são compactados. O dispositivo de backup/recuperação de destino descompacta os pacotes antes de gravar no disco de preparo. Se a compactação não for necessária para a replicação do streamsnap no segundo dispositivo de backup/recuperação, mude a configuração avançada de compactação da replicação do streamsnap para Não compactar e clique em Salvar alterações.
    Observação: a replicação do Streamsnap só é compatível com os dispositivos de backup/recuperação implantados em uma única rede.
    Não remover o mapeamento Especifica se você quer que os discos de preparo temporários mapeados para o host e usados durante a movimentação de dados para backup permaneçam mapeados para o host. Os LUNs são mapeados durante o primeiro job, e todos os jobs subsequentes reutilizam o mesmo LUN mapeado. Selecione uma das opções:
  • Mantenha os discos de preparo mapeados entre os jobs. Selecione essa opção se quiser que os discos de preparo temporários mapeados para o host e usados durante a movimentação de dados permaneçam mapeados para o host. Os LUNs são mapeados durante o primeiro job, e todos os jobs subsequentes reutilizam o mesmo LUN mapeado. Essa opção fica selecionada por padrão.
    Observação: para aplicativos gerenciados usando o agente de backup e DR (como o banco de dados SQL) em que o aplicativo está em um SO em execução em uma VM do VMware, essa opção é ignorada. O disco de preparo é sempre desmapeado da VM após cada job.
    •
  • Remover o mapeamento dos discos de preparo após cada job. Essa opção desmonta o disco de preparo do sistema operacional na conclusão de cada job (removendo pontos de montagem ou letras de unidade) e também o desmapeia do host. Essa opção exige que o host faça uma verificação de LUNs SCSI no início do próximo job, já que os discos de preparo remapeados precisam ser redescobertos antes de serem remontados.
    •
    Truncate (Purge) Log After Backup Especifique se os registros do banco de dados serão truncados (limpos) após cada backup. Quando a opção Truncar registro após o backup está ativada, os registros relacionados ao aplicativo são truncados até o backup recente ou atual. Se você truncar registros, também precisará fazer backup do registro de transações para permitir uma recuperação de roll forward.
    As opções são:
  • Não truncar ou limpar o registro após o backup
    •
  • Truncar ou limpar o registro após o backup
    •
    Ignorar aplicativos off-line
    (somente para gerenciamento de grupos de consistência)    		 Especifique se os aplicativos indisponíveis que fazem parte de um grupo de consistência devem ser ignorados. Crie um grupo de consistência para fazer backup dos dados de todos os aplicativos membros juntos para preservar a consistência dos dados entre os aplicativos membros. Os grupos de consistência são coleções de aplicativos descobertos do mesmo host.
    As opções são:
  • Falha no backup quando aplicativos off-line são encontrados
    •
  • Pular aplicativos off-line durante o backup
    •
    Mapear discos de preparo para todos os nós em um cluster de aplicativo Se os nós estiverem em um cluster de aplicativos, use isso para garantir que os nós de um cluster de aplicativos estejam protegidos em caso de failover durante o backup.
  • Não mapeie o disco de preparo para todos os nós do cluster de aplicativos.
    •
  • Mapear o disco de preparo para todos os nós do cluster de aplicativos
    Em caso de falha no cluster de aplicativos, essa opção protege as cópias de failover.
    •
    Mapear o disco de preparo para todos os hosts ESX em um cluster
    (somente para VMs do VMware)     		Se os servidores ESX estiverem em um dispositivo, use essa configuração para garantir que as VMs sejam gerenciadas em caso de failover durante o backup. No caso de uma falha no host do ESX, essa opção gerencia cópias de failover de VMs do VMware. (Oracle, sistemas de arquivos locais, SMB, NFS, SQL Server):
  • Mapear o disco de preparo para o host ESX apenas para VM
    •
  • Mapear o disco de preparo para todos os hosts ESX no cluster
    •
  • Mapear o disco de preparo para dois hosts ESX no cluster
    •
    Fazer backup de logins de usuários do SQL Server Captura as credenciais de login do banco de dados do SQL Server. Quando o banco de dados é montado como um aplicativo virtual (montagem com reconhecimento de app), o banco de dados virtual tem todas as credenciais de login usadas pela origem. As opções são Sim ou Não.
    Ativar o backup de registros do banco de dados A opção Ativar backup de registro do banco de dados permite que a política do plano de backup faça backup de um banco de dados e de todos os arquivos de registro de transações associados. O backup dos registros é feito quando o job de snapshot de registro é executado. As opções são "Sim" ou "Não". Quando definido como Sim, as opções relacionadas são ativadas.
    Observação: para detalhes sobre a Proteção de registros, consulte Proteção de registros do banco de dados em uma política de plano de backup.
    RPO Quando Ativar backup de registro do banco de dados está definido 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. O menor valor que pode ser definido (em minutos) é 15.
    Período de retenção do backup de registros
    (em dias)    		 Quando Ativar backup de registro do banco de dados está definido como Sim, a retenção de registros é definida separadamente da retenção da política de snapshot. Ter um período de armazenamento separado permite usar registros em conjunto com cópias do banco de dados armazenadas no pool de snapshots. O período de armazenamento de registros é uma configuração obrigatória.
    Replicar registros
    (usa a tecnologia Streamsnap)    		 Quando Ativar backup de registro do banco de dados está definido como Ativar, a configuração avançada Replicar registros permite que os registros do banco de dados sejam replicados para um dispositivo remoto. Para que um job de replicação de registros seja executado, é necessário que haja uma política de replicação do streamsnap incluída no modelo, além de um perfil de recurso que especifique um dispositivo remoto, e pelo menos uma replicação bem-sucedida do banco de dados precisa ser concluída primeiro. Em seguida, é possível usar os registros no site remoto para qualquer backup de banco de dados dentro do intervalo de retenção dos registros replicados. Essa função é ativada por padrão.
    A replicação de registros usa a tecnologia StreamSnap para realizar a replicação entre os dispositivos locais e remotos. A replicação de registros vai diretamente do pool de snapshots local para o pool de snapshots no dispositivo remoto.
    Observação: a replicação de registros só ocorre depois que o banco de dados é protegido e o backup é replicado para o dispositivo remoto.
    Enviar registros para o pool do OnVault Defina como Sim para que os registros sejam replicados em um ou mais pools de armazenamento do OnVault, permitindo recuperações pontuais do OnVault em outro site.
    Observação: se você selecionar essa opção, o Backup e DR vai enviar registros para todos os pools do OnVault definidos no perfil desse aplicativo. Se houver dois pools no perfil, o monitor vai mostrar jobs do OnVault (registro) para cada backup de registro, um para cada pool. Somente os pools do OnVault que estão no perfil desse SLA vão receber os registros.
    • A retenção de registros replicados para o OnVault é semelhante à retenção de registros de snapshot.
    • A replicação de registros de banco de dados em um bucket do OnVault é diferente de um backup de banco de dados. Se você selecionar Enviar registros para o pool do OnVault, o Backup e DR vai replicar continuamente os registros para buckets do OnVault, de maneira semelhante aos backups de snapshots de registro. Por exemplo, se um backup de registro for feito a cada 15 minutos, os registros serão replicados para o OnVault a cada 15 minutos para garantir que todos os snapshots de registro sejam replicados para os pools do OnVault.
    • O ID da política mostrado no console de gerenciamento do appliance é o ID da política de snapshot, já que essa replicação de registros para buckets do OnVault está vinculada à política de snapshot.
    Observação: as políticas diárias, semanais, mensais e anuais do OnVault são apenas para backups de banco de dados, não se aplicam a backups de registros.
    Tamanho do crescimento do disco de preparo de registros (em porcentagem) Quando Ativar backup de registro do banco de dados está definido como Sim, Tamanho de crescimento do disco de preparo de registro define o crescimento a ser usado ao aumentar automaticamente o disco de preparo em que os registros residem. Essa configuração varia de 5% a 100%.
    Taxa de mudança estimada Quando Ativar backup de registro do banco de dados está definido como Sim, essa configuração define a alteração diária (em porcentagem), o que permite que o dispositivo calcule melhor o tamanho do disco de preparo necessário para armazenar registros. Essa configuração vai de zero a 100.
    Compactar backup de registro do banco de dados Quando Ativar backup de registro do banco de dados está definido como Sim, essa configuração instrui o banco de dados de origem a compactar os registros antes que eles sejam capturados pelo console de gerenciamento do dispositivo. O servidor de banco de dados realiza a compactação de registros durante o backup de registros. As opções são Yes ou No. Quando definida como Yes, a opção Compress Database Log Backup é ativada.
    Retenção obrigatória Permite que o usuário configure o período de imutabilidade entre zero e 36.525 dias. Por padrão, o valor é definido como zero para todas as políticas atuais.
    É possível modificar uma política que já é usada para proteger um aplicativo definindo um período de armazenamento obrigatório mais longo. No entanto, não é possível reduzir o período de armazenamento obrigatória.
    Não é possível definir a retenção obrigatória para uma política de streamsnap com a retenção "Manter apenas a imagem remota mais recente".
    Observação: a retenção aplicada não pode ser substituída por aplicativo. A opção não aparece na página Substituições de política.
    Observação: a configuração de política avançada Retenção aplicada não é compatível com a proteção de aplicativos que aponta para um backup vault. Quando um backup vault é o destino de armazenamento, ele determina o período de armazenamento obrigatório.
    Comportamento do job quando a VM de destino precisa de consolidação de snapshot Selecione uma ação se a VM exigir consolidação:
  • Falha no job se a VM precisar de consolidação: jobs pontuais falham.
    •
  • Executar o job sem realizar a consolidação: todos os jobs são executados normalmente, mesmo que a consolidação esteja pendente.
    •
  • Realizar a consolidação no início do job: os jobs pontuais tentam realizar a consolidação no início do job. Se a consolidação falhar, o job falhará com uma mensagem de erro.
    •
    Falha no caminho de início ausente Se um ou mais caminhos de início forem especificados e algum deles não existir, o job vai falhar com a mensagem "UDSAgent: o caminho de início especificado não existe". Se nenhum caminho inicial for especificado, essa opção não terá efeito. As opções são Sim ou Não.
    Observação: o estado padrão dessa opção é Não (desativado), que é o mesmo comportamento das versões anteriores do agente de backup e DR. O job não falhará se um caminho de início não existir.
    Ativar o modo de captura degradada O modo de captura degradado captura dados incrementais quando o serviço de rastreamento de blocos de alteração (CBT, na sigla em inglês) está indisponível. A captura de dados pode demorar mais. As opções são Sim ou Não.
    Tempo limite de script
    (aplicável apenas a backups baseados em agentes)    		 O agente de backup e DR permite criar scripts do lado do host que são executados no host de um aplicativo antes ou depois da execução de uma política. Os quatro tempos limite fornecidos em um modelo de política são mapeados diretamente para os quatro estágios de um script do lado do host.
    Observação: por padrão, os valores de tempo limite do script são os seguintes. Se um tempo limite de script não for especificado, o valor ficará em branco e o padrão será usado.
  • Tempo limite de inicialização do script: define quanto tempo um job deve esperar pelo script invocado no host antes que qualquer ação seja realizada pelo job. Se o script não for concluído dentro desse tempo limite, o job vai falhar. O valor padrão é de 60 segundos. O intervalo permitido é de 1 a 86.400 segundos.
    •
  • Tempo limite de congelamento do script: define quanto tempo uma política precisa esperar para que o script invocado congele um aplicativo antes que um snapshot seja criado. Se o script não for concluído dentro desse tempo limite, o job vai falhar. O valor padrão é de 60 segundos. O intervalo permitido é de 1 a 86.400 segundos.
  • Tempo limite de descongelamento do script: define quanto tempo uma política precisa esperar para que o script invocado congele um aplicativo após a criação de um snapshot. Se o script não for concluído dentro desse tempo limite, o job vai falhar. O valor padrão é de 60 segundos. O intervalo permitido é de 1 a 86.400 segundos.
  • Tempo limite de conclusão do script: define por quanto tempo uma política precisa aguardar o script que é invocado no final do job. Se o script não for concluído dentro desse tempo limite, o job vai falhar. O valor padrão é de 60 segundos. O intervalo permitido é de 1 a 86.400 segundos.
    		•

    A seguir