NBU | Realizando upgrade do client atraves do install_client_files sftp

Fala galera tudo bem?

Hoje vou comentar um pouco sobre o upgrade da versão do Netbackup Client. Apesar de ser algo simples na vida do analista de backup, podemos passar batido sobre as diversas formas de fazer isso

- Copiando o binário para o client e realizando o upgrade manualmente;

- Usando um servidor como repositório de binários e assim, montar um NFS deste servidor para os clients, evitando a necessidade de copiar binários;

- Através de uma Deployment Policy pela console do MasterServer (comente aí se quiser um post sobre isso ou me envie um email);

- Diretamente pelo MasterServer através do comando nbinstallcmd (que é basicamente a linha de comando de uma Deployment Policy;

- Ou fazendo o MasterServer para o cliente através do comando install_client_files, onde é possível usar o método ssh ou sftp.

É esse último que vamos falar hoje.

Tem uma publicacao da Veritas sobre isso se quiserem ler.

https://www.veritas.com/support/en_US/article.100005288

Obviamente, eu precisei ocultar os hostnames do MasterServer e do client, mas da para entender.

No MasterServer

Execute o comando conforme abaixo:

./install_client_files sftp <cliente> <usuário>

ele perguntará sobre Java GUI e JRE. Marque a opção equivalente ao seu ambiente. No meu caso, o Java GUI no client não deve ser instalado.

Ao final ele dá a mensagem de que o processo foi feito com sucesso e para concluir a instalação, você deve executar o comando como mostra.

No Client

Execute o comando conforme abaixo:

sh /tmp/<bp.47321>/client_config

Apenas acompanhe....

Pronto. Upgrade de client realizado com sucesso.

Valeu gente,

Abs,

Jeferson Sasso

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 - Como consultar no client os objetos gravados pelo RMAN

Fala pessoal tudo bem?

Essa dica ajuda bastante o time DBA. Provavelmente o DBA não tem acesso ao catálogo direto do Masterserver, não consegue fazer algumas buscas, mas saiba que pelo servidor onde está o banco, dá.

É provável que o servidor tenha o client do Netbackup instalado então bora para a prática.

Vá até o caminho de instalação do NBU, em servidores Unix, normalmente está no /usr/openv/netbackup/bin

O comando a ser executado é o bplist.

Sintaxe: bplist -S <masterserver> -C <clientname> -t 4 -l -R /

O parâmetro -t é o policy type, onde o 4 = Oracle. Se quiser listar objetos gravados em uma policy Sybase, por exemplo, você usa o -t 7.

Na documentação da Veritas tem todas as opções. Vou deixar abaixo os mais comuns.

0 = Standard

4 = Oracle

7 = Sybase

13 = MS-Windows

15 = MS-SQL-Server

16 = MS-Exchange-Server

17 = SAP

40 = VMWare

Caso queiram que escreva sobre algum determinado assunto, mandem por email ou deixem nos comentários.

Forte abraço

Sasso

Netbackup - RMAN Error 12010/12014

Fala galera tudo bem?

Queria compartilhar um erro recente que tivemos.

Quando fazemos backup de bancos Oracle via RMAN e Netbackup, obrigatoriamente passamos algumas variáveis que o precisam ser colocadas no script para que o RMAN utilize o device type correto, como por exemplo, NB_ORA_POLICY, NB_ORA_SERV, NB_ORA_SCHED.

O erro abaixo indica que várias entradas no RMAN tinham sido setadas para configurações default de canais para o device type SBT_TAPE.

A verdade é que depois de investigarmos exaustivamente o porque isso ocorreu, não conseguimos chegar a alguma conclusão. Juntamente com o time DBA, e para um ambiente que funciona sem problemas há muito tempo, chegamos a conclusão que foi uma leve dedada de alguém... mas enfim, como resolver isso?

Como o ambiente possui mais de uma instance, a primeira coisa é setar as variáveis de ambiente do oracle

E na sequência conectar no banco.

O que fizemos para resolver foi resetar as configurações que ficam no RMAN quando rodamos o show all através do comando: exec dbms_backup_restore.resetconfig

Na sequência rodamos um novo backup de archivelog log e veja que já no primeiro backup ele seta novamente todas as configurações.

O resultado? Tudo o que nós e os DBA´s mais gostam de ver.: Recovery Manager Complete. Return Code 0 = SUCESSO!!!!

Abs galera e até a próxima.

Jeferson Sasso

Netbackup - Identificando o objeto gravado pelo Oracle RMAN

Fala galera tudo bem com vocês?

Você tem algum backup de Oracle ativo no seu NBU? 

Se esses dados do RMAN estiverem sendo gravados todos dentro de uma mesma policy e estiverem associados ao Default-Application-Backup, somente olhar pelo catalog do master não é o suficiente para identificar que objeto é, mesmo porque, sabemos que o dependendo de como o DBA configurou o script, ele pode estar usando um backup Full time in point, um Level 0, Level 1, Archivelog, Cumulative...

A boa notícia é que a grande maioria, ao menos é uma boa prática, configura em seu script para que ao gerar os pieces, eles consigam facilmente identificar do que se trata.

Vamos ao exemplo.

Veja que no catalog do master há uma imagem de backup gravada em 25/04/2020 e está associada ao Default-Application-Backup. Do que se trata essa imagem? É algum backup full mensal, ou um archivelog perdido que já deveria ter sido expirado pelo RMAN e ainda não foi?

Pelo command line você consegue facilmente ver isso através do comando BPFLIST.

Rode dessa forma: bpflist -backupid <backupid>

Se achar que tem muita sujeira, pode usar o awk para fazer um filtro melhor.

É isso. Espero ter ajudado.

Forte abraço.

Netbackup - Timeout em backup SQL

Fala galera tudo bem?

Uma passada rápida para uma dica que pode ajudá-los com backup de bancos SQL.

Caso você não esteja utilizando o Inteligent Policy do NBU, é provável que esteja utilizando a policy que chama os scripts .bch. 

Quando o backup, nos detalhes do job dá para ver qual o timeout do VDI. Veja bem que esse não é o timeout do client e sim do VDI, usado para fazer backup do SQL.

Os scripts normalmente são criados pela interface gráfica do Netbackup MS SQL Client

A interface tem essa carinha

Depois de salvar o script, você consegue editá-lo com o notepad. Se perceber que o timeout não é o suficiente, acrescente o parâmetro VDITIMEOUTSECONDS no script. Salve-o e restarte o backup.

Isso deve resolver o problema de timeout que está ocorrendo.

Forte abraço

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.