Configurar configurações avançadas de políticas

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 avançadas da política ao criar uma política de backup.

Também é possível conferir e mudar as configurações de política de aplicativos específicos ao mostrar 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, 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, à direita, 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 da 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 avançadas de política.

               

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 em caso de falhas: um backup consistente em caso de falhas é um backup rápido dos dados do aplicativo no armazenamento como se a energia fosse 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 em caso de falhas pode levar mais tempo e introduzir exceções. Talvez seja necessário realizar algumas etapas manuais adicionais durante a recuperação, dependendo do SO convidado, dos sistemas de arquivos e dos aplicativos. Escolha a opção de consistência de falha se o processo de consistência de aplicativo causar problemas para seus aplicativos ou cargas de trabalho devido ao processo de inatividade. A consistência de falha pode resultar em um RTO mais longo devido à necessidade de o sistema de arquivos ou o aplicativo realizar uma recuperação do snapshot inconsistente, podendo até resultar em um snapshot irrecuperável em casos extremos. Fazer backup consistente do aplicativo: o backup consistente do aplicativo usa snapshots inativos, que usam ferramentas VMware ou um ambiente Google Cloud convidado para inativar o sistema de arquivos da máquina virtual. Uma operação de quiescência usa recursos integrados do sistema operacional Windows para colocar em estado de espera sistemas de arquivos e aplicativos compatíveis com VSS. Ele também usa scripts de congelamento ou descongelamento fornecidos pelo cliente (em todas as plataformas) para aumentar a consistência do aplicativo. O resultado é um nível de confiança maior na capacidade de recuperação do backup, além de tempos de recuperação mais curtos na maioria dos casos. Às vezes, os backups consistentes com o aplicativo podem causar uma breve pausa na E/S. Embora seja incomum, alguns aplicativos mais movimentados podem informar erros de E/S no momento do backup. Às vezes, os backups consistentes de aplicativos falham se o VMware não conseguir colocar a VM em estado de inatividade 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 Como criar um snapshot de disco permanente consistente de aplicativo do Linux para mais informações. Para montar um snapshot do Windows Compute Engine como uma VM nova ou existente capturada com a opção Consistente com o aplicativo, mude o disco do modo somente leitura para 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 em caso de falha na última tentativa: essa opção inicialmente faz backups consistentes do aplicativo, mas, se um backup consistente do aplicativo falhar por qualquer motivo, ela faz um backup consistente em caso de falha.
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 multirregião é selecionada (com base no local do disco de origem). Você também pode 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 geram as mesmas taxas que a 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 pode ser usado posteriormente 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 do snapshot de arquivamento é de 90 dias, independente do período de retenção definido na política. Além disso, o tipo de arquivamento tem uma cobrança de recuperação adicional se for usado em um job de montagem ou restauração. O tipo de snapshot de arquivo só pode ser usado quando o console de gerenciamento e o dispositivo de backup/recuperação estão na versão 11.0.4 ou mais recente.
Superalocação de disco de preparo (em porcentagem)	Especifique o espaço extra alocado para o disco de staging (além do que é realmente necessário) para acomodar o crescimento do aplicativo. Essa configuração varia de 0 a 1.000%.
Caminhos de poda globais	Não faça backup desses diretórios (especifique o caminho completo). Consulte também os valores de remoção global de caminhos no nível da política.
Compactar a replicação do Streamsnap	Por padrão, a compactação para replicação de streamsnap está ativada. A compactação aumenta a eficiência da replicação de streamsnap para o dispositivo remoto de backup/recuperação ao transferir dados pela rede, por exemplo, ao replicar imagens 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 staging. 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 é compatível apenas com os dispositivos de backup/recuperação implantados em uma única rede.
Não desmapear	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. As LUNs são mapeadas durante o primeiro job, e todos os jobs subsequentes reutilizam a mesma LUN mapeada. 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. As LUNs são mapeadas durante o primeiro job, e todos os jobs subsequentes reutilizam a mesma LUN mapeada. Essa opção fica selecionada por padrão. Observação: para aplicativos gerenciados usando o agente do Backup e DR (como um banco de dados SQL) em que o aplicativo está em um SO executado em uma VM do VMware, essa opção é ignorada. O disco de staging é sempre removido da VM após cada job. Desvincule os discos de staging após cada job. Essa opção desmonta o disco de preparo do sistema operacional ao concluir cada job (removendo pontos de montagem ou letras de unidade) e também o desvincula 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 staging remapeados precisam ser redescobertos antes de serem remontados.
Truncar (limpar) o registro após o backup	Especifique se os registros do banco de dados devem ser 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 os registros, também será necessário fazer backup do registro de transações para permitir uma recuperação de roll forward. As opções são: Não truncar nem 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. Você cria um grupo de consistência para fazer backup dos dados de todos os aplicativos membros juntos e preservar a consistência dos dados em todos eles. Os grupos de consistência são coleções de aplicativos descobertos do mesmo host. As opções são: Falhar o backup quando aplicativos off-line forem encontrados Pular aplicativos off-line durante o backup
Mapear discos de staging para todos os nós em um cluster de aplicativos	Se os nós estiverem em um cluster de aplicativo, use isso para garantir que os nós de um cluster de aplicativo 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 staging para todos os nós do cluster de aplicativo Em caso de falha do cluster de aplicativo, essa opção protege as cópias de failover.
Mapear o disco de staging para todos os hosts ESX em um cluster (somente para VMs do VMware)	Se os servidores ESX estiverem em um appliance, use essa configuração para garantir que as VMs sejam gerenciadas em caso de failover durante o backup. Em caso de falha de um host ESX, essa opção gerencia cópias de failover de VMs do VMware. (Oracle, sistemas de arquivos locais, SMB, NFS, SQL Server): Mapear disco de staging para host ESX somente para VM Mapear o disco de staging para todos os hosts ESX no cluster Mapear o disco de staging 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 compatível com apps), ele 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 do 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. Os registros são armazenados em backup 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 de banco de dados em uma política de plano de backup.
RPO	Quando Enable Database Log Backup está definido como Yes, o RPO define a frequência do backup de registros 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 a opção Ativar backup de registros do banco de dados está definida como Sim, a retenção de registros é definida separadamente da retenção da política de instantâneo. 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 em um dispositivo remoto. Para que um job de replicação de registros seja executado, é necessário que uma política de replicação de streamsnap seja incluída no modelo junto com um perfil de recurso que especifique um dispositivo remoto. Além disso, pelo menos uma replicação bem-sucedida do banco de dados precisa ser concluída primeiro. Em seguida, use os registros no site remoto para qualquer imagem 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 não ocorre até que o banco de dados seja protegido e a imagem replicada para o dispositivo remoto.
Enviar registros para o OnVault Pool	Defina como Sim. Os registros serão replicados para 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 OnVault (registro) para cada backup de registro, um para cada pool. Somente os pools do OnVault no perfil desse SLA vão receber os registros. A retenção de registros replicados no OnVault é semelhante à retenção de registros de instantâneo. A replicação de registros do banco de dados em um bucket do OnVault é diferente de um backup do 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 semelhantes aos backups de snapshots de registros. 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 é o ID da política de snapshot, já que essa replicação de registros em 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 e não se aplicam a backups de registros.
Tamanho do crescimento do disco de preparo do registro (em porcentagem)	Quando a opção Ativar backup de registros do banco de dados está definida como Sim, o Tamanho do crescimento do disco de preparação de registros define o crescimento a ser usado ao aumentar automaticamente o disco de preparação em que os registros residem. Essa configuração varia de 5 a 100%.
Taxa de mudança estimada	Quando Enable Database Log Backup está definido como Yes, essa configuração define a mudança diária (em porcentagem), o que permite que o appliance calcule melhor o tamanho do disco de staging necessário para armazenar os registros. Essa configuração varia de zero a 100.
Compactar backup de registro do banco de dados	Quando a opção Ativar backup de registros do banco de dados está definida 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. O servidor de banco de dados realiza a compactação de registros durante o backup. As opções são Sim ou Não. Quando definida como Sim, a opção Compactar backup de registros do banco de dados é ativada.
Retenção aplicada	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 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 forçada para uma política de streamsnap cuja retenção seja "Manter apenas a imagem remota mais recente". Observação: retenção forçada 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 avançada da política de retenção forçada não é compatível com a proteção de aplicativos que aponta para um cofre de backup. 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 precisar de consolidação: Falha no job se a VM precisar de consolidação: jobs pontuais falham. Execute o job sem fazer a consolidação: todos os jobs são executados normalmente, mesmo que a consolidação esteja pendente. Realize a consolidação no início do job: os jobs pontuais tentam fazer a consolidação no início do job. Se a consolidação falhar, o job vai falhar com uma mensagem de erro.
Fail On Missing Start Path	Se um ou mais caminhos de início forem especificados e algum deles não existir, o job vai falhar com a mensagem UDSAgent: Specified start path doesn't exist. Se nenhum caminho de início 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 do Backup e DR. O job não falha se um caminho de inicialização não existir.
Ativar o modo de captura degradada	O modo de captura degradado captura dados incrementais quando o serviço Controle de bloqueio de alteração (CBT) está indisponível. A captura de dados pode levar mais tempo. As opções são Sim ou Não.
Tempo limite do script (aplicável apenas a backups baseados em agente)	Com o agente do Backup e DR, é possível 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 por quanto tempo um job deve aguardar o 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 de script: define por quanto tempo uma política deve aguardar o script invocado para congelar um aplicativo antes de um instantâneo ser 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 por quanto tempo uma política deve aguardar o script invocado para congelar um aplicativo depois que um snapshot é 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 conclusão do script: define por quanto tempo uma política deve aguardar o script 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

• Confira uma visão geral do plano de backup
• Criar um modelo de backup
• Criar uma política de backup
• Crie um perfil de recurso.
• Configurar as configurações avançadas de política de um aplicativo com backup feito pela política
• Aplicar um plano de backup a um aplicativo