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.

Conselhos para novos administradores - Parte 4

Pessoal, desculpem a demora em continuar com esses textos, mas tive um contratempo familiar e não consegui atualizar.

Mas vamos lá, dando sequência a alguns conselhos para novos administradores.

 Busque referência e valide um hardware antes de tentar utilizá-lo no TSM:

É incrível, mas muitos analistas de sistemas instalam novas librarys ou drives em seus sistemas operacionais e logo em seguida tentam usá-lo no TSM. Então eles simplesmente escrevem para ADSM-L dizendo que "não funciona", com o comando ‘lsdev’ no AIX para mostrar os devices com status Defined em vez de Available.

Você precisa validar totalmente, e depois buscar referências de novos hardwares antes colocá-lo em produção, sob qualquer aplicação. Validação significa testá-lo totalmente no nível do sistema operacional para assegurar sua funcionalidade por completo. Por exemplo, a nova library pode pegar uma fita do CAP(chamado também de I/O Station ou Bulk), reconhecer o seu código de barras, e armazená-la em um slot? Via comando ‘mtlib’ ou similar, a library vai responder para montar a fita designada? Eu consigo gravar na fita o volume de dados que eu espero que ela tenha capacidade, via comando ‘tapeutil’ ou outro comando?

Benchmarking é importante: Você compra um equipamento com base no que o fornecedor afirma sobre a capacidade e desempenho; Então você não deve medir a sua performance para ver se ele atende seus requisitos? Considere as ramificações de *não* fazer benchmarking, e mais tarde sendo colocado em produção e os usuários reclamando de baixa performance.

É no teste geral que você descobre coisas como throughput sendo a metade do que você esperava (talvez porque o adaptador SCSI está definido para a velocidade errada), a library tendo problema de leitura no barcode, devido a labels baratos que você comprou, a operação da unidade de fita com problemas devido a um microcódigo errado, etc.

Nunca assuma as configurações defaults:

A boa administração *nunca* permite os defaults, em parte porque não informa a possibilidade de alteração nos arquivos de configuração, e em parte porque você ficará à mercê do fornecedor devido a uma mudança arbitrária.

Evitar misturar dados de curta e longa retenção na mesma fita:

Este é outro problema no desenho de configuração do seu ambiente. Você pode ter múltiplos filespaces que se misturam nos mesmos volumes(fitas). Se os respectivos arquivos têm retenções muito diferentes, os volumes vão acabar prematuramente com um monte de "buracos" onde os dados de curta retenção expiraram, o que eleva a quantidade de processos de reclamation que você terá de executar - o que é mecanicamente ruim para as unidades de fita, e pode interferir com outros schedules.

Não fique na versão+release baselevel quando houver atualizações disponível:

Notavelmente, no ADSM-L encontramos muitos clientes instalando a versão+release baselevel (por exemplo, 5.5.0.0) e nunca mais faz a atualização - e em seguida, escrevem de problemas que estão tendo. Tenham em mente que o baselevel é apena: Um ponto de partida. As versões de manutenção, em seguida, começam a aparecer, fixando vários problemas e fazendo ajustes necessários. Se você não aplicou as versões mais recentes de manutenção, você está em uma posição onde não poderá resolver problemas já conhecidos e resolvidos. E não tome uma postura axiomático que você não pode atualizar um TSMServer sem atualizar todos os outros clients e agents em seu ambiente, ao mesmo tempo: Os componentes de TSM possibilitam muitas vezes que uma versão mais atual do Server, pode trabalhar normalmente com uma versão mais antiga do client.(Os manuais costumam especificar todas as versões suportadas pela IBM).

Conselho geral: Nunca implemente um ambiente apenas na versão baselevel do software. Espere um pouco para que uma nova versão tenha um código amadurecido antes de adotá-lo.

Caso tenham alguma dúvida, sugestão, reclamação ou correção, poste um comentário ou escreva para tsmnapratica@gmail.com

Um abraço!

Conselhos para novos administradores - Parte 3

Investigar os primeiros indícios de problemas:

Muitas vezes vemos em posts do ADSM-L onde um administrador fala ter percebido alguns dias antes indícios de um problema, porém não tomou nenhuma ação – e em uma última análise, o problema se tornou uma calamidade. Não ignore um indício de problema: a natureza está tentando lhe dizer algo.

Melhor ainda: Procure os problemas antes que eles martelem sua cabeça. A maioria das pessoas não olham o dsmerror.log a menos que alguma falha notória obrigue-o a fazê-lo; Esta log pode conter informações valiosas relativas a arquivos não encontrados, delay na rede, e problemas relacionados a fitas. Da mesma forma, analise os registros do Sistema Operacional para os problemas (por exemplo, AIX Error Log, Windows Event Viewer...etc).

Planeje as configurações do TSM para Recuperações, mais do que para Backups:

Muitos Administradores inexperientes, dada a tarefa de criação de TSM "no vácuo", planeja a configuração para a melhor performance de backups. Errado! O ponto crítico de todo o software de backup é a recuperação rápida de dados. Se você otimizar seu ambiente para backups, provavelmente o resultado irá causar impacto no momento de recuperação.

Por exemplo, o administrador novato não vai usar o collocation, fazendo com que todas as fitas sejam utilizadas por completo. Óbvio, ele faz isso; Mas no restore de um determinado node:filespace:diretório, o processo de recuperação terá que procurar em todas as fitas que estão compartilhadas com outros nodes, outros filespaces.

Isso não quer dizer que a velocidade de recuperação deve ser o único fator na hora de projetar seu sistema: Ir totalmente nesse sentido pode criar uma situação onde os backups terão sua janela de execução prolongadas, ou que necessite utilizar mais drives ou fitas que podem estar ou não disponíveis. Seu projeto, portanto, tem que estar compromissado para melhor otimizar o tempo de restore.

Uma boa tarde a todos!

Qualquer dúvida, crítica ou sugestão, entre em contato fazendo comentários nos posts ou enviando email para tsmnapratica@gmail.com

Conselhos para novos administradores - Parte 2

Pessoal, boa noite,

Vimos dicas importantes no post anterior, como o quão importante é conhecer o ambiente que estaremos administrando e uma das peças chaves para a boa administração que é a monitoração.

Vamos as dicas de hoje....

Mantenha registros:

Ao alterar qualquer arquivo de um sistema crítico, SEMPRE faça uma cópia antes. (Obs.: Eu criei um comando ‘bkupfile’, que executa um ‘cp –p’ para fazer uma cópia do arquivo, acrescentando-se um datestamp YYYYMMDD para indicar a data da mudança; E esse comando é usado religiosamente sempre que for realizar uma modificação em algum arquivo).

É de valor inestimável usar este procedimento, para apontar quando as mudanças foram feitas, e fornecendo alguma coisa para realizar fallback em caso de problemas.

De alguma forma, preservar o conteúdo do ACTLOG para uma época que engloba a reutilização da fita mais antiga. Apenas o ACTLOG lhe dará uma imagem clara do uso da fita ao longo do tempo, o que também é uma informação de valor inestimável ao tentar descobrir o que foi gravado e quando - particularmente em situações de recuperação.

Leia arquivos README!!!

Por mais óbvio que isso deve ser, e acompanhando os posts do ADSM-L, pouquíssimos clientes realmente lêem o README. É extremamente importante, pois os fabricantes sempre fornecem informações suplementares.

Os mesmos usam tais arquivos para fornecer as informações mais atualizadas sobre o software que está a ponto de usar. Informações que podem complementar e/ou instruções corretivas feitas na documentação formal além de fornecer avisos sobre a melhor forma de usar o software, baseado em descobertas recentes. Ignorar este arquivo é colocar você e os demais recursos da sua área em risco: no mínimo, você pode perder tempo; na pior das hipóteses, os danos podem ser irreversíveis.

Fique ligado!

Caso tenham alguma sugestão, reclamação, correção, ou qualquer outra coisa, por favor compartilhem. Escrevam, compartilhem ou mandem email para tsmnapratica@gmail.com.

Um grande abraço a todos.

Conselhos para novos administradores - Parte 1

Pessoal, bom dia

Recebi um documento de um colega há muito tempo. Estava perdido em um dos meus HD´s. Gostaria de compartilhar com vocês. É grande, portanto vou dividir em postagens.

Conhecer e entender os sistemas que será responsável:

Nenhum esforço é suficientemente forte, como parte de uma implementação de um sistema crítico, é absolutamenteo essencial que se torne familiar deste sistema, o que significa que você deve ler os manuais e se torne familiar com todos os elementos e saiba onde procurar informações, particularmente, informações relacionadas a problemas.

Administrar e monitorar o sistema:

É incrível, mas no mailing do ADSM-L, nós repetidas vezes encontramos clientes que estão escrevendo sobre o porque seus sistemas falharam..... porque os sistemas não receberam níveis adequados de administração, ou seja, cuidado. O elemento mais vital da administração é a monitoração, particularmente para a escassez de recursos. Você precisa para olhar constantemente a utilização do DB e LOG do TSM, a disponibilidade de fitas scratchs, a disponibilidade de drives, e similares. É imensamente frustrante ver um cliente escrever sobre a queda de um TSMServer, causada pelo estouro da área de Log.... cujo uso já estava crescendo ao longo do tempo, onde o administrador teve tempo suficiente por algumas semanas para aumentar o tamanho desta área ou alterar os schedules que estavam causando o "log pinned" para que o uso da log seja mais racional.

Lembrem-se.: O universo favorece aqueles que prestarem atenção!!!

Um bom dia a todos!

METAFRAME - RC12

Bom dia a todos,

Recentemente tivemos um problema em nosso ambiente e gostaria de compartilhar a solução aplicada.

Em um ambiente Windows Metaframe, as unidades de disco locais (C:\ D:\ E:\) não ficam visíveis no SO, porém se você digitar no Windows Explorer C:\, ele consegue acessar a unidade sem qualquer erro.

No OPT estava configurado.:

Domain C:\

Domain D:\

Domain E:\

Domain SystemObject

Mesmo assim, ao tentar executar o backup a mensagem de erro era a seguinte.: File System not ready

A solução implementada.:

Existem duas chaves de registro no Windows que define se os discos locais serão ocultados para o usuário.

Local 1

My Computer\HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Local 2

My Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

A solução foi a remoção da chave de registro NoDrives do Local 1. Assim as unidades locais ficaram acessíveis para o client do TSM e com isso o backup foi executado normalmente.

Caso tenham alguma sugestão, reclamação, correção, ou uma outra alternativa de solução para o tópico, por favor compartilhem.

Um abraço a todos.

Quando nada mais funciona.....

Olá pessoal, boa noite,

Muitos devem estar neste momento se perguntando.: "Qual a relação entre um durex e a nossa área?"

Muito bem. Esta semana tivemos um pequeno problema. Uma fita LTO3 arrebentou dentro de um dos drives do nosso robô.

E agora, o que fazer?

A primeira coisa foi checar se a política de backup contempla DRM, ou seja, cópia offsite. Infelizmente não. Se tivesse, bastaria fazer o restore volume.

A segunda coisa, foi efetuar levantamento de todas as informações que estavam na fita,  para analisar o impacto de possíveis perdas.  Não era muita coisa, mas eram e são importantes. Algo em torno de 10% Full

Duas horas depois do problema, finalmente conseguimos tirar a fita do drive.

Em um estalo, um dos colegas sugeriu usar durex para colar a fita e tentar executar o move data. Apesar da apreensão de todos, resolvemos testar e para nossa surpresa, FUNCIONOU!!!

A idéia do post de hoje é para demonstrar que apesar de ter uma política de backup, que está executando com sucesso, por um erro de hardware, teríamos um grande impacto caso tivéssemos uma solicitação de restore. E que uma decisão, atitude, que as vezes pode parecer maluquice, pode funcionar.

Pensem nisso!

Um ótimo fim de semana a todos.

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.

Registro de um novo domínio

Pessoal, boa noite,

Hoje gostaria de, ao invés de escrever muito, o que convenhamos as vezes cansa, vou postar um vídeo. Fiz agora pouco, devido a necessidade de implementação de um ambiente Exchange.

Como todos sabem, não é obrigatório, mas é recomendável que separemos os tipos de dados através de domínios. Eu costumo separar os tipos de dados da seguinte forma.: Um domínio para backups de file systems para máquinas Intel; Um domínio para backups de file systems para máquinas Unix; Um domínio para dados de Exchange; E um dominio para Oracle/SQL.

Acompanhem o vídeo abaixo.

 

Obs.: Depois que o vídeo ficou pronto é que percebi alguns erros de digitação. Peço desculpas antecipadamente...rs


Espero que tenham gostado.

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

Um abraço a todos.

Comparativo entre fitas LTO

Pessoal, boa noite,

Gostaria de pedir desculpas pela demora em responder todos os e-mails que recebi. Gosto de escrever, de trocar idéias, experências com outros profissionais, mas precisei realmente dar um tempo, devido a atividades profissionais.

Este post não é sobre TSM, mas é sobre um tipo de midia amplamente utilizado, e de conhecimento de todos aqueles que trabalham na área de Backup/Restore. É a fita LTO.

A figura abaixo, que considero muito interessante, demonstra a evolução das gerações dessa fita.

Caso possuam uma dúvida, uma sugestão, crítica ou correção, comente, mande e-mail para tsmnapratica@gmail.com.

Um abraço a todos.