Sistema de Backup utilizando IBM - Tivoli Storage Manager ... - PPGIa

Sistema de Backup utilizando IBM - Tivoli Storage Manager 

Josmar Neduziak 

Curso de Redes e Segurança de Sistemas 

Curitiba, Outubro de 2010 

Resumo 

Não importam quais são os tipos de atividades, com que as empresas trabalhão, todos 

seus sistemas dependem de computadores e seres humanos para gerenciá-los, porém estamos 

sujeitos a falhas tanto por operação voluntária quanto involuntária ou ainda a queima de 

equipamentos, entre outros fatores que possam acontecer. Sendo assim, por que não investir 

em uma ferramenta que possa disponibilizar eficazmente a restauração de dados caso 

necessário? 

1 - Introdução: 

Muitas empresas não dão o devido valor ao backup de seus dados, pois não imaginam 

o prejuízo que podem ter se todos os seus arquivos vierem a se perder, a maioria das 

organizações podem até mesmo falir se perderem suas bases. Normalmente estas, só dão a 

importância que tal assunto merece após ocorrer alguma falha grave com perdas de 

informações importantes e que causem prejuízo financeiro, neste caso, pode ser tarde demais 

para tomar uma medida preventiva. 

Apos a conscientização dos gestores das empresas de que o investimento em backup 

de dados não é dinheiro “jogado fora”, mas sim, um investimento na garantia da continuidade 

dos negócios com evolução segura e projeções de crescimento consistente após o 

investimento em um sistema de backup confiável, com certeza tais empresas poderão 

continuar a traçar metas otimistas sem medo de que a qualquer dia, tudo venha a se perder, 

devido à falta de segurança da informação, ou simplesmente por descuido, ou pior, por 

descaso. 

Com a evolução e o crescimento das redes de internet e dos meios de comunicações, 

deu-se origem a novos e complexos ambientes, tais como banco de dados e uma variedade 

cada vez maior de aplicativos primordiais para prestação de serviços. Sendo assim, há 

necessidade de investir em uma solução de gerenciamento e armazenamento de dados de 

forma confiável com atributos e políticas que possam ser ajustados para garantir os níveis de 

serviço que seus clientes exigem. 

Neste trabalho, abordarei especificamente o sistema de backup da empresa IBM, 

Tivoli Storage Manager (TSM). Uma das melhores ferramentas do mercado, devido a sua 

capacidade, confiabilidade, segurança e qualidade no gerenciamento e retenção de dados. 

Este sistema é adquirido principalmente por empresas de médio e grande porte, devido 

seu custo, pois empresas de pequeno porte optam por utilizar softwares grátis, onde, embora 

1

também possam ser eficientes, talvez não tenham a mesma segurança e confiança que o TSM 

fornece. 

Este artigo esta estruturado da seguinte forma. Na seção 2 será apresentado um pouco 

da história da ferramenta, suas versões e informações sobre o banco de dados. Na seção 3 

serão informados os requisitos de hardware e software para instalação do TSM Server e dos 

clientes. Na seção 4 serão apresentadas várias informações importantes sobre o seu 

funcionamento incluindo informações sobre o seu gerenciamento, formas de retenção dos 

dados, políticas, armazenamento e tratamento das informações, entre outros. Na seção 5 serão 

apresentadas as novidades da versão 6.x. Na seção 6 e 7 respectivamente, apresentarei as 

principais vantagens e desvantagens do TSM, seguido da conclusão na seção 8. 

2 - História da ferramenta: 

A IBM deu o “ponta pé inicial” e impulsionou-se na frente de muitas empresas do 

mercado na área de backup e recovery em 1990 com o sistema Workstation DataSave Facility 

(WDSF40 for VM), onde, nem analistas, clientes e nem mesmo os engenheiros imaginavam 

que estavam iniciando um caminho para um produto que abriria uma nova era na gestão de 

armazenamento. 

Em 1993 ela criou outra ferramenta chamada ADSTAR Distributed Storage Manager 

(ADSM) com sua versão 1.1, a qual veio a ser desenvolvida apartir da WDSF. O ADSM foi 

desenvolvido inicialmente no centro de pesquisas Almaden que localiza-se no conhecido Vale 

do Silício nos EUA, onde atualmente emprega mais de 500 pesquisadores na área de sistemas 

e tecnologia de armazenamento, banco de dados e ciência da computação[1]. 

A primeira versão do ADSM foi distribuído para o sistema Multiple Virtual Storage 

(MVS) e para servidores VM mainframe, o qual suportava o processo de backup/restore e 

archive/retrieve dos seguintes clientes: Novell Netware, AIX, Apple Macintosh, IBM OS/2 e 

Microsoft Windows [2]. 

Após a aquisição da Tivoli Systems a IBM moveu todos os esforços para este grupo 

com intuito de criar um novo produto destinado ao serviço de desaster/recovery criando assim 

o Tivoli Storage Manager (TSM) em 1999, aonde o mesmo viria a revolucionar este mercado, 

incluindo-o novas interfaces, inclusive interface de gerenciamento web. Inicialmente com a 

versão 3.7, evoluindo conforme tabela abaixo até a versão atual (6.2), sendo extremamente 

confiável e vendida no mundo todo. 

Release Versão Data de Lançamento 

Workstation DataSave Facility (WDSF40 for VM) - Setembro 1990 

ADSTAR Distributed Storage Manager 1.1 Julio 1993 

ADSTAR Distributed Storage Manager 1.2 1994 


ADSTAR Distributed Storage Manager 1.2.1 1995 




IBM Tivoli Storage Manager 3.7 1999 


IBM Tivoli Storage Manager 4.2.0 2001 


2





IBM Tivoli Storage Manager 5.4 Janeiro de 2007 

IBM Tivoli Storage Manager 5.5 Novembro de 2007 

IBM Tivoli Storage Manager 6.1 Março de 2009 

IBM Tivoli Storage Manager 6.2 Março de 2010 

Tabela 1 - Versões 

O TSM é considerado uma solução bastante flexível embora exija um bom 

conhecimento técnico para gerenciá-lo, sendo que, após conhecer suas funcionalidades e 

políticas o mesmo se torna simples e fácil sua manutenção e gerenciamento. Ele é 

considerado pioneiro na utilização de banco de dados integrado, utiliza-se um gerenciamento 

centralizando, e apartir da versão 6.1 é utilizado um banco de dados DB2 independente, não 

sendo necessário ter um conhecimento avançado em banco de dados para gerenciá-lo, 

facilitando assim o seu suporte. Devido a tais funcionalidades é muito utilizado por grandes 

corporações como indústrias, governos, organizações militares, organizações de educação e 

de serviços em geral, onde tais necessitam de uma ferramenta eficiente, para seu 

armazenamento seguro e confiável. 

Figura 1: Banco de Dados DB2 relacional [11] 

A arquitetura e banco de dados centralizada oferece muitas vantagens, quando 

comparadas a outras tradicionais arquiteturas orientadas a produtos de armazenamento. Por 

exemplo, o recurso de backup incremental que faz com que arquivos novos e alterados sejam 

backupeados, e não apenas feitas copias full (completa). Esta técnica avançada reduz a 

quantidade de dados que está sendo gerenciada, tempo e a largura de banda que levaria para 

transferir, diminuindo consideravelmente a quantidade de disco e fitas para o armazenamento. 

Porém há a necessidade de criar uma política de backup confiável para o próprio 

banco de dados do sistema, sendo que, sem o mesmo não é possível efetuar leitura, nem a 

restauração dos dados armazenados. Para garantir a segurança as fitas gravadas em um TSM 

especifico não pode ser lidas por nenhum outro. 

3

O TSM oferece ainda a continuidade sendo possível efetuar a migração de uma versão 

para a outra progressivamente sem nenhum problema, utilizando as fitas de armazenamento 

antigas, sendo este um fator importante para a decisão das empresas de qual sistema de 

armazenamento irão utilizar, pois tal deve garantir que a próxima geração será compatível 

com a anterior. 

Figura 3: Progressão das fitas magnéticas [6] 

3 - Requisitos de software e hardware: 

As tabelas abaixo mostrarão informações mínimas para a implantação do TSM em sua 

mais nova versão 6.2 em servidores e clientes Linux e Windows, obtido nos manuais 

referenciados. Além destes ainda é possível implantar-lo em máquinas com Sistema 

Operacional AIX, HP-UX e Solaris. 

3.1 - Mínimo necessário de hardware em servidores Linux: 

Tipo de 

Hardware 

Requisitos de Hardware 

Hardware Computador com base em processador ou multiprocessadores compatíveis 

com Intel Pentium 

Espaço em disco Os valores mínimos a seguir para o espaço em disco: 

� 5 MB para o diretório /var 

� 10 MB para o diretório /opt se você criar pontos de montagem 

� 4 GB para o diretório /opt/tivoli/tsm se você criar pontos de montagem 

� 390 MB para o diretório /tmp 

� 300 MB para o diretório /usr 

� 2 GB no diretório inicial 

Memória � 12 GB. 

� 16 GB se você estiver usando deduplicação. 

� Se você planeja executar múltiplas instâncias, cada instância exige a memória listada em um 

servidor. Multiplique a memória para um servidor pelo número de instâncias planejadas 

para o sistema. [4] 

3.2 - Mínimo necessário de Softwares em servidores Linux: 

Tipo de software Requisitos mínimos de software 

Sistema 

Operacional 

Protocolo de 

comunicação 

O servidor Tivoli Storage Manager no Linux requer um dos seguintes sistemas operacionais: 

� Red Hat Enterprise Linux 5, Update 3 ou posterior 

� SUSE Linux Enterprise Server 10, Service Pack 2 ou posterior 

� SUSE Linux Enterprise Server 11 

� TCP/IP Versão 4 ou Versão 6 

� Protocolo de memória compartilhada (com cliente do Tivoli Storage Manager Versão 6.1 

System p) 

Navegador da Web Os navegadores a seguir são suportados: 

� Microsoft Internet Explorer 6.0 SP1 

� Microsoft Internet Explorer 7.0 

� Firefox 2.0 ou superior [4] 

4

3.3 - Mínimo necessário de hardware em servidores Windows: 

Tipo de Hardware Requisitos de Hardware 

Hardware Computador com base em processador ou multiprocessadores compatíveis 

com Intel Pentium 

Espaço em disco � Pelo menos 3 GB de armazenamento livre em disco (para uma instalação típica) 

� 200 MB de espaço em diretório temporário 

� Tamanho de partição de 2 GB na unidade C:\ 

� 300 MB no diretório de instância 

Memória Sistemas Windows de 64 bits (recomendado) 

� 12 GB. 

� 16 GB se você estiver usando deduplicação. 

Sistemas Windows de 32 bits 

� 8 GB. 

� A deduplicação não é suportada. 

� Executar mais de uma instância do servidor em um sistema não é suportado. [4] 

3.4 - Mínimo necessário de software em servidores Windows: 

Tipo de software Requisitos mínimos de software 

Sistema 

Operacional 

Protocolo de 

comunicação 

Navegador da 

Web 

� Microsoft Windows Server 2003: Standard, Enterprise ou Datacenter Edition, Service 

Pack 2 ou posterior 

� Microsoft Windows Server 2003: Standard, Enterprise ou Datacenter x64 Edition (64 

bits), Service Pack 2 ou posterior 

� Microsoft Windows Storage Server 2003 

� Microsoft Windows Storage Server 2003 x64 

� Microsoft Windows Server 2008: Standard, Enterprise ou Datacenter Edition 

� Microsoft Windows Server 2008: Standard, Enterprise ou Datacenter x64 Edition (64 bits) 

� Microsoft Windows Server 2008 R2: Standard, Enterprise ou Datacenter Edition 

Pelo menos um dos seguintes protocolos de comunicação: 

� Canais Nomeados 

� TCP/IP Versão 4 ou Versão 6 

� Microsoft Internet Explorer 6.0 SP1 

� Microsoft Internet Explorer 7.0 

� Firefox 2.0 ou superior 

Tabelas 2 - Requisitos [4] 

3.5 – Requisitos de software e hardware para instalação de Clientes: 

Windows: 

Um dos seguintes Sistemas Operacionais: 

� Windows XP Professional 

� Windows Server 2003 

� Windows Vista 

� Windows 2008 Server 

� Windows 7 

� Processador PC baseado em x86 (Pentium® ou mais recente) ou AMD64/EM64T 

� Seguem os requisitos mínimos de espaço em disco: 

� 8 MB para a API* (Interface de Programação de Aplicações) de 32 bits 

� 17 MB para a API de 64 bits (isto inclui a API de 32 bits) 

� 29 MB para o cliente de Backup/Archive 

� 143 MB para o cliente HSM 

Memória: 512 MB [4] 

Linux: 

5

Um dos seguintes Sistemas Operacionais: 

� CentOS 4 e 5 

� Debian* 4 e 5 

� Fedora 11 e 12 

� Oracle Enterprise Linux 4 e 5 

� Scientific Linux 4 e 5 

� SUSE Linux Enterprise Desktop 10 e 11 

� RedHat Desktop 5 

� Mandriva Linux 2010 

� Ubuntu* 8, 9 e 10 

� Processador PC baseado em x86 (Pentium® ou mais recente) ou AMD64/EM64T 

� Seguem os requisitos mínimos de espaço em disco: 

� 8 MB para a API de 32 bits 

� 17 MB para a API de 64 bits (isto inclui a API de 32 bits) 

� 29 MB para o cliente de Backup/Archive 

� 143 MB para o cliente HSM 

Memória: 512 MB[4] 

4 - Funcionamento da ferramenta: 

Uma Infra-estrutura do TSM normalmente segue o seguinte padrão de equipamento: 

- 1 Tape Library 

- 1 Servidor TSM (Administrator Center, ISC, DB2, Storage Pool, Logs) 

- Clientes 

- Rede WAN, SAN e LAN ou somente LAN 

Segue abaixo um modelo de uma infra-estrutura padrão com o TSM: 

6

Figura 4 – Rede padrão utilizada pelo TSM 

4.1 - Gerenciamento do TSM: 

Dependendo do ambiente as regras de negócio podem ou não estarem bem definidas. 

Em uma organização, um só analista pode executar todas as operações ao mesmo tempo, mas 

também pode ser que exista um time de analistas compartilhando as responsabilidades de 

todas as tarefas do TSM. 

Cada analista poderá ter uma função junto ao gerenciamento do TSM, por isso, a 

necessidade de disponibilizar as permissões corretas para cada um, visando manter a 

segurança e possibilitando a utilização de uma política de acesso, criando usuários com 

privilégios específicos, tais como: System, Policy, Storage, Operator, Analyst. 

� System: Usuário Administrador com maior nível de privilégios 

- Registrar e remover administradores 

- Adicionar e remover privilégios 

- Renomear administradores e trocar suas senhas 

- Definir e excluir Políticas e Storage Pools 

- Cancelar Processos 

- Alterar parâmetros do TSM Server 

� Policy: Esse privilégio pode ou não estar restrito a um Policy Domain. 

- Registrar, Modificar e Excluir Client Nodes 

- Registrar, Modificar, Excluir e Associar Schedules 

- Excluir arquivos armazenados pelos Client Nodes 

- Registrar, Modificar e Excluir objetos das políticas 

� Operator: 

- Habilitar e Desabilitar o TSM Server para sessões de Client Nodes 

- Cancelar sessões 

7

- Gerenciar montagem de fitas, e status das mídias 

- Parar o TSM Server 

� Storage: Esse privilégio pode, ou não estar restrito a um Storage Pool com restrições 

de Storage Pool 

- Definir e Excluir volumes de Storage Pools 

- Move data e audit volume 

- Sem restrições de Storage Pool, todos os privilégios acima 

- Definir, Alterar e Excluir volumes de DB e LOG 

- Definir, Alterar e Excluir espelhamentos de DB e LOG 

- Definir, Alterar e Excluir Device Classes 

� Analyst: Somente possui privilégios para zerar contadores de performance do TSM 

� Node: Somente possui privilégios para acesso do client WEB de determinados Nodes 

(clientes) com algumas opções de backup e restore [10] 

Tal gerenciamento pode ser efetuado pelo prompt (linha de comando), ou ainda, pela 

pagina Administration Center, que integra-se com o Integrated Solution Console (ISC), ao 

qual permite fazer a gerencia de vários servidores TSM, inclusive sendo possível instalá-lo 

em outro servidor. 

Figura 5 – Gerencia com ISC 

4.2 – Principais comandos 

O TSM Server, quase em sua totalidade pode ser configurado e gerenciado via linha 

de comando, estes comandos podem ser inseridos no Administratrive Command Line para 

verificar e configurar parâmetros no servidor, e nos clientes para verificar status e 

configurações. 

Lista com algumas dos principais comandos que um administrador usa no dia-a-dia: 

q vol - mostra situação de preenchimento das fitas na library; 

q libv - mostra as fitas que estão montadas na library; 

q mount - mostra se há alguma fita montada no drive da library; 

q proc - mostra se há algum processo em execução no momento; 

q act - mostra log do tsm; 

q ev * * - mostra todos os eventos que o tsm executou no dia; 

8

q ev * * -begind=-n begint=17:00 - mostra todos os eventos executados no dia, se for –1 

será mostrado dados do dia anterior, se for –2 será de 2 dias atrás e assim por diante, 

apartir das 17:00 horas; 

q req - mostra se há algum processo requisitando intervenção do operador. 

se houver, aparecerá um número e após executar a ação necessária, deve-se digitar: reply 

 

help query - mostra todos os tipos de query e sua sintaxe; 

query event - informações sobre eventos schedulados e completos; 

query log - informações sobre alocação de logs; 

query db - estatísticas do banco de dados; 

query dbvolumes - apresenta volumes que compõe o banco de dados do TSM; 

query system - informações consolidadas sobre o TSM; 

query stgpool - informações sobre o storage pool; 

query occupancy - recursos usados para informações dos clients; 

query status - informações gerais dos parâmetros do servidor; 

query session - informação sobre as sessões abertas no TSM; 

query process - processos de clients que estejam rodando em background; 

query activity log - mostra o log do TSM; 

query libvolume - mostra volumes montados na library; 

update admin - alterar password de usuários; 

show time - mostra horário do TSM Server; 

query mgmt - mostra management classes; 

query cota - mostra tempo de retenção das management classes; 

query schedule - mostra informações sobre as schedules criadas; 

q lic - ver a situação das licenças; 

4.3 - Formas de retenção dos dados: 

Backup: Os dados são controlados individualmente armazenados e retidos segundo certo 

número de versões, especificadas nas políticas (Backup Copy Groups). 

O backup dispõe de quatro tipos, dependendo da necessidade assim podem ser criadas suas 

políticas: 

� Backup Full: Efetua o backup total de todos os diretórios e arquivos. 

� Backup Incremental: Faz o backup de todos os diretórios e arquivos alterados desde o 

ultimo backup incremental. Se necessário restaurar algo, será preciso utilizar a fita 

com o ultimo backup full e em seguida todas as fitas utilizadas com o conjunto 

incrementais subseqüentes para restauração de arquivos alterados durante a semana, 

por exemplo. 

� Backup Diferencial: Faz o backup de todos os diretórios e arquivos desde o ultimo 

backup full. Para restaurar os dados neste é necessário restaurar os dados da fita full 

mais a ultima fita diferencial. 

� Snapshot ou Image Backup: O TSM é capaz de fazer uma cópia fiel do sistema, esta 

opção é a menos utilizada, pois muitas vezes o restore do snapshot pode demorar mais 

do que reinstalar o sistema operacional dependendo da disposição dos arquivos nas 

fitas. 

Restore: É a restauração flexível dos dados para o local de origem ou outro local, até mesmo 

para outro servidor (utilizando a opção Virtual Node), conforme definição do administrador, 

garantindo assim o menor impacto possível. 

9

Archive: Os dados são armazenados e retidos por um certo período, determinados nas 

políticas (Archive Copy Groups). Este procedimento é mais utilizado para cópia de arquivos 

grandes com poucas alterações e com necessidade de longo período de retenção. 

Retrieve: É a restauração dos dados que foram anteriormente arquivados com o processo de 

archive. 

Figura 7 – Exemplo de um procedimento de backup/restore e utilização das fitas 

4.4 - Arquitetura Políticas: 

A seguir, algumas informações sobre a forma que o TSM trata e gerenciam as políticas 

de retenção, esta definição é feita através de quatro níveis os quais podem ser criados através 

do Administrator Center (pagina web) ou via linha de comando: 

� Policy Domain 

� Policy Set 

� Management Class 

� Copy Groups 

Figura 6 – Políticas [8] 

Policy Domain: Consiste em aplicar as regras para o gerenciamento e agrupamento clients 

nodes (Servidores clientes), normalmente agrupa-se pelas características semelhantes, como 

tipo de plataforma, domínio, tipo de dados a ser copiados. 

Policy Set: É a parte da politica que contém as definições ativas. 

10

Management Class: O Management Class contém as regras usadas para gerenciar os dados 

por clientes e domínio. 

Copy Groups: Neste nível existem dois tipos, o Backup Copy Group e o Archive Copy 

Group, é onde define-se o período de retenção e o destino dos dados. Estes dispõem de alguns 

parâmetros interessantes como: 

Backup copy group: 

� destination: Define o stgpool (espaço em disco) onde os dados serão armazenados; 

� frequency: Copia o arquivo independente de quando ele foi alterado; 

� verexists: Numero de versões retidas; 

� verdeleted: Numero de versões retidas após o arquivo ser deletado; 

� retextra: Período que o arquivo ficará disponível após ele se tornar inativo; 

� retonly: Retenção após o arquivo ser deletado no cliente; 

� mode: Determina que o TSM faça a cópia do arquivo sempre que ele for modificado, 

ou sempre que for executado a Schedule (agendamento); 

� serialization: Define o que pode ser feito se o arquivo estiver sendo editado no 

momento do backup; 

Archive copy group: 

� destination: Define o stgpool onde os dados serão armazenados; 

� retver: Período de retenção do archive; 

� serealization: Define o que pode ser feito se o arquivo estiver sendo editado no 

momento do backup; 

Para efetuar toda a configuração das políticas é necessário seguir a seguinte ordem: 

1 - Definir a Policy Domain; 

2 - Definir a nova Policy Set; 

3 - Definir a nova Management Class; 

4 - Definir um novo Backup Copy Group ou Archive Copy Group; 

5 - Atribuir uma default Management Class; 

6 - Validar a Policy Set; 

7 - Ativar a Policy Set; 

8 - Efetuar o gerenciamento com o Administration Center; 

4.5 - Armazenamento temporário em disco: 

Após definir as políticas é necessário criar os espaços em disco que manterão os 

arquivos copiados dos clientes temporariamente. É interessante a criação deste espaço 

relativamente grande para a acomodação dos backups e archives, levando em conta que, os 

discos são randômicos, agilizam o processo inicial sendo possível executar copias simultâneas 

para o disco e posteriormente migrados para as fitas. 

Diskpool: Local em disco disponível para armazenamento temporário dos dados antes do 

mesmo ser movido automaticamente (migration) ou ser forçado à migração para as fitas. Tal 

espaço em disco é de primordial importância, pois, sendo possível efetuar leitura e gravação 

simultânea, torna-se viável efetuar backup/archive de diversos clientes ao mesmo tempo 

diminuindo o período de janelas. 

Obs.: Se o arquivo a ser efetuado o backup ou archive for maior que o diskpool disponível, o 

mesmo irá ser encaminhado direto para as fitas na Tape Library (Unidade de gravação de fitas 

magnéticas). 

Backuppool: É um espaço do diskpool onde ficarão armazenados os backups antes de ser 

envidos para a Tape Library. 

Archivepool: É um espaço do diskpool onde ficarão armazenados os archives antes de ser 

enviados para a Tape Library. 

11

4.6 - Tratamento dos dados: 

Existem algumas particularidades que o TSM utiliza para tratar os dados, buscando 

desta forma, facilitar o gerenciamento e melhorar a utilização das fitas: 

Expiration: Conforme as políticas criadas para armazenamento dos arquivos e/ou dados, tais 

vão expirando e vão sendo eliminados automaticamente do banco de dados, desta forma os 

dados gravados nas fitas não terão mais validade, ou seja, o TSM não reconhece mais. 

Migration: É um processo utilizado pelo TSM para migrar os dados do diskpool (dados que 

estão no disco do servidor) para as fitas. Isso pode ser feito automaticamente, basta efetuar a 

configuração no TSM Server, sendo o padrão ele migrar os dados quando atinge a 90% do 

backuppool (quando forem backups) ou archivepool (quando forem archives) migrando até o 

percentual de 70%, porém o mais interessante é migrar completamente os dados quando este 

atingir 90%, liberando assim o disco para eventuais backups/archives que necessitem de uma 

maior quantidade de disco. 

Figura 8 – Forma de tratamento dos dados utilizado pelo TSM [6] 

Reclamation: É a movimentação ou transferência dos dados de uma ou mais fitas 

subutilizadas para outra, desta forma, há a liberação destas, se tornando scratchs (sem dados e 

pronta para a reutilização). 

12

Figura 9 – Processo de reclamation de fitas [6] 

Versionamento: O TSM permite que se retenham arquivos por múltiplas versões (backup), e 

não somente por tempo (archive), ou seja, uma vez que o arquivo for modificado, pode-se 

configurar o produto para manter versões anteriores deste mesmo arquivo, de forma que 

proteja o ambiente caso alguma inconsistência tenha ocorrido ao arquivo e o mesmo tenha 

sido backupeado em uma versão falha, possibilitando assim a restauração de versões 

anteriores do mesmo, por exemplo. 

O produto também permite que cada dado tenha sua retenção tratada sob os seguintes 

aspectos: 

1. Enquanto o arquivo existir, quantas versões do mesmo deverão ser mantidas em 

backup? 

2. Enquanto o arquivo existir, por quanto tempo deve-se manter cada versão adicional? 

3. Quando o arquivo for deletado, quantas versões em backup devem permanecer? 

4. Quando o arquivo for deletado, e existir apenas uma última versão do mesmo, por 

quanto tempo a mais deseja-se manter essa última versão em backup? 

Na figura abaixo, segue um exemplo de um arquivo que foi alterado e efetuado o 

backup diariamente, sendo configurado sua política de versionamento para reter as cinco 

ultimas cópias. 

13

Figura 10 – Política de versionamento 

Schedules: São agendamentos realizados no TSM para efetuar os backups/archive 

restore/retrive automaticamente, sem necessitar da intervenção do administrador em tempo 

real. Existem dois tipos de schedules, são eles: Client Schedules e o Administrative Schedules. 

Com o Client Schedule, podemos: 

� Agendar Backups Incrementais, Diferenciais e Full; 

� Agendar Archives; 

� Agendar Retrieves e Restores; 

� Agendar Comandos do Sistema Operacional e Scripts; 

Com o Administrative Schedule, podemos: 

� Agendar Comandos Administrativos como: reclamation, expiration, migration, etc; 

Para efetuar os agendamentos é necessário seguir alguns passos, para seu real funcionamento: 

1. Especificar o Scheduling Mode a ser utilizado; 

2. Definir os Scheduling Parameters; 

3. Definir os schedules para cada Policy Domain; 

4. Associar cada schedule com um ou mais client nodes; 

5. Especificar um Retention Time para os Events Records no database; 

Scheduling Mode: É a técnica de comunicação client/server (Client Polling ou Server 

Prompted). 

Events Records: São registros do banco de dados que descreve o status atual e o resultado dos 

eventos. 

14

Figura 11 – Agendamentos 

4.7 - Maintenance Script: 

Para facilitar a administração de todo o ambiente, o TSM conta com uma configuração 

de script que faz automaticamente todo o processo necessário para manter o seu bom 

funcionamento, normalmente este procedimento é agendado diariamente pela manhã. 

Abaixo algumas ações e funcionalidades que devem ser tomadas no Maintenance 

Script: 

1. Criar o script para backup do DB diário (ex.: seis incrementais backups, seguindo por 

um backup full). 

2. Adicionar o Device Class para efetuar o backup do banco de dados (DB) diariamente. 

3. Migração dos storage pools (backuppool, archivepool) para efetuar a movimentação 

dos dados para a fita. 

4. Executar o Expiration, para limpar os dados expirados dos backups\archives efetuados. 

5. Rodar o Reclamation, todas as fitas com menos de 50% (enviar os dados para outras 

fitas e torná-las scratch) 

6. Backup Storage Pools, faz o backup todo o storagepool (dados que estão gravados nas 

fitas) para a storagepool clone (fitas clones que serão retiradas da Tape Libary 

diariamente e enviadas para o cofre externo). Desta forma mantendo se a segurança 

principalmente dos dados críticos contra eventuais desastres de qualquer natureza. 

4.9 - Virtual Node: 

A função Virtual Node é uma opção utilizada pelos administradores, para restauração 

de arquivos originários de um servidor em outro servidor com o mesmo tipo de Sistema 

Operacional. Isso é bastante utilizado quando se quer restaurar os dados de uma máquina que 

houve a perda para outra que irá manter tal serviço de forma permanente ou temporariamente. 

Obs.: A restauração de arquivos no Linux se dá apenas via linha de comando, não é possível 

fazer a restauração de um arquivo de outro servidor via ambiente gráfico neste Sistema 

Operacional. 

15

Figura 12 – Restauração dos dados em servidor diferente 

4.9 - Gerenciamento Online: 

Uma solução muito interessante do TSM utilizado em diversas aplicações padrões do 

mercado é o Tivoli Data Protection (TDP), ao qual facilita o backup destas, não sendo 

necessário parar o sistema para efetuar as cópias de segurança, além de poder ser feitas em 

tempo real e reduzir significativamente as necessidades administrativas, possuem interfaces 

customizadas que permitem acesso aos dados backupeados em cada tipo de, de forma 

uniforme e simplificada. 

Entre os sistemas gerenciados por esta solução estão: 

Banco de IBM DB2, Oracle Enterprise Edition, Oracle Real Aplication Clusters (RAC), 

Dados: IBM Informix (built-in), Microsoft SQL Server. 

Correio IBM Lotus Domino, Microsoft Exchange Server, Microsoft Exchange Server 

Eletrônico: VSS, Microsoft Exchange Server Ind. Mailbox Recover. 

Servidor de WebSphere Application Server, Microsoft Sharepoint Portal. 

aplicação: 

Hardware: IBM Enterprise Storage Server, Shark, EMC Symmetrix. 

ERP: SAP R/3SAP Enterprise (Oracle), SAP Enterprise (DB2), SAP Oracle/DB2 

Flashcopy 

Tabela 3 – Soluções suportadas pelo TDP [5] 

4.9.1 - Vantagens na utilização dos Agentes TDP: 

� Proteção em tempo real dos dados fazendo backup automaticamente de sistemas 

críticos; 

� Reter os arquivos por tempo pré-definidos, com cópias de versões separadas para 

facilitar a restauração, além de expiração automática dos dados; 

� Fácil implementação e gerenciamento, sendo executado em segundo plano e de forma 

transparente e sem que ocorram sobrecargas no sistema; 

� Trabalha com múltiplas tecnologias de backup/replicação (local disk, file server, web, 

Tivoli Storage Manager, NAS device); 

� É possível apagar versões de arquivos antigos para liberar espaço para novas versões, 

além de efetuar o autogerenciamento da área de destino; 

� Otimiza e reduz a utilização da banda de rede e elimina a necessidade de janela para 

efetuar as cópias de segurança; 

� Utilização de sessões paralelas de backup e restore; 

16

� Utilização de área em disco do TSM (diskpool) para backup e archive de logs dos 

bancos de dados; 

� De acordo como a aplicação, opções de restore para servidores diferentes, ou em áreas 

diferentes; 

� Todos os agentes desenvolvidos na solução de TSM são certificados pelos fabricantes 

onde atuam; 

4.10 - Modelos de Tape Librarys e status das fitas: 

A Tape Library é um equipamento bastante complexo, que faz a gravação dos dados 

oriundos dos clientes nas fitas magnéticas, onde apenas uma Tape Library pode atender a 

diversos servidores TSM. 

Existem diversos modelos de library, desde as mais simples com apenas uma unidade 

de gravação (Tape Library TS3100) até as mais avançadas com 192 drives (Tape Library 

TS3500) sendo compatíveis com as fitas IBM LTO Ultrium 1, 2, 3, 4 e 5. Esta ultima com 

capacidade de armazenamento de 1,5 TB nativos e 3 TB compactados e transferência de até 

140 MBps. 

As fitas utilizadas nas Tape Librarys tem alguns status, dependendo do estado é 

possível ou não efetuar gravação. 

Scrath: É uma fita que não contem mais dados válidos, portanto ela esta pronta para ser 

reutilizada. 

Private: Uma fita quando contém dados válidos é considerada private, porém nada impede se 

estiver sendo subutilizada, ser efetuado a migração destes dados para outra fita (move data), 

liberando a mesma, tornando-se scrath. 

Tais fitas podem ainda estar disponíveis ou não para gravação, estando elas em status 

Scrath ou Private: 

Read Only: É possível alterar o status de uma fita para ser efetuada somente leitura da 

mesma, este procedimento é feito normalmente quando não se quer salvar nada nesta fita. 

Read White: Este status deixa a fita disponível para gravação, é o status padrão das fitas que 

estão scraths. 

17

Figura 13 – Processo das fitas magnéticas [9] 

4.11 - Incluindo ou excluindo arquivos: 

O TSM conta com uma opção de include/exclude de arquivos e/ou diretórios, desta 

forma, é possível evitar salvar arquivos de pouco ou nenhuma utilidade para a organização, 

como por exemplo, arquivos .avi, .mp3, .wmv, .dll, entre outros. 

Tal exclusão de arquivos e/ou diretórios pode ser configurado no próprio TSM Server, 

ou ainda nos clientes, através do arquivo de configuração dsm.otp que pode ser encontrado no 

seguinte local: “C:\Program Files\Tivoli\TSM\baclient\dsm.opt” para Windows e no 

“/opt/tivoli/tsm/client/ba/bin/dsm.opt” para clientes Linux, que, além da lista de exclusão ou 

inclusão, é onde fica toda a configuração necessária para a comunicação entre cliente e 

servidor. 

Abaixo segue uma tabela de alguns caracteres que são utilizados nos arquivos de 

configuração do TSM Server e clientes: 

Caracter Informação 

? Usado para combinar um caracter 

* Usado para combinar um ou mais caracters 

\… Usado para combinar com qualquer diretório Windows 

…/ Usado para combinar com qualquer diretório Linux 

“ ” Usado para combinar um nome que contenha caracters em branco 

[ ] Usado para combinar qualquer caracter dos especificados 

[-] Usado para combinar qualquer caracter neste intervalo 

Tabela 4 – Caracteres reconhecidos pelo TSM 

Segue alguns exemplos de um arquivo de exclusão (exclude lists) que podem ser 

usados nos sistemas operacionais como: Macintosh, Novell Netware,Unix/Linux, Windows: 

18

Este exemplo mostra uma lista de exclusão para os sistemas operacionais Windows e 

Linux: 

Exemplo: 

Windows: 

exclude ?:\...\*.shs 

exclude ?:\...\*.tmp 

exclude ?:\...\386spart.par 

exclude.dir ?:\...\system32\config 

exclude.dir ?:\...\system32\dhcp 

exclude.dir ?:\...\system32\lserver 

exclude ?:\...\system32\perflib*.dat 

exclude.dir ?:\...\system32\wins 

exclude.dir ?:\...\temp 

exclude *:\...\*.ghs 

exclude *:\...\*.iso 

exclude *:\...\*.pqi 

exclude ?:\...\*.exe 

exclude ?:\...\*.dll 

exclude ?:\...\*.jar 

exclude ?:\...\*.com 

Linux: 

exclude.dir /.../temp 

exclude.dir /.../tmp 

exclude /.../tmp/.../* 

exclude /.../*.iso 

exclude /.../*.pqi 

exclude.dir /.../trash 

exclude.dir /.../Trash 

Também é possível, ao invés de excluir arquivos ou diretórios, efetuar a inclusão, 

apenas alterando a palavra exclude por include dentro do arquivo de configuração dsm.opt: 

Exemplo: 

include ?:\...\*.exe 

include ?:\...\*.dl 

include.dir ?:\...\system32\dhcp 

4.12 - Clonagem de fitas: 

O TSM tem uma função que permite clonar o que foi gravado em fita. Isto é 

interessante quando queremos mandar fitas para cofre ou fora da empresa, um procedimento 

importante a ser realizado, devido ao risco de ocorrer algum desastre no datacenter, como 

inundação, incêndio. Com a clonagem das mesmas, é possível garantir que os dados serão 

recuperados posteriormente a um grave incidente. 

Basicamente, quando se faz a clonagem do pool de fitas, o TSM gera uma cópia de 

todos os dados válidos que foram gravados na cópia primaria e efetua uma cópia idêntica em 

um novo volume de fitas. A retenção dos dados permanece a mesma, ou seja, se expirou os 

dados na cópia primária também expira no clone. 

A parte mais importante da clonagem é justamente a definição adequada do prazo de 

retenção. Se o prazo de retenção for insuficiente, pode ocorrer dos dados não estarem 

19

disponíveis quando necessário. Se o prazo de retenção for longo demais, gasta-se mais fitas. 

por isso há a necessidade de um planejamento eficiente das políticas de retenção. 

Abaixo, segue um procedimento para a criação de um Storage Pool Clone via linha de 

comando: 

1. Criar um storagepool do tipo copypool: 

define stgpool clone lto_class_1 pooltype=copy maxscratch=9999999 define stgpool 

stg_clone lto_class pooltype=copy description='stg para clonar fitas-cofre' 

maxscratch=99999999 

2. Criar schedule administrativo para fazer o clone após todos os backups do dia, este 

schedule executará o comando: 

backup stgpool lto_ts3581 clone preview=no wait=no maxprocess=1 

backup stgpool ts_3200 stg_clone wait=no 

Obs.: É necessário adicionar os volumes (fitas scraths) ao Clone Pool, por que a mesma não 

utiliza o pool de fitas dos backups e archives normais (primarios). Também é necessário 

verificar se as fitas estão com status de Read/Write, podendo assim, ser utilizada sem 

problemas. 

4.13 - Capacidade de gerar cópias simultâneas de backup: 

O TSM permite que seja gerado simultaneamente o backup de um ou mais servidores 

para mais de um volume (mesmo que, em mídias diferentes). Dessa forma, agiliza-se em 

muito os processos de envio de volumes para cofres, pois se tem as cópias sendo feitas 

simultaneamente para fitas locais e para as que irão ser enviadas para local externo, sem que 

haja necessidade de um processo posterior de clonagem dos dados. 

Figura 14 – Copias simultâneas [6] 

5 - Novidades da versão 6: 

5.1 - Deduplication 

Uma das novidades que a versão 6 traz, é a possibilidade de eliminar a duplicação de 

dados, ou seja, esta nova técnica é capaz de gerenciar a redundância dos dados salvando 

apenas uma cópia. Onde há arquivos idênticos, substituindo estes por indicadores e apontando 

para um arquivo único de forma transparente para o usuário. Um bom exemplo disso é 

quando muitos usuários recebem e-mails idênticos, que ao invés de ser salvo todas as cópias 

de todos os usuários, é salvo apenas uma e as demais apontadas para esta. Desta forma 

elimina-se o crescimento explosivo dos dados (principalmente quando combinado com o 

20

método progressivo), economizando na utilização de discos, fitas e conseqüentemente 

possibilita efetuar backups e restores mais rápidos. 

Figura 15 – Processo do deduplication [7] 

5.2 - Integração com Vmware: 

Atualmente muitas organizações estão migrando seus servidores para máquinas 

virtuais, buscando melhor desempenho, redução de custos, e a máxima utilização da máquina. 

Desta forma, também há a necessidade de garantir a segurança dos dados destas. 

Apartir da versão 6.1 é possível efetuar o backup Full-Image onde se faz uma cópia 

total da máquina virtual independente do Sistema Operacional utilizado e também File-Level 

que faz cópias a nível de arquivos da máquina virtual, sendo possível aplicar formas de 

retenção especificas (incremental, diferencial) utilizando a tecnologia VMware Consolidated 

Backup (VCB), que consiste em utilizar um proxy Server poupando o processamento dos 

hosts. 

O Vmware e o TSM podem ser integrado de 3 formas: 

� Por máquina virtual 

� Por ESX Server 

� Utilizando VCB 

Figura 16 – TSM + VMware [7] 

6 - Vantagens na utilização do TSM: 

21

� Centralização na realização do backup\archive e gerenciamento; 

� Opção de criar sites distintos duplicando os dados em tempo real; 

� Ambiente gráfico e terminais para gerenciamento do TSM (Administrative Command 

Line, Management Console, Integrated Solutions Console e Administration Center); 

� Possibilidade de criar políticas de privilégios para controle e acesso; 

� Diversos tipos de backup: full, incremental, diferencial, Snapshot; 

� Possibilidade de restore do próprio sistema de backup (TSM) caso haja algum 

problema com o servidor original; 

� Monitoramento fácil e com lista de erros elaborada; 

� Possibilidade de exclusão ou inclusão de arquivos com extensões especificas e 

diretórios; 

� Versionamento de backups; 

� Deduplicação dos dados; 

� Capacidade de inclusão de proteção opcional de dados para aplicativos como Banco de 

dados, ERP, e-mail; 

� Possibilidade de criptografar e compactar os dados, garantindo assim, mais segurança 

e o máximo de utilização das fitas; 

7 - Desvantagens na utilização do TSM: 

� Complexidade para instalação e configuração e gerenciamento do mesmo até o seu 

real entendimento; 

� Preço elevado das licenças; 

� Apartir da versão 6.1 o DB2 requer mais espaço de disco e memória; 

� Não é possível efetuar upgrade das versões do TSM em servidores Windows e AIX 

com 32 bits para servidores 64 bits; 

� Dependendo da necessidade de backup/archive restore/retrieve de grandes quantidades 

de dados haverá uma sobrecarga na rede, por isso onde necessita-se de grande 

transferência de dados, uma boa solução é a implantação de uma rede SAN; 

8 - Conclusão 

Todos os fatores e conceitos apresentados até agora são diferenciais importantes da 

solução do TSM quando trabalhadas com todos estes conceitos em conjunto. 

Neste trabalho procurei demonstrar a solidez e eficiência da tecnologia utilizada pelo 

produto, podendo oferecer segurança e disponibilidade superiores quando comparadas a 

outras soluções corporativas de backup: 

22

Figura 16 – Eficiencia do TSM 

O futuro dos sistemas de armazenamento deve incluir o TSM como um dos melhores e 

mais seguros sistemas de retenção, principalmente quando existe a necessidade de guardar 

grandes quantidades de dados. 

De modo geral, as empresas devem tomar o máximo de cuidado com suas 

informações, utilizando-se qualquer que seja a ferramenta já trará certo alivio caso ocorra 

alguma eventualidade ocasionando perdas. Porém, dependendo da empresa o gerenciamento 

das informações com ferramentas básicas podem trazer maior custos que benefícios, e ainda 

correr o risco de não haver a possibilidade do restore das informações no momento 

necessário, sendo que, o importante não é o backup mais sim a restauração dos mesmos. 

9 - Referencias: 

[1] http://mundodasmarcas.blogspot.com/2006/05/ibm-negcios-online.html 

[2] http://www.ccs.uottawa.ca/software/tsm/index.html 

[3] http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp 

[4] http://www-01.ibm.com/support/docview.wss?uid=swg21243309#client_x86linux 

[5] http://www-01.ibm.com/software/tivoli/products/continuous-data-protection 

[6]http://www.ibm.com/developerworks/br/tivoli/resources/Introducao_ao_TSM_61_R8C_2. 

pdf 

[7]http://www.ibm.com/developerworks/br/tivoli/resources/Novidades_do_TSM_61_R8C_2. 

pdf 

[8] http://www.psu.edu/dept/aset/ait/tsm/5.1docs/html/qstart/anraqs15.htm 

[9]http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.srv.do 

c/t_move_bkup_media.html 

[10]http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.srv.d 

oc/t_move_bkup_media.html 

[11] http://www.redbooks.ibm.com/redbooks/pdfs/sg246247.pdf 

23

Sistema de Backup utilizando IBM - Tivoli Storage Manager ... - PPGIa

Create successful ePaper yourself

Delete template?

Save as template?