quarta-feira, 26 de dezembro de 2012

TSM Database Backup

Pessoal, tudo bem?

Recebi algumas perguntas sobre o backup do DB e pelo teor dessas perguntas, é possível concluir que principalmente novos "desbravadores" dessa poderosa ferramenta possui algumas dúvidas sobre como lidar com ele.

Eu considero, basicamente o backup do DB do TSM o backup mais importante do nosso ambiente, uma vez que é nele que estão todos os apontamentos, informações a respeito de todo ambiente de backup, desde informações de server e clients, até informações sobre o gerenciamento dos dados armazenados.

E por que o backup do DB é o mais importante? Se o servidor do TSM sofrer um crash e houver corrupção do DB, será necessário fazer restore dele. Se você não possuir um backup atualizado, o banco voltará com a posição do último backup e dessa forma perderá todas as informações gravadas e armazenadas desde a data do último backup até o crash.

Exemplo (verídico).:
O ambiente TSM foi implementado em 01/MAR/2012 e o último backup do DB foi executado nessa data. Infelizmente, hoje 26/DEZ/2012, caos o DB seja corrompido, será necessário fazer o restore com base no último backup full, ou seja, se o último backup do DB foi no dia 01/MAR, todos os backups gravados entre 01/MAR e 26/DEZ foram definitivamente perdidos. Isso ocorre porque, todos os dados gravados nas fitas de lá para cá, ao voltar o restore é como se esses dados não existissem, já que o TSM voltará com data de 01/MAR.

Para verificar quando foi o último backup do DB, utilize o comando.: q volhist t=dbb ou t=dbs

Tipo de Backup
Full - Executa o backup full do banco do TSM.
Incremental - Executa um backup incremental de todos os dados do DB que foram modificados desde o último backup full executado com sucesso.
DBSnapshot - Executa um backup full (image) do banco do TSM sem interromper o ciclo de execução dos backups fulls e incrementais. Normalmetne utilizado para ambientes com DRM configurado, já que essas cópias, são as que vão para cofre externo (offsite).

Executar o backup do DB é um processo administrativo. Com um schedule t=a é possível agendar sua execução, e da mesma forma que o backup é agendado é possível checar sua execução com um simples query event.

Execução
A execução do backup do DB é simples e lembre-se que na dúvida de executar algum comando, na própria console é possível chamar o HELP que mostrará todos os parâmetros necessários.

Exemplo de Backup Full (DBB).
backup db devc=device_class_name type=full scratch=yes wait=yes

Exemplo de Backup Incremental
backup db devc=device_class_name type=incremental scratch=yes wait=yes

Exemplo de Backup Snapshot (DBS)
backup db devc=device_class_name type=dbs scratch=yes wait=yes

Criando um schedule administrativo para o backup do DB.:
def sched backup_db t=a cmd='backup db t=full devc=lto scratch=yes wait=yes' active=yes startt=09:00 startd=today per=1 peru=day day=any

O resultado desse comando é a criação de um schedule chamado BACKUP_DB que executará um backup full todos os dias as 09:00hs

Para checar a execução do schedule.: q event backup_db t=a
Ou você pode checar diretamente o volhistory.: q volhist t=dbb

Um abraço e um excelente 2013 a todos os colegas, principalmente aqueles que estarão de plantão nessa virada!

quarta-feira, 29 de agosto de 2012

Atraso em respostas!!!

Pessoal, boa tarde,
Peço desculpas por demorar em responder aos emails que recebo. Estou passando por alguns momentos turbulentos na empresa onde acabei me distanciando dos posts e dos emails.

Estou respondendo na medida do possível, já que a lista não é muito pequena...rs ainda bem

Em paralelo a isso, convido a todos a escreverem artigos ou dicas sobre alguns problemas que passaram e como fizeram para resolver. Mande para o email tsmnapratica@gmail.com que assim que possível, será publicado.

Um abraço

sexta-feira, 18 de maio de 2012

Dica sobre Include

Oi pessoal, desculpem a demora, ando meio atribulado com alguns assuntos na empresa.

Recebi uma dúvida essa semana de um colega sobre um problema que ele estava tendo com INCLUDE. Basicamente o problema consistia que o backup somente gravava diretórios, sem levar os arquivos e como solução (paleativa), era necessário colocar include para cada subdiretório que existia.

O INCLUDE que ele estava passando era.:
Include "C:\XPTO\*"     MgmtClass

A sugestão que passei foi utilizar esse INCLUDE.:
Include "C:\XPTO\...\*.*" MgmtClass

A idéia é porque o \... entende que pode haver de 0 a n diretórios abaixo da pasta raiz XPTO, portanto o *.* irá incluir todos os arquivos encontrados.

Recebi depois feedback do colega dizendo que funcionou!! 

A lista de possibilidades para trabalhar com Includes e Excludes é enorme. Qualquer dia vamos escrever mais a respeito.

Qualquer problema, dúvida, sugestões ou correções, mande um email para tsmnapratica@gmail.com ou poste um comentário como fez nosso colega Cartola.

Um ótimo dia a todos!

quinta-feira, 5 de abril de 2012

Erro em restore de Exchange via TDP




E lá vamos nós novamente falar de erro em Exchange.....

Confesso que geralmente são os mais chatos de tratar. Hoje ao executarmos um restore, nos deparamos com o seguinte erro.:

ACN0151E The restore environment information isn't found or can not be opened.


Muito bem. Basicamente esse erro ocorre quando o path informado no parâmetro TEMPLOGRESTOREPATH  não está acessível. Acontece muito em ambientes em cluster ( é o nosso ambiente ).

Para resolver basta colocar um path válido e acessível.




Um abraço.

quarta-feira, 21 de março de 2012

Fitas Utilizadas X Fitas Liberadas

Oi pessoal,
Esses dias estava conversando com um ex-colega de trabalho sobre utilização e liberação de fitas no TSM. A idéia é manter um controle de quantas fitas o TSM está consumindo e por outro lado quantas fitas scratchs o TSM está liberando através de seus processos administrativos.

Uma das formas que podemos fazer isso é através de selects. Sempre que o TSM associa uma fita scratch a um stgpool, ele emite um alerta informativo. E por outro lado, sempre que o TSM libera uma fita para scratch, ele também emite um alerta informativo.

Os alertas são.: 
- Para fitas liberadas.: ANR1341I
- Para fitas consumidas.: ANR1340I


Para sabermos o que significa esses alertas, basta chamar o help na console do TSM.

Exemplo.:

tsm: TSMSERVER>help ANR1340
ANR1340I  Scratch volume volume name is now defined in storage pool storage pool name.

Explanation: The scratch volume specified has been added to the storage pool shown.
System action: None.
User response: None.


tsm: TSMSERVER>help ANR1341
ANR1341I  Scratch volume volume name has been deleted from storage pool storage pool name.

Explanation: The scratch volume specified is no longer in use and has been removed from the indicated storage pool.
System action: None.
User response: None.



Obviamente a conta não é exata, pois não estamos checando se a fita consumida está 100% FULL ou se está 1% Filling. Estamos apenas tirando uma estimativa.

Podemos usar os seguintes selects para verificar um intervalo de tempo determinado.:
select count(msgno) as "FITAS CONSUMIDAS" from actlog where msgno=1340 and DATE_TIME between timestamp('2011-06-01 00:00:00.000000') and timestamp('2011-06-30 23:59:59.000000')

select count(msgno) as "FITAS LIBERADAS" from actlog where msgno=1341 and DATE_TIME between timestamp('2011-06-16 00:00:00.000000') and timestamp('2011-06-30 23:59:59.000000')

Um abraço.

sexta-feira, 9 de março de 2012

Como desativar um schedule de backup temporariamente

Como fazer para desativar um schedule de backup temporariamente? Seja por um dia apenas ou por vários dias.

Basicamente podemos fazer de duas formas.:

Desassociando o node.: del assoc

Exemplo.:

tsm: TSMSERVER3>del assoc PD_LDC_FS BRASPO001_INCR_DIA BRASPO001_DIA

Do you wish to proceed? (Yes (Y)/No (N)) y
ANR2511I Node BRASPO001_DIA disassociated from schedule BRASPO001_INCR_DIA in policy domain PD_LDC_FS.

Ou

Dando atualizando o schedule para voltar a executar em XX dias.: upd sched startdate=+3

Exemplo.:

tsm: TSMSERVER3>update schedule PD_LDC_FS BRASPO006_INCR_DIA startd=+3
ANR2502I Schedule BRASPO006_INCR_DIA updated in policy domain PD_LDC_FS.



Eu particularmente prefiro utilizar o update schedule, pois se por acaso, você se esquecer, ele volta a executar normalmente daqui a 3 dias de forma automática.

Diferentemente do delete assoc, que se você utilizar, obrigatoriamente deverá fazer o define assoc novamente, caso contrário o schedule não será mais executado.

É possível ainda utilizarmos scripts e schedules administrativos para deletar e definir associações, garantindo assim que os schedules sejam desativados e re-ativados automaticamente.

Exemplo (quero desativar meu schedule no dia 10/03/2012 as 20:00hs e quero que ele volte a executar no dia 11/03/2012 as 19:00hs).:

Nesse caso, vamos definir dois schedules administrativos que conseguimos resolver nosso problema.

Schedule 1
define schedule altera_scheds t=a cmd='del assoc domain schedule node' active=yes starttime=20:00 startdate=03/10/2012 peru=one day=any

Schedule 2
define schedule volta_scheds t=a cmd='def assoc domain schedule node' active=yes starttime=19:00 startdate=03/11/2012 peru=one day=any

Uma observação.: Tenha em mente que qualquer alteração, faz com que as evidências de execução não apareçam mais no Q EVENT, isso porque o EVENT é uma view e não uma tabela propriamente. De qualquer forma, se fizer alguma alteração e precisar buscar no TSM evidência de execução, utilize o ACTLOG (q act begind=-10 endd=today se=schedule_name)


Se pensarmos que em nosso ambiente corporativo, a lista de tarefas e atividades são grandes e que executamos muitas coisas em paralelo, a probabilidade de esquecermos de voltar o schedule é grande, portanto é mais garantido utilizar o update schedule.



Bom fim de semana a todos.