1 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
23
Embed
Sistema de Backup utilizando IBM - Tivoli Storage Managerjamhour/RSS/TCCRSS09A/Josmar Neduziak - RS… · 1 Sistema de Backup utilizando IBM - Tivoli Storage Manager Josmar Neduziak
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
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
2
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 2.1 1995
ADSTAR Distributed Storage Manager 1.2.1 1995
ADSTAR Distributed Storage Manager 3.1 1997
ADSTAR Distributed Storage Manager 3.1.1 1998
ADSTAR Distributed Storage Manager 3.1.2 1998
IBM Tivoli Storage Manager 3.7 1999
IBM Tivoli Storage Manager 4.1 2000
IBM Tivoli Storage Manager 4.2.0 2001
IBM Tivoli Storage Manager 4.2.1 2001
3
IBM Tivoli Storage Manager 5.1.0 2002
IBM Tivoli Storage Manager 5.1.5 2002
IBM Tivoli Storage Manager 5.2 2003
IBM Tivoli Storage Manager 5.3 2005
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.
4
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
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
Protocolo de
comunicação 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]
5
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 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
Protocolo de
comunicação
Pelo menos um dos seguintes protocolos de comunicação:
Canais Nomeados
TCP/IP Versão 4 ou Versão 6
Navegador da
Web 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:
6
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:
7
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
8
- 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;
9
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
<nº do request>
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 <user> <password> - 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.
10
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.
11
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.
12
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).
13
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.
14
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;