Mostrando postagens com marcador data protection. Mostrar todas as postagens
Mostrando postagens com marcador data protection. Mostrar todas as postagens

quarta-feira, 10 de junho de 2026

Air-Gapped Backup: O que é e por que ele é sua última linha de defesa?


Fala, pessoal!

Hoje quero comentar sobre um conceito que poucos falam, mas vejo como importante para empresas que conseguem se recuperar de um ataque e aquelas que não se recuperam. Já ouviram falar do Air-Gapped Backup?


A gente já observa um aumento agressivo de ataques de ransomware direcionados e posso dizer que garantir que os dados estejam "backupeados" já não é mais suficiente. Se o atacante conseguir acesso de administrador à nossa rede, podem ter certeza que a primeira coisa que ele quer fazer é achar e se possível, destruir os repositórios de backup.


E é aqui que entra o conceito de Air-Gap (ou isolamento físico). Em termos simples: o que não está conectado à rede não pode ser hackeado.


O conceito do "Vão de ar"

Pensa assim: Imagine que existe um "vão de ar" literal entre os dados de produção e o backup. Para que uma estratégia seja considerada genuinamente air-gapped, ela precisa cumprir dois requisitos:


1. Isolamento eletrônico: O dispositivo de destino não possui endereço IP ativo na rede de produção, não responde a comandos locais e fica completamente isolado da internet fora da janela de gravação.

2. Isolamento físico ou lógico rígido: O acesso às credenciais de escrita e ao hardware é extremamente restrito e segregado do restante do ambiente.


Se um malware infectar o servidor principal ou o próprio Backup Server, ele simplesmente não consegue saltar por esse "vão de ar" para criptografar o repositório protegido.


Como aplicar o Air-Gap na prática?

No dia a dia, a gente costuma dividir essa abordagem em duas frentes:


1. Air-gap físico (O modelo tradicional)

Funciona como sendo o cenário clássico do uso de mídias removíveis, como fitas magnéticas (LTO) ou HDs externos. Assim que o job de backup é concluído, a mídia é ejetada e removida fisicamente do rack.

Na prática, o operador leva essa fita para um cofre anti-incêndio ou para uma empresa de custódia, tipo Iron Mountain, NewSpace. Como o hacker não tem acesso no data center, os dados salvos ali estão 100% protegidos contra qualquer ameaça digital.


2. Air-gap lógico ou imutabilidade (O modelo moderno)

Basicamente, sabemos que mover fitas manualmente exige esforço operacional e encarece o RTO, então o mercado evoluiu para o isolamento lógico combinado com nuvem ou storages dedicados.

Então, na prática, os dados são enviados para um repositório isolado, que pode ser um bucket na nuvem ou mesmo on-premises, em um appliance protegido. Assim que a transferência acaba, a conexão é bloqueada via software por firewalls restritivos. Além disso, ativa-se uma política de imutabilidade. A gente conhece isso nas fitas do tipo WORM (Write Once, Read Many): O arquivo não pode ser deletado ou alterado por ninguém durante um período de retenção predefinido, nem mesmo por uma conta de Admin comprometida.


Então, físico ou lógico: Qual escolher?

Veja abaixo um comparativo que ajuda a planejar qual abordagem seria a melhor:




A evolução da regra 3-2-1

Muitos de nós crescemos seguindo a clássica regra 3-2-1 (3 cópias de dados, em 2 mídias diferentes, sendo 1 fora do site). Ou pelo menos tentando implementar.... hahah. Porém, diante do cenário atual de ameaças, o mercado adotou uma outra: a regra 3-2-1-1.

Esse último "1" representa a obrigatoriedade de manter pelo menos uma cópia dos dados em estado imutável ou sob efeito de Air-gap. É como se fosse uma carta na manga que garante a resiliência do ambiente e a continuidade do negócio quando todas as outras defesas falharem. Lembrem-se, somos a última linha de defesa da empresa.

Não deixe de revisar seu ambiente. Faça sugestões aos seus superiores. Esteja à frente das ameaças. Formalize suas idéias/propostas. 

E se você já implementou alguma estratégia de Air-gap ou imutabilidade no seu ambiente, deixa um comentário relatando sua experiência.


Aquele abraço

Sasso

quinta-feira, 16 de julho de 2020

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
















segunda-feira, 6 de julho de 2020

Netbackup - Como reduzir os logs do /usr/openv com segurança

Fala pessoal, tudo bem?
Aqui vai uma dica rápida, se vocês tiverem algum problema de falta de espaço no /usr/openv no Master Server e precisarem fazer alguma limpeza, cuidado com a limpeza. Não saiam apagando qualquer coisa sem ter plena certeza do que se trata.

Você pode utilizar um comando chamado vxlogmgr com a opção -d. Ele irá apagar com segurança logs não mais necessárias ao ambiente e assim liberar um pouco de espaço.

No exemplo abaixo dá para ver que o /usr/openv está com 76%

Rode o comando

Ele lista a quantidade de logs a serem deletadas e pergunta se quer continuar.

Ao final podemos ver no exemplo que o FS baixou para 75%.


Isso foi apenas um exemplo do que fazer em uma necessidade de emergência. Avalie o seu ambiente e veja se não é o caso de aumentar o filesystem ou se o ofensor for o catálogo, se já não é hora de criar um novo domínio, ok?

Forte abraço
Sasso




segunda-feira, 29 de junho de 2020

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

terça-feira, 23 de junho de 2020

Netbackup - Instalando o binário sem precisar copiar os pacotes

Olá pessoal tudo bem?
Em algumas situações é necessário instalar o client do Netbackup. Ocorre que o binário da versão 8.1.2 não é tão pequeno e sendo assim temos 2 problemas ou no mínimo 2 possíveis ocorrências.

- Não ter um FS com espaço suficiente
- O tempo para fazer cópia do binário para a máquina demora demais a depender da sua rede

Para esses casos e pensando em agilizar uma dica do que pode ser feito.

Algum servidor na rede que tenha espaço para ser utilizado como repositório, como o próprio masterserver ou outra máquina.

O print abaixo mostra o passo a passo.

- cria um diretório
- usa o comando mount para montar o file system da máquina onde está o repositório para a máquina que você quer
- o df -k mostra certinho que o FS está montado.
- faz o processo de install (nesse ponto eu cancelei porque a ideia é só mostrar o processo)
- desmounta o file system com o comando umount
- remove o diretório que você criou.
- fim.

























Até a próxima
Abs,
Sasso




terça-feira, 16 de junho de 2020

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















quinta-feira, 11 de junho de 2020

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.


domingo, 7 de junho de 2020

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

segunda-feira, 1 de junho de 2020

Netbackup - Tratando erros Win32 xx: Unknow Error

Fala galera, tudo bem com vocês?

Caso vocês possuam policies do time MS-Windows, vocês podem encontrar algum tipo de alerta que ao analisarmos a log no detalhe, o NBU sempre vai mostrar um erro Win 32 xx: Unknow error.

As vezes temos dificuldade em localizar e tratar algumas falhas assim, mas tem um link no próprio site da microsoft que pode dar um direcionamento no troubleshooting e resolução das falhas.

Segue o link:








Espero ter ajudado.
Abraços

terça-feira, 26 de maio de 2020

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.


sexta-feira, 22 de maio de 2020

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



sábado, 4 de junho de 2011

Problema TDP for Exchange

Pessoal, boa tarde,

Peço desculpas, sei que não postei aqui ainda como instalar e customizar o TDP for Exchange, mas como tive um problema ontem e afinal de contas, esse blog é exatamente para trocarmos idéias sobre nosso cotidiano, resolvi colocar os problemas que tive e o que foi feito para resolver. Em uma outra oportunidade, postarei como instalar e configurar o TDP.

Ontem coloquei aqui no blog um video onde estava preparando o TSMServer para receber um ambiente de Exchange.

Após isso, iniciei a configuração do TDP for Exchange em cluster, só que tive alguns contratempos, o qual gostaria de compartilhar, e o que foi feito para resolver.


Erro 1.:
ACN5237E Unable to communicate with the Microsoft Exchange Server
O TDP for Exchange utiliza como default o hostname local do servidor como sendo o nome do Exchange Server. Em um ambiente cluster, os administradores do Exchange normalmente não utilizam o hostname local ou hostname da máquina física para setar o Exchange Server. Eles usam um hostname Virtual (Exchange Virtual Server).

"C:\Program Files\Tivoli\TSM\TDPExchange\tdpexc.exe"

Dê um espaço em branco e acrescente as seguintes opções.:


Obs.: Atente

Então nossa linha de comando ficará assim.:

"C:\Program Files\Tivoli\TSM\TDPExchange\tdpexc.exe" /EXCSERVER=exchange_server_name /TSMOPTFILE=x:\path\dsm.opt

Pronto, meu problema foi resolvido, pensei..... mas....

Erro 2.:
ACN5238E Unable to retrieve the domain information
Este erro é ocasionado se o seu usuário não tiver permissões suficientes. Apesar de saber disso, os administradores de Exchange, garantiam que meu usuário estava Ok. Mas não estava.
 
Precisei passar o link da IBM onde mostra claramente o erro e o que deve ser feito.
 
Vou reproduzir aqui.:

Cause
This problem is caused by running Data Protection for Exchange while logged in under a userid without enough permissions. Data Protection for Exchange requires that the userid have the "Exchange View Only Administrator" or higher permission. Without enough authority, the Windows operating system will not allow Data Protection for Exchange to access the Exchange objects necessary to perform the operation.

Answer
There are two solutions to this problem:

1. Use the Microsoft Exchange System Manager to add the required permissions to the userid performing the Data Protection for Exchange operations.

or

2. Login in to Windows under a userid that already has the proper permissions to perform the operations.


Pronto. Feito isso, problema resolvido, backup full iniciado e executado sem erros.


Qualquer dúvida, sugestão, crítica ou correção, por favor, mandem mensagens para o blog ou enviem um email para tsmnapratica@gmail.com


Um abraço a todos.