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.

Algumas consultas (querys) no TSM

Olá, boa tarde a todos...

Tenho recebido algumas perguntas muito interessantes, as quais, sempre que possível respondo por email mesmo.

O post de hoje é para responder para um colega iniciante na área, que tem demonstrado muito interesse em se aprimorar em TSM.

No TSM, é possível extrair diversas informações através de querys SQL. Essas querys facilitam e muito nosso dia-a-dia, onde é possível, por exemplo, traçar estimativas de crescimento com base na volumetria de backup gerada mês a mês. 

A dúvida de hoje é mais simples.: Como faço para descobrir quais foram as últimas fitas utilizadas no ambiente ?

Um select básico seria este.: 

select volume_name, last_write_date from volumes order by last_write_date

Mas é possível incrementar com mais informações, caso seja necessário, por exemplo se seu ambiente tiver muitos stgpools.:

select volume_name, stgpool_name, last_write_date from volumes group by stgpool_name, last_write_date, volume_name

Quantas fitas cada stgpool está utilizando.:

select stgpool_name, count(volume_name) as QTD_FITAS from volumes group by stgpool_name

Há fitas com erros de leitura ou gravação no ambiente.:

select stgpool_name, volume_name from volumes where write_errors<>0 or read_errors<>0

Eis alguns exemplos, mas há com certeza uma infinidade de querys possíveis. Sempre tomando cuidado com o tipo de query, uma vez que selects grandes, podem causar lentidão no TSMServer e em alguns casos extremos, quedas.

Um abraço a todos.

Conselhos para novos administradores - Parte Final

Ao investigar os erros de sessões, olhe em ambas as pontas da sessão:

Os arquivos do ADSM-L estão cheios de publicações sobre problemas de sessão onde o técnico local olhou para indicações sobre apenas o client final da sessão que falhou. Obviamente, se o TSMServer cancelou a sessão, terá registrado algumas informações sobre o motivo. (A razão para os problemas da sessão é quase sempre encontrado no TSMServer.) Examine indicações em ambas as pontas da sessão para obter toda a imagem. Poste perguntas sobre erros de sessão no ADSM-L somente depois de investigar o todo, e não encontrar a resposta.

Verifique o anti-virus onde está rodando Jobs de backup:

Há inúmeros problemas provocados pelo anti-vírus, não só para o TSMServer, como para qualquer outro software de backup, quando executado, ao mesmo tempo em um servidor onde o backup está ativo. Funcionalidade e desempenho sofrem.

Não deixe que os usuários finais ditem as escolhas tecnológicas:

Dentro de uma organização, os usuários finais tendem a ser conhecidos por ditarem como um sistema deve ser implementado, com base em seus conhecimentos limitados e geralmente obsoletos para tecnologia de processamento de dados. Departamentos do usuário final são responsáveis por transmitir as necessidades do negócio, e não definir opções tecnológicas. O departamento de TI está, suponhamos, mais apto a opinar sobre tecnologias, e deve determinar a melhor implementação. Por exemplo, alguns usuários finais podem chegar a um esquema de backup para diários, semanais e mensais – obviamente com base em como eles viram, no passado, o funcionamento de alguns produtos de backup. Seus esquemas, provavelmente, não tem nada a ver com as necessidades do negócio, e se for seguido seria subverter as capacidades do TSMServer que custou caro para a empresa, que o adotou, para segurança inteligente dos dados de negócio.

Não use todos drives para fins administrativos:

Há ocasiões em que você, como administrador do TSMServer quer fazer um monte de coisas, como fazer o backup de stgpools, reclaim e restore de fitas, e por isso somos tentados a usar cada drive. Não! Na maioria dos ambientes, solicitações de clients podem vir a qualquer momento. A ocupação de todos os drives, no mínimo causará delay nas sessões. Também pode causar que os processos administrativos sejam preteridos ... e se você esperava liberar fitas scratchs o suficiente com o reclamation, próximo ao horário da janela de backup, você pode, (e muito provavelmente será) ser rudemente surpreendido mais tarde.

Conselho para análise de um problema. Alguns pontos nesta área:

- Na lista de discussão(mailing do ADSM), vemos muitas postagens sobre problemas de performance que começa com.: "Nós temos dois sistemas idênticos ...". Nunca acredite que dois sistemas são idênticos. Tal coisa é fisicamente impossível, e se acredita, irá inibir uma análise mais produtiva de problemas de performance do sistema. Diferenças são saudáveis, e dar a oportunidade de comparar os efeitos de diferentes ingredientes.

 - Como uma extensão do exposto, não entre em uma análise de qualquer sistema com noções preconcebidas de como as coisas estão acontecendo nesse sistema. Faça isso e você vai se cegar para funcionamento do sistema real. Coloque-se em uma mentalidade de procurar, para saber o que está acontecendo, e sua análise será muito mais eficaz.

 - "Mas, nada foi mudado!" Bem, às vezes, isso é uma coisa ruim. Sistemas podem rodar durante muito tempo, muito bem, apesar de terem software, firmware, ou adaptadores com problemas latentes. Muitas vezes, há mensagens de erro em “backuground” que aparecem, mas o cliente ignora, porque "as coisas estão funcionando". Tudo que torna uma situação incomum, porém, para causar a falha total, como o hardware e/ou software, de repente enfrenta condições que estão além ou incompatível com sua programação. Ignorando os sinais de perigo é uma má idéia. Mantenha seu sistema com boa saúde.

Não confie cegamente nos fornecedores:

Nós queremos que todos sejam confiáveis, mas em questões envolvendo dinheiro, a confiança tem de ser mensurada. Enquanto os fornecedores são geralmente escrupulosos, há aqueles cujas mentalidades fazem com que habitualmente recorram a truques sujos (Microsoft é um exemplo), e casos em que ocorrem lapsos, como quando surge um novo executivo. Em particular, tenha a certeza de que sua área de compras/jurídico debrucem sobre todos os detalhes contratuais.

Espere verrugas:

Não crie expectativa de que nenhum release de qualquer software seja perfeito. Todo release de qualquer coisa tem algumas verrugas. Por exemplo, upgrade para o TSMServer 5.2.4 para resolver alguns problemas e obter menor incômodo do query process com texto desalinhado para processos de Reclaim. A palavra de ordem na vida: "É sempre alguma coisa."

Baixe os docs de fornecedores enquanto estão disponíveis:

Há uma tendência natural a considerar que a documentação online do fornecedor como sempre estar lá e de fácil acesso. A realidade é que os fornecedores (mesmo IBM) derrubem seus servidores web horários de pico (apenas quando você pode estar em apuros); e eles removem os docs mais antigos para liberar espaço para os novos. Então, quando você encontrar um PDF útil, utilize todos os meios para salvar uma cópia no seu sistema local. Isso vai tornar o acesso rápido e seguro.

Incentive a atualização da arquitetura de dados do departamento de TI da empresa:

Regularmente vemos postagens de administradores TSM tentando lidar com um backup de um filesystem contendo um número enorme de arquivos (muitos milhões), resultando em ANS1030E e outros problemas; e vemos também, sistemas 32bits, relativamente pequenos, controlando terabytes de dados. Tais situações são normalmente encontrados em sistemas Windows, que estão sob o controle de grupos de trabalho que são destemidos por conceitos de processamento de dados e consideram o sistema Windows como assim como o PC que eles usam em casa. O resultado comum é um único filesystem ocupando discos inteiros: este filesystem é enorme, e eventualmente 100% ocupado, com um grande número de arquivos. O resultado é uma massa de dados pesada, problemática, difícil de fazer backup e singularmente vulnerável a um problema de mídia ou de corrupção lógica. Arquitetura racional para organização de dados em partições de tamanho razoável, facilitando o gerenciamento e o backup, e eliminando o ponto único de falha. Uma organização com um bom departamento de TI irá publicar diretrizes sólidas para as melhores práticas na implementação de discos e filesystems, para ajudar a evitar passivos.

Planeje tirar proveito da evolução dos drives:

Alguns sites, por vezes, utilizam-se de uma library e um modelo de drive e nunca pensam em evoluir conforme o tempo passa, e se aproximam de esgotamento da capacidade. Os sites deveriam planejar a migração dos drives para as gerações posteriores de sua tecnologia, o que permite manter uma margem de capacidade saudável dentro dos limites da library existente. Por exemplo, uma  library 3494, com drives 3590E pode aumentar em 10x ou mais em capacidade, adicionando drives 3592 – uma evolução que não exige mais uso de espaço físico, e até economiza em energia e remoção de calor. Librarys SCSI podem desfrutar de ganhos semelhantes aos avanços da tecnologia LTO.

Se estiver rodando Unix, instale o comando lsof.

O comando lsof é uma ajuda inestimável para a análise do sistema, listando arquivos, portas, sockets, e outros objetos em seu ambiente operacional. Usando este comando, você pode determinar imediatamente quais portas seus TSMServer e client estão usando.

Para dúvidas, críticas, sugestões ou correções, postem no blog ou mandem um email para tsmnapratica@gmail.com.

Um abraço!

Diferença entre o Occupancy e o Import/Export

Por que há diferença de quantidade de objetos entre o Q OCC e as estatísticas do processo de import/export?

O comando Q OCC somente mostra os dados que estão retidos nos respectivos stgpools (tanto o primário quanto o pool de cópia, se houver). O Q OCC mostra a quantidade de arquivos, o espaço lógico e o espaço físico ocupado, e qual stgpool estão esses objetos.

O Q OCC não mostra os objetos que não estão armazenados no stgpool. O objeto que mais se enquadra nessa situação são os diretórios. Diretórios somente ocupam espaço no DB do TSM.

O processo de import/export irá reportar todos os dados que serão gravados em fita. Isto inclui todas as definições do nodes assim como todos os arquivos (objetos) que aparecem no inventário do server que se enquadram na especificação do FILEDATA. O processo de import/export conta cada um desses objetos bem como o tamanho. Com uma grande quantidade no número de diretórios envolvidos no processo, teremos uma grande diferença no "número de arquivos" entre o Q OCC e as estatísticas do import/export.

Portanto, os dados do occupancy deveriam ser usados apenas para estimar as estatísticas do processo de import/export.

Delete Filespace

Qual a ordem de deleção de objetos que o TSM faz quando rodamos o comando DELETE FILESPACE ?

A pergunta é válida para os casos em que alguém executa esse comando e logo em seguida, percebendo o erro, faz o cancelamento do processo.

O DELETEFILESPACE irá deletar todos os arquivos de todos os filespaces existentes no node. A deleção de objetos é executada em uma ordem para minimizar os danos caso o comando seja erroneamente executado.

A ordem de deleção será a seguinte.:

1- Backups Inactives

2- Backups Actives

3- Archives

4- Space managed files

Caso tenham alguma dúvida, sugestão, correção ou críticas, por favor escreva para tsmnapratica@gmail.com.

Qual fita utilizar em um restore ?

Um das coisas que considero ruim no TSM e que a IBM poderia melhorar é.: Como identificar facilmente quais fitas vou precisar para um determinado restore?

Sabemos, por exemplo, que o Netbackup em um processo de restore, basta clicar no botão PREVIEW, que ele informa qual fita será utilizada.

E no TSM?

Se você possui um ambiente pequeno, provavelmente todas as fitas estarão no robo, então não tem do que se preocupar. Com ambientes corporativos, de grande porte, pode ser um pouco complicado, pois provavelmente a quantidade de SLOTS disponíveis no seu robo não são suficientes para armazenar todas as suas fitas.

Podemos utilizar o comando query nodedata . Ele trará todas as fitas associadas a um determinado node, facilitando assim, a identificação das fitas.

E se tivermos um node com muitos filespaces e precisarmos fazer o restore de somente um deles? Abaixo tem um select que irá ajudar a indentificar essas fitas.

select volumeusage.node_name, volumeusage.filespace_name, volumeusage.volume_name from volumes,volumeusage where volumes.volume_name=volumeusage.volume_name and ((volumeusage.node_name='NODE_NAME') and volumes.LAST_WRITE_DATE between timestamp('AAAA-MM-DD HH:MM:SS.000000') and timestamp('AAAA-MM-DD HH:MM:SS.000000') and (volumeusage.filespace_name in ('FILESPACE_NAME')))

Utilize o timestamp para filtrar a data, como por exemplo, mostrar todas as fitas utilizadas entre 01/12/2011 a 19/12/2011.

Qualquer dúvida, sugestão, reclamação ou correção, entre em contato pelo blog ou pelo email tsmnapratica@gmail.com

Um abraço a todos.

Conselhos para novos administradores - Parte 5

Se você tiver uma library grande, monitore-a:

Se você tem uma library grande, como uma 3494/3500, sobre a qual a organização depende, somente faz sentido implementando monitoração ativa para assegurar que está operacional e que envie alertas em tempo real quando um problema é detectado. Esperar o TSM detectar um erro pode significar descobrir muito tempo depois um problema já iniciado e recebendo indiretamente (e potencialmente obscuros) indicações que levam muito tempo para rastrear o motivo pelo qual a library está down.

Você pode colocar uma monitoração básica, algo tão simples como uma invocação periódica(loop) do comando ‘mtlib’, por exemplo.

Trate os problemas no primeiro indício que o problema existe!

Surpreendentemente, alguns clientes imediatamente implementam ações de correção arbitrárias antes de descobrir o que realmente causou o problema. Por exemplo, o técnico encontra fitas 3590 com status Unavailable e executa um audit library. Errado! Librarys 3494 mantém consistência própria e não necessitam de AUDITS. Problemas de hardware e intervenção humana (remoção de fitas da library) fazem com que as fitas fiquem com status Unavailable.

Implementar uma correção de um software baselevel durante um problema de hardware, é no mínimo desperdício de tempo, e pode até mesmo causar coisas piores.

Lembrem-se.: Os médicos não aplicam um tratamento antes do diagnóstico, e você também não deveria fazer.

Sempre considere o seu ambiente Server & Client como um todo:

Server e clients devem ser capazes de interoperar como um amálgama totalmente compatíveis. Ao considerar uma atualização do Server, o que é absolutamente essencial ter suas versões no nível mais alto, planeje também atualizar os clients que até podem funcionar. Por mais óbvio que este conselho possa parecer, ainda vemos postagens em fóruns, de administradores que atualizaram o TSMServer sem considerar os clients, e se perguntam por que alguns de seus clients não funcionam mais, e/ou o que as mensagens estranhas do Server querem dizer. Lembre-se que os fornecedores podem garantir (por seus testes), limitado a apenas algumas combinações Server e Client: faça a disparidade muito grande e os resultados serão imprevisíveis.

Use a sincronização de tempo em seus computadores!!!

Sincronizar os relógios dos computadores a um padrão de tempo é fundamental para as operações client-server. No mínimo, relógios atrasados, podem causar confusão durante o debug de um erro, e pode atrapalhar operações sensíveis como a autenticação Kerberos. Um simples comando, como o ‘dsmc q ses’ irá mostrar o horário atual do Server, para comparar com o horário do Client.

Logs:

O TSM tem a capacidade (e pode) produzir uma variedade de logs para Clients e Server. O Server possui o actlog; O Client possui a log de Schedule e a log de Erro; E os TDPs possuem logs. Além disso, o Sistema Operacional possui suas logs de mensagem. Você tem a habilidade de suprimir as logs, como a opção quiet do Client Option. Aqui você decide qual log armazenar, quanto de log será armazenado e por quanto tempo.

Mas, é você sozinho que tomará esta decisão? Seu site provavelmente tem normas que são aplicadas pelos auditores, definindo a extensão das logs e a retenção das mesmas, conforme o tempo necessário, segurança e outros requisitos. Note que o produto HSM do TSM, ou a sua função Archive, pode ajudar muito no gerenciamento de log. HSM em particular é muito útil porque permite que todos os logs estejam visíveis em um sistema de arquivo hierárquico, enquanto ao mesmo tempo, ocupa o mínimo de espaço no file system.

Validar um novo client antes de habilitar sua utilização:

Preocupantemente, muitos sites instalam um client e depois simplesmente executam full backups (pior, com um schedule) sem validação inicial que está corretamente instalado, configurado, ou totalmente utilizável. Então, quando ele não funciona como esperado, eles ficam confusos, e enviam diversas mensagens através de foruns, perguntando "O que há de errado?" Obviamente, quando se introduz um novo software, ele precisa ser instalado de acordo com instruções do fornecedor (não se esqueçam o arquivo README), então, ser configurado de acordo com o manual que corresponde a sua versão/release e depois validá-lo. Aqui estão alguns passos básicos de validação:

- Execute o comando 'dsmc q opt' para verificar que os parâmetros utilizados são válidos, e, se terá efeito, uma vez que este irá executar a primeira interação com o servidor TSM e irá procurar todas as opções do client setadas no lado do server.

- Execute o comando 'dsmc q inclexcl’ para verificar se os Include/Exclude são válidos. (Nem todos os includes/excludes são setados no client: alguns podem ser definidos no server.)

- Faça um backup teste para ver como se comporta este novo client com as opções setadas: 'dsmc selective '. Isto irá exercer o fluxo do path entre o client e o server, através do stgpool primário definido via Management Class e o Copy Group, que vão descobrir um possível problema e se as definições necessárias ou recursos não estão no lugar no server.

- Agora execute o comando 'dsmc incremental’ em um diretório, para testar esse tipo de backup.

- A maioria dos backups devem ser executadas através de um ClientSchedule, portanto, verifique esta funcionalidade através do immediate (define clientaction).

- Vá em frente para testar quaisquer outras funções que este client irá utilizar (Archive, Images, etc.)

Note que tudo isso é exercício. Qualquer novo filespaces criado durante os testes, podem ser descartados, ao final, se desejar. Se os problemas ou anomalias ocorrerem, verifique o dsmerror.log no client e o actlog no server. Execute o comando ‘query session’ no server durante e após os testes, em busca de problemas e verifique a transferência de dados em ambas as direções, pelas estatísticas relatadas. O Guia de Problem Determination do TSM está disponível para pesquisar erros, buscar dicas a respeito de erros reportados no client. Você também pode executar o client sob o comando ‘truss’ do Unix para ver o que está acontecendo, e o TSM Client rastrear sua disponibilidade.

Depois de subir a versão do client, teste:

Difícil de acreditar, mas muitos sites fazem coisas como subir a versão de seus clients e apenas aguardam a execução dos backups de produção da noite: SEM TESTES! Evitem pagar o preço de "assumir o risco": TESTE!!!.

Basicamente verifique primeiro como 'dsmc q opt' e 'dsmc q fi' deve ser feito para verificar se todas as opções estão rendendo o que se espera, e que a interação client-server básico pode ocorrer com sucesso. Então, é saudável para executar um define clientaction no server, para executar uma coisa básica como o comando 'date' um sistema operacional no cliente, para garantir que o mecanismo scheduler está funcionando. Em seguida, tentar um backup trivial.

Qualquer dúvida, sugestão, críticas ou correções, por favor escreva.

Um abraço.