Netbackup - Configurando o Oracle Inteligent Policy

Fala pessoal, tudo bem?
Já precisaram configurar um backup de RMAN através do Inteligent Policy do Netbackup?


Vamos à prática.


1- Instalar o NBU Client no servidor.
2- Ajustar o bp.conf
3- Vai na interface gráfica do NBU (Netbackup Management → Applications → Oracle → All Instances


Obs.: O NBU consegue identificar os bancos ativos nos servidores que possuem client instalado. Dar refresh para atualizar a lista de bancos.





Atenção: Observar o campo STATE. Novos bancos estarão com esse campo em branco, indicando que precisam ser registrados/ativados para que possamos fazer backup via OIP. Os bancos que estão com status Active, significa que já foram registrados/ativados.


4- Right-Click no banco que será registrado/ativado. Entrar na Opção Register.






5- Entrar com a credencial conforme abaixo






Apenas reforçando:
- A primeira credencial é o usuário/senha usada para o banco no SO. Na maioria dos casos, é o usuário Oracle
- A segunda credencial é o usuário/senha criado pelo DBA para uso exclusivo do NBU. Esse usuário precisa ter permissão sysdba (se o dba te questionar, mostre a página 110 do manual).
- O Net Service name (TNS Alias) é o dba que informa. Para testar o nome passado pelo DBA, rodar na máquina o comando: tnsping <net service name>


6- Criar uma policy do tipo Oracle





7- Criar os schedules conforme necessidade da política. Atentar que para policies OIP, não existe mais o Default-Application-Backup. Somente os schedules que você preisa.


Type of Backup → Full Backup
É um backup full Level 0. No exemplo abaixo, é um backup full a ser executado diariamente.






Type of Backup → archived Redo Log Backup
É o backup de archivelog do Oracle





Na aba Instances and Databases, selecionar a opção Protect Instances and Databases e logo abaixo New.


Quando a aparecer a aba com as instances, reparem que vão aparecer TODAS as instances de TODOS os clients que já foram registradas/ativadas. Selecionar apenas a instance que precisa de backup conforme policy.








Na aba Backup Selections, deixar a opção default (Whole database).





Na última aba, ORACLE, atentar para os campos marcados. Apesar de serem auto-intuitivos, importante prestar atenção e customizar conforme necessidade de cada banco. O ideal é compartilhar com o DBA as opções que serão usadas aqui.




Depois disso, rodar um backup manualmente e validar a execução. Importante também pedir para o DBA validar a execução no banco.





É isso. Até a próxima
Abs,
Sasso

Netbackup - Expiração de imagem amarrada a uma SLP

Olá pessoal tudo bem?

Continuando nosso assunto da SLP. Comentei no post anterior um pouco sobre a SLP.

Hoje gostaria de complementar o assunto, pois é importante falar que enquanto a ação de duplicate não finalizar com sucesso, a primeira imagem de backup fica amarrada à SLP e não é expirada.

Então por exemplo, lembrando o exemplo anterior.

1- Backup com retenção de 30 dias em disco de alta performance

2- Duplicate com retenção de 1 ano em fita.

Se a ação 2 não finalizar com sucesso nos próximos 30 dias, mesmo que a ação 1, tenha fixado a retenção do backup com 30 dias, ele NÃO irá expirar enquanto o duplicate não rodar.

Outro exemplo: Você pode configurar a SLP para gravar o backup em um advanced disk para expirar imediatamente após a migração dele para uma fita. Isso significa que enquanto esse dado não duplicar ele não vai expirar de forma nenhuma até que o duplicate execute com sucesso.

Mas existe uma forma de você forçar essa 'desassociação' do backup à SLP. Apesar de não ser recomendado e precisa ter extrema cautela para fazer, é possível.

Via command line direto no MasterServer, rode o comando NBSTLUTIL.

Exemplo: nbstlutil cancel -backupid  <clientname_1517977711>

A cautela que eu comento aqui é o seguinte. O backup está marcado para reter por 10 dias e depois de duplicar vai reter por 1 ano. Se passados 10 dias ele ainda não duplicou (e aqui não importa o motivo), você rodar esse comando, já era, seu dado será expirado e você o perderá.

Mas quando usar esse comando? O ideal é nunca, mas existe uma situação que já vi ocorrer e talvez ajude outras pessoas. Um backup que gravou em disco e tinha retenção de 10 dias e depois ficou tentando duplicar para fita para reter por mais 30 dias. Como o ambiente de fitas estava fora do ar, passados 30 dias, o NBU ainda estava tentando duplicar esse dado e de fato não precisava mais.

Ao rodar esse comando o dado perdeu a amarração e portanto foi expirado pelo NBU.

Então é isso. Um forte abraço.

Netbackup - SLP (Storage Lifecycle Policy)

Fala pessoal tudo bem?

Hoje uma dica rápida. Vocês já tiveram algum caso onde uma imagem de backup que está associada a uma SLP e que já deveria ter expirado ainda não o foi? Vou falar um pouco sobre isso na próxima postagem, mas primeiro vamos ao conceito.

Vocês sabem o que é uma SLP? Basicamente a SLP (Storage Lifecycle Policy) abre a possibilidade de você criar cópias de um backup de forma automática, seguindo retenções específicas. Por exemplo, se você combina seu armazenamento entre discos de alta performance (+caros), com discos de baixa performance (+baratos), e com fitas (++baratos), é possível criar uma SLP para que o backup seja executado gravando no primeiro pool com retenção de 30 dias, na sequência ele gera um job de duplicate onde o NBU grava a imagem no segundo pool  (baixa perfomance) com retenção de 90 dias e por último uma instrução de duplicate para gerar uma cópia em uma fita com retenção de 1 ano.

Dessa forma você consegue programar o NBU a realizar essa movimentação dos dados para que seu disco de alta performance, por exemplo, não fique em uso por dados com baixa probabilidade de restore. A ideia nessa estratégia é basicamente o seguinte.:

1- Mantém os dados em um disco de alta performance por 30 dias, pois caso seja necessário fazer o restore, a performance tende a ser maior

2- Duplica essa imagem para um disco de baixa performance e mantém por 90 dias. Probabilidade de restore desse dado é mediana

3- Se em 90 dias não pediram restore desses dados, mas ainda assim é necessário retê-lo de acordo com sua política, migre-o para fita e guarde pelo tempo que precisar.

Existem outras estratégias possíveis de serem feitas, por exemplo manter uma cópia de backup e "replicar" esse backup para outro Netbackup Server, que esteja no seu site DR. Enfim, ferramenta bacana que lhe dá alternativas.

Veja outro exemplo abaixo:

Nesse caso, a SLP vai manter o backup em um disco de alta performance por 15 dias, outro disco por 1 ano e fita por 30 anos. No caso a fita é enviada para um cofre offsite.

Espero ter ajudado.

Abraços

Arquitetura da política de backup

Conforme havia comentado ontem, hoje quero abordar um tópico sobre a arquitetura da política de backup no TSMServer.

Há 4 níveis de objetos de política.:

• Policy Domain
• Policy Set
• Management Class
• Copy Groups

Vamos entrar nos detalhes de cada um.:

• POLICY DOMAIN

Esta é o topo da estrutura da política e o mais simples em relação ao seu conteúdo e configuração.

A Policy Domain permite agrupar client nodes logicamente, por características semelhantes, como por exemplo, pelo tipo de plataforma - AIX Domain, Windows Domain -, ou ainda, pelo tipo de dados a ser copiado, por exemplo, todos os nodes de backup de banco de dados Oracle, SQL..etc.

Outro tipo de uso é agrupar os nodes por função organizacional, por exemplo, departamento financeiro da localidade São Paulo.

Existem apenas 3 parâmetros para serem setados.:

• DESCRIPTION - Descrição do domínio, algo que determine a característica / identificação deste domínio
• BACKRETENTION - Esse parâmetro fica válido apenas quando toda estrutura que está abaixo do Domain relativo a um BACKUP é deletado, ou seja, se todas as políticas do TSM forem deletadas, os backups armazenados assumem a retenção setada nesse parâmetro. 30 dias é o valor default desse parâmetro.
• ARCHIRETENTION - Esse parâmetro fica válido apenas quanto toda a estrutura que está abaixo do Domain relativo a um ARCHIVE é deletado, ou seja, se todas as políticas do TSM forem deletadas, os archives armazenados asusmem a retenção setada nesse parâmetro. 365 dias é o valor default desse parâmetro.

• POLICY SET

Esta é a segunda camada de objetos da estrutura da política de backup. O único parâmetro a ser definido na criação de uma Policy Set é DESCRIPTION

• Apenas 01 (UMA) policy set pode estar ACTIVE em um Domain por vez. Podem haver várias Policy's Set definidas em uma Policy Domain, mas apenas UM deles será a ativa.
• A Policy Set ACTIVE é quem contém as Management Classes que serão associadas aos BACKUPS e ARCHIVES realizados.
• Quando uma Policy Set é ACTIVATED, o conteúdo dessa política é copiada para a política que terá o nome ACTIVE.
• Comandos possíveis para uma Policy Set.: define, copy, validate, activate, e também a descrição pode ser atualizada.

• MANAGEMENT CLASS

O terceiro nível da estrutura da política de backup é a MANAGEMENT CLASS, que podem ser quantas classes necessitar.

Cada MGMT Class pode conter um BACKUP COPYGROUP e/ou um ARCHIVE COPYGROUP. É necessário a definição desses Copy Groups de acordo com o tipo de operação que deseja executar (BACKUP e/ou ARCHIVE).

Para ativar uma Policy Set é necessário pelo menos uma MGMT Class e deve ter, obrigatoriamente, uma MGMT Class que é definida como DEFAULT.

As MGMT Class também gerenciam o modo de armazenamento do HSM. Os parâmetros que devem ser setados são.: SPACEMGTECHNIQUE, AUTOMIGNONUSE, MIGREQUIRESBKUP, MIGDESTINATION.

Os objetos gravados são associados a uma MGMT Class através da opção INCLUDE, que é setada no client node (dsm.sys ou dsm.opt), como no exemplo abaixo.:

INCLUDE * MGMT_30D

Neste exemplo todos os objetos gravados no servidor, estarão associados a MGMT Class de retenção 30 dias.
Se nenhuma MGMT Class for associada ao objeto, a MGMT Class Default é utilizada.

• COPYGROUP

Último nível da estrutura da política de backup é o Copy Group. Existem 2 tipos de Copy Group : BACKUP e ARCHIVE


Cada tipo contém parâmetros determinados que setam quanto tempo o objeto permanecerá retido ou quando ele será deletado.

Todos os Copy Group's chamam : STANDARD. Eles são diferenciados pela estrutura de MGMT Class, Policy Set e Policy Domain que está associado.

• BACKUP COPYGROUP:

Determina o destino dos objetos do tipo BACKUP e sua retenção. Seguem os principais parâmetros.:

• DESTINATION : determina o Storage Pool primário onde os dados serão inicialmente armazenados. O mesmo pode ser um STGPOOL de disco, fita, etc. Não pode ser um Copy Storage Pool.

• FREQUENCY.: frequência de quanto o TSM pode copiar um objeto. Esse parâmetro é usado apenas para o Backup tipo Incremental, sendo ignorado no Backup tipo Seletivo. O valor default é 0, ou seja, que o objeto seja copiado independente de quando foi copiado na última vez.

• VEREXISTS.: É o número máximo de versões de um mesmo objeto que serão retidas se esse objeto existir fisicamente no servidor. Default é 2, e pode ser setado de 1 a 9999, ou Nolimit.

• VERDELETED.: É o número máximo de versões de um mesmo objeto que serão retidas se esse objeto for DELETADO fisicamente no servidor. Default é 1, e pode ser setado de 1 a 9999, ou Nolimit.

• RETEXTRA.: É o número de dias de retenção de um objeto após ele se tornar inativo. O default é 30 dias. Pode ser setado de 0 a 9999 , ou Nolimit.

• RETONLY.: É o número de dias de retenção de um objeto após ser deletado fisicamente do servidor. O default é 60 dias. Pode ser setado de 0 a 9999 , ou Nolimit

Uma observação importante.: Esses parâmetros são válidos para as versões inativas dos objetos. A versão ativa fica armazenada “para sempre” ou até que o arquivo seja deletado fisicamente do servidor.

Continuando...

• MODE.: Determina se o TSM irá copiar o objeto somente se houve alteração neste objeto desde o último backup, ou se sempre que o cliente executar um backup. Os valores são MODIFIED (defalut) e ABSOLUTE (Full)

• SERIALIZATION.: Determina o que deve ser feito com os objetos que são modificados durante a execução do backup. Os possiveis valores são.:

1. SHRSTATIC (default).: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é ignorado.
2. STATIC.: Tenta gravar o objeto 1 (UMA) vez. Se o mesmo continuar sendo modificado, o objeto é ignorado falha.
3. SHRDYNAMIC.: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é copiado da forma que estiver.
4. DYNAMIC.: O objeto é copiado da forma que estiver.

• ARCHIVE COPYGROUP

Determina o destino dos objetos do tipo ARCHIVE e sua retenção. Seguem os principais parâmetros :

• DESTINATION.: Determina o STGPOOL primário onde os objetos serão inicialmente armazenados. Obs.: Não pode ser um copy storage pool.
• RETVER.: Número de dias de retenção de um archive. O default é 365 dias. Pode ser setado de 0 a 30000, ou Nolimit.
• SERIALIZATION.: Determina o que deve ser feito com os objetos que são modificados durante um backup. Seguem os possíveis valores.:

1. SHRSTATIC (default).: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é ignorado.
2. STATIC.: Tenta gravar o objeto 1 (UMA) vez. Se o mesmo continuar sendo modificado, o objeto é ignorado falha.
3. SHRDYNAMIC.: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é copiado da forma que estiver.
4. DYNAMIC.: O objeto é copiado da forma que estiver.

Uma última observação.: Caso uma MGMT Class seja apagada, todos os dados que estavam associados a ela, serão associados a política DEFAULT.
Tomem cuidado com as “limpezas”, pois a política default pode ter uma retenção inferior a politica que foi deletada.

Tenham todos um ótimo dia.