Processos administrativos - continuação 2

Dando continuidade aos processos administrativos, conforme comentado ontem, vou falar sobre o collocation e o expiration.

Processo COLLOCATION

O collocation é um parâmetro configurável no STGPOOL. Sua finalidade é agrupar dados de um mesmo client node em uma mesma fita.

Vamos acompanhar a ilustração abaixo para visualizar melhor.

Todos os backups executados para stgpool de disco, quando são migrados para fita através do processo migration, são agrupados por client node, ou seja, todos os backups do Client A, somente utilizarão as fitas destinadas ao Client A e assim por diante.

A grande vantagem é a execução de restore mais ágil, já que o robo não precisará realizar grande quantidade de montagem.

A desvantagem é o alto consumo de fitas, pois provavelmente o ambiente ficará com dados agrupados por client node, porém com muitas fitas com baixa porcentagem de utilização.

Processo EXPIRATION

O processo expiration,  basicamente aplica as retenções de backup definidas na política, no DB do TSMServer.

Este processo deleta as referências de dados, ou seja, deleta o apontamento no DB do TSM do dado que foi expirado.

Sem esse apontamento no DB, não é possível restaurar dados, mesmo que fisicamente ainda existam nas fitas.

Somente seria possível realizar o restore se.:

A fita fisicamente não for sobrescrita.

E que se realize o restore do DB do TSM em um ambiente paralelo com data anterior a execução do expire.

Recebi um email bacana do leitor Júlio. Sua dúvida é referente ao backup baseado em versões, sua execução e expiração.

Amanhã vou tratar deste assunto. Caso tenham sugestões de tópicos, entre em contato.

Tenham todos um ótimo dia.

Processos administrativos - continuação

Dando sequência ao tópico sobre processos administrativos, o próximo que gostaria de comentar é o processo Reclamation ou Space Reclaim.

Processo RECLAMATION

Basicamente, este processo tem como objetivo agrupar dados que estão espalhados em diversas fitas com baixa porcentagem de utilização, movendo esses dados para uma nova fita, fazendo com que as fitas com baixa utilização voltem a ficar com status SCRATCH.

Acompanhe as ilustrações a seguir.:

Na ilustração acima, percebemos que a fita está com 100% de utilização. Após um período, a mesma fica fragmentada, uma vez que o processo de expiração de dados está efetuando a limpeza conforme política definida. O reclaim faz com que todas as fitas nesse estado, tenham os dados reagrupados e movidos para uma nova fita, fazendo com que as fitas sejam melhor utilizadas.

Acompanhem este outro exemplo.:

Podemos observar que em um primeiro momento, um grupo de fitas de diversos clients, estão com sua capacidade máxima de dados armazenados.

Em seguida, conforme a política de retenção de dados aplicada, alguns dados vão sendo expirados e portanto as fitas começam a ficar com espaços vazios.

Após definir o threshold a ser configurado, o processo de space reclaim, reclamation ou simplesmente reclaim, é iniciado e todos os dados são consolidados em um menor número possível de fitas.

• Agiliza os processos de restores
• Possibilita que as fitas sejam liberadas para re-utilização
• Não há necessidade de aguardar a expiração de todos os dados
• Menor custo, já que com isso, é possível reutilizar mais vezes as fitas com baixa porcentagem de utilização, evitando assim, compra de novas fitas

O reclaim é um processo administrativo e portanto pode-se criar um schedule para que fique programado sua execução automaticamente no ambiente, sem intervenção do administrador.

Processo MOVE DATA

O processo de move data é igual ao reclaim, porém o mesmo é executado manualmente.

No próximo post, falarei sobre o processo de COLLOCATION e EXPIRATION.

Tenham todos um ótimo dia.

Processos administrativos

O TSM possui alguns processos administrativos que visam facilitar o trabalho de manutenção e administração do ambiente.

Vamos comentar um pouco sobre cada um deles.:

Processo de MIGRATION

Para permitir o backup simultâneo por parte dos servidores, sem afetar a distribuição dos dados entre as fitas, e visando também  garantir uma melhor performance no caso de restore, o TSM trabalha com o conceito de migração de dados entre Pools, ou seja, permite que todos os equipamentos envolvidos  consolidem seu backup numa área temporária em disco, acessada pelo TSMServer, que de forma online, ordena esses dados entre as fitas, fazendo com que os drives sejam melhor aproveitados, sem que fiquem ociosos.

Vejam a ilustração a seguir.:

Pela ilustração, é possível visualizar melhor como funciona o processo.:

1- Client A, B,... Z envia os dados do backup para o TSMServer

2- O TSMServer armazena esses dados em uma área temporária. (STGPOOL de disco)

3- Durante o processo de migration, o TSM consolida os dados dos servidores de forma que facilite e agilize uma possível solicitação de restore, evitando que os dados de um mesmo client fique espalhado em diversas fitas.

Este processo de migration possui um threshold a ser configurado. É o que chamamos de High threshold e Low threshold.

Vejam a ilustração abaixo.:

Quando o STGPOOL de disco enche ou o mesmo atinja a configuração definida pelo administrador, os dados automaticamente são migrados para o próximo STGPOOL, o que pode ser um outro STGPOOL de disco ou de fita.

Acompanhe a próxima ilustração.:

No exemplo desta ilustração, o High Threshold foi configurado a 80% e o Low Threshold a 20%.

Quando o High Migration Threshold é atingido (80%), o processo de migration inicia automaticamente, procurando pelo node que tenha feito backup do maior file space ou o archive que ocupam o maior espaço. O objetivo é para que o processo libere espaço no disco mais rapidamente.

Após determinar o node,o server verifica o número de dias que ele foi armazenado ou acessado. Se for maior que o migration delay period, o processo inicia a movimentação dos dados para o next stgpool.

No exemplo acima, o filespace que ocupa o maior espaço é um de 1 gb, portanto é o primeiro a ser migrado.

Se depois de migrar todos os dados do client node a % do stgpool for menor do que está definido no Low Threshold, o migration finaliza, senão, um novo client node é escolhido.

Gostaria de falar sobre os demais processos administrativos, porém creio que o post ficaria muito grande. Amanhã voltamos ao assunto para falar sobre o processo de RECLAMATION.

Tenham todos um ótimo dia.

Os tipos de backup

Hoje gostaria de comentar um pouco sobre os tipos de backups que existe no TSM.

Seletivo

Grava todos os objetos informados, sem distinção. É um backup full.

Incremental

Grava todos os objetos novos ou modificados com base no último incremental ou no último seletivo.

Image

Não faz distinção de objetos por arquivos ou diretórios individuais. É enviado para o TSMServer um volume inteiro como sendo um único objeto. Entenda-se como volume, uma partição ou file system (Semelhante ao Ghost). É utilizado também para backup de Raw Devices.

Observação.: Não faz restore parcial, ou de arquivos. Somente da partição inteira.

Journal

O journal cria uma lista de objetos novos ou modificados no ambiente. É muito bom para ser usado em file servers com grande quantidade de arquivos, pois evita que o TSMServer inspecione o disco inteiro para localizar objetos novos ou modificados. Assim que o backup inicia, o TSM utiliza a lista criada pelo journal para gravar diretamente os objetos que lá estão listados. O ganho é o tempo de backup.

Incremental Progressivo

É um conceito implementado no TSM que remove a necessidade de ter um backup full periódico para que o incremental possa ser executado baseado nesse full.

Todas as vezes que um novo client node é inserido no TSM, usando-se a política de somente backup incremental progressivo, somente os objetos novos ou modificados são gravados, exceto na primeira execução, que como não base de comparação, o primeiro backup é sempre full.

Segue uma imagem ilustrativa sobre a comparação entre backups Full + Incremental, Full + Diferencial, Incremental Progressivo.

Com a implementação do Incremental Progressivo

• Não é necessário o backup full periódico
• Melhor aproveitamento do espaço em midias, e portanto, menor consumo, o que significa menor custo
• Baixo consumo do tráfego da rede

Tenham todos um ótimo dia.

Arquitetura da política de backup

Conforme havia comentado ontem, hoje quero abordar um tópico sobre a arquitetura da política de backup no TSMServer.

Há 4 níveis de objetos de política.:

• Policy Domain
• Policy Set
• Management Class
• Copy Groups

Vamos entrar nos detalhes de cada um.:

• POLICY DOMAIN

Esta é o topo da estrutura da política e o mais simples em relação ao seu conteúdo e configuração.

A Policy Domain permite agrupar client nodes logicamente, por características semelhantes, como por exemplo, pelo tipo de plataforma - AIX Domain, Windows Domain -, ou ainda, pelo tipo de dados a ser copiado, por exemplo, todos os nodes de backup de banco de dados Oracle, SQL..etc.

Outro tipo de uso é agrupar os nodes por função organizacional, por exemplo, departamento financeiro da localidade São Paulo.

Existem apenas 3 parâmetros para serem setados.:

• DESCRIPTION - Descrição do domínio, algo que determine a característica / identificação deste domínio
• BACKRETENTION - Esse parâmetro fica válido apenas quando toda estrutura que está abaixo do Domain relativo a um BACKUP é deletado, ou seja, se todas as políticas do TSM forem deletadas, os backups armazenados assumem a retenção setada nesse parâmetro. 30 dias é o valor default desse parâmetro.
• ARCHIRETENTION - Esse parâmetro fica válido apenas quanto toda a estrutura que está abaixo do Domain relativo a um ARCHIVE é deletado, ou seja, se todas as políticas do TSM forem deletadas, os archives armazenados asusmem a retenção setada nesse parâmetro. 365 dias é o valor default desse parâmetro.

• POLICY SET

Esta é a segunda camada de objetos da estrutura da política de backup. O único parâmetro a ser definido na criação de uma Policy Set é DESCRIPTION

• Apenas 01 (UMA) policy set pode estar ACTIVE em um Domain por vez. Podem haver várias Policy's Set definidas em uma Policy Domain, mas apenas UM deles será a ativa.
• A Policy Set ACTIVE é quem contém as Management Classes que serão associadas aos BACKUPS e ARCHIVES realizados.
• Quando uma Policy Set é ACTIVATED, o conteúdo dessa política é copiada para a política que terá o nome ACTIVE.
• Comandos possíveis para uma Policy Set.: define, copy, validate, activate, e também a descrição pode ser atualizada.

• MANAGEMENT CLASS

O terceiro nível da estrutura da política de backup é a MANAGEMENT CLASS, que podem ser quantas classes necessitar.

Cada MGMT Class pode conter um BACKUP COPYGROUP e/ou um ARCHIVE COPYGROUP. É necessário a definição desses Copy Groups de acordo com o tipo de operação que deseja executar (BACKUP e/ou ARCHIVE).

Para ativar uma Policy Set é necessário pelo menos uma MGMT Class e deve ter, obrigatoriamente, uma MGMT Class que é definida como DEFAULT.

As MGMT Class também gerenciam o modo de armazenamento do HSM. Os parâmetros que devem ser setados são.: SPACEMGTECHNIQUE, AUTOMIGNONUSE, MIGREQUIRESBKUP, MIGDESTINATION.

Os objetos gravados são associados a uma MGMT Class através da opção INCLUDE, que é setada no client node (dsm.sys ou dsm.opt), como no exemplo abaixo.:

INCLUDE * MGMT_30D

Neste exemplo todos os objetos gravados no servidor, estarão associados a MGMT Class de retenção 30 dias.
Se nenhuma MGMT Class for associada ao objeto, a MGMT Class Default é utilizada.

• COPYGROUP

Último nível da estrutura da política de backup é o Copy Group. Existem 2 tipos de Copy Group : BACKUP e ARCHIVE


Cada tipo contém parâmetros determinados que setam quanto tempo o objeto permanecerá retido ou quando ele será deletado.

Todos os Copy Group's chamam : STANDARD. Eles são diferenciados pela estrutura de MGMT Class, Policy Set e Policy Domain que está associado.

• BACKUP COPYGROUP:

Determina o destino dos objetos do tipo BACKUP e sua retenção. Seguem os principais parâmetros.:

• DESTINATION : determina o Storage Pool primário onde os dados serão inicialmente armazenados. O mesmo pode ser um STGPOOL de disco, fita, etc. Não pode ser um Copy Storage Pool.

• FREQUENCY.: frequência de quanto o TSM pode copiar um objeto. Esse parâmetro é usado apenas para o Backup tipo Incremental, sendo ignorado no Backup tipo Seletivo. O valor default é 0, ou seja, que o objeto seja copiado independente de quando foi copiado na última vez.

• VEREXISTS.: É o número máximo de versões de um mesmo objeto que serão retidas se esse objeto existir fisicamente no servidor. Default é 2, e pode ser setado de 1 a 9999, ou Nolimit.

• VERDELETED.: É o número máximo de versões de um mesmo objeto que serão retidas se esse objeto for DELETADO fisicamente no servidor. Default é 1, e pode ser setado de 1 a 9999, ou Nolimit.

• RETEXTRA.: É o número de dias de retenção de um objeto após ele se tornar inativo. O default é 30 dias. Pode ser setado de 0 a 9999 , ou Nolimit.

• RETONLY.: É o número de dias de retenção de um objeto após ser deletado fisicamente do servidor. O default é 60 dias. Pode ser setado de 0 a 9999 , ou Nolimit

Uma observação importante.: Esses parâmetros são válidos para as versões inativas dos objetos. A versão ativa fica armazenada “para sempre” ou até que o arquivo seja deletado fisicamente do servidor.

Continuando...

• MODE.: Determina se o TSM irá copiar o objeto somente se houve alteração neste objeto desde o último backup, ou se sempre que o cliente executar um backup. Os valores são MODIFIED (defalut) e ABSOLUTE (Full)

• SERIALIZATION.: Determina o que deve ser feito com os objetos que são modificados durante a execução do backup. Os possiveis valores são.:

1. SHRSTATIC (default).: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é ignorado.
2. STATIC.: Tenta gravar o objeto 1 (UMA) vez. Se o mesmo continuar sendo modificado, o objeto é ignorado falha.
3. SHRDYNAMIC.: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é copiado da forma que estiver.
4. DYNAMIC.: O objeto é copiado da forma que estiver.

• ARCHIVE COPYGROUP

Determina o destino dos objetos do tipo ARCHIVE e sua retenção. Seguem os principais parâmetros :

• DESTINATION.: Determina o STGPOOL primário onde os objetos serão inicialmente armazenados. Obs.: Não pode ser um copy storage pool.
• RETVER.: Número de dias de retenção de um archive. O default é 365 dias. Pode ser setado de 0 a 30000, ou Nolimit.
• SERIALIZATION.: Determina o que deve ser feito com os objetos que são modificados durante um backup. Seguem os possíveis valores.:

1. SHRSTATIC (default).: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é ignorado.
2. STATIC.: Tenta gravar o objeto 1 (UMA) vez. Se o mesmo continuar sendo modificado, o objeto é ignorado falha.
3. SHRDYNAMIC.: Tenta gravar o objeto "n" vezes. Se o mesmo continuar sendo modificado, o objeto é copiado da forma que estiver.
4. DYNAMIC.: O objeto é copiado da forma que estiver.

Uma última observação.: Caso uma MGMT Class seja apagada, todos os dados que estavam associados a ela, serão associados a política DEFAULT.
Tomem cuidado com as “limpezas”, pois a política default pode ter uma retenção inferior a politica que foi deletada.

Tenham todos um ótimo dia.

Alguns componentes do TSMServer

Hoje gostaria de escrever um pouco sobre alguns componentes do TSMServer. É bom para que tenhamos uma noção quando tratarmos de questões mais técnicas.

• Administração.:

É possível realizar a administração do TSMServer através da Interface Administrativa. Com ela é possível definir políticas de backup, definir schedules de backup, realizar o gerenciamento de fitas, verificar status de backup, etc..

Normalmente acessada via interface Web - http://localhost:1580/ ou via command line - dsmadmc

Eu particularmente, tenho maior afinidade com a linha de comando. Mas isso varia de pessoa para pessoa.

• Client Node ou simplesmente Node.:

Um node no TSMServer pode ser um servidor de aplicação, um servidor de banco de dados ou até mesmo uma estação de trabalho de um usuário, que se conecta ao TSMServer para execução de backup.

No TSMServer é realizado o registro desse node.

No servidor/estação, é necessário a instalação do binário do TSMClient para que o node seja autenticado e portanto tenha permissão de acesso ao TSMServer para execução de backups.

• Device Class

Uma device class é uma entidade lógica do TSMServer. Nela você associa o hardware que está utilizando, - pode ser um robo, autoloader, ou até mesmo um drive stand-alone - , a um storage pool. Podemos ter diversos robos conectados ao TSMServer, sendo cada um, uma device class, gravando ou migrando dados entre eles, como por exemplo, usar um robo que está localizado em um site para gravar backups de produção e utilizar um robo que está em outro site para duplicar esses dados para Offsite.

Podemos dizer que tudo o que foi gravado durante sua janela de backup é a Cópia 1. O Offsite é a Cópia 2, ou backup do backup. Geralmente as fitas utilizadas no Offsite são enviadas para um cofre por questão de segurança, pois sua finalidade principal é prover o DR (Disaster Recovery).

• Policy Domain

Quando os clients são resgistrados no TSMServer, eles são associados a um domínio (Policy Domain). Uma Policy Domain é um grupo de node de políticas de backup com características semelhantes dentro do TSMServer. Tem por objetivo organizar as políticas de backup existentes e os nodes associados a essas políticas.

• Policy Set

Um Policy Set (conjunto de políticas) contém um grupo de Management Classes (classes de gerenciamento) que existem para um domínio específico. Podemos ter vários Policy Set's dentro de uma Policy Domain, porém somente uma pode estar ativa a cada vez.

• Management Class

As classes de gerenciamento especificam COMO os arquivos serão gerenciados.

• Copy Groups

Copy groups controlam como os dados de backup e de archive serão tratados, e qual a retenção dos mesmos.

Obs.: BACKUP e ARCHIVE são formas de backup disponível no TSM.

BACKUP é configurado para manter versões de objetos, ou seja, se você programou um job de BACKUP Incremental diário e no servidor tiver um objeto que é modificado diariamente, todos os dias este objeto será gravado no backup. Desta forma, você programa quantas versões desse mesmo objeto precisa ser mantida.

ARCHIVE é configurado para manter um objeto retido durante seu tempo de vida, ou X dias. Neste caso o job é sempre full e não em consideração versões de arquivo. Basicamente faz o backup full e retém pelo período determinado na Management Class.

Irei entrar em detalhes sobre a estrutura de uma política de backup, com suas opções de configuração amanhã.

Tenham todos um ótimo dia.

Arquitetura básica do TSMServer

Abaixo temos uma ilustração da arquitetura básica do TSMServer.

Como foi informado anteriormente, o TSMServer é uma ferramenta centralizada. Uma das principais características TSMServer é pelo fato de possuir não apenas um catálogo, como muitas outras ferramentas de backup, mas um Database Relacional.

Este Database foi desenvolvido para o melhor gerenciamento de dados, com a mínima necessidade de administração do banco. Todas as informações relevantes, logs, segurança e autenticação, gerenciamento de fitas e inventário de dados é gerenciado pelo DB do TSMServer.

Em conjunto com o DB, o TSMServer também possui uma área identificada como Recovery Log. Esta área armazena dados durante as transações de jobs que estão em execução e logo em seguida realiza o "commit" no DB. Isso faz com que o DB não seja sobrecarregado, ganhando performance. As transações são gravadas em log e "commitadas" no DB de forma automática, não necessitando intervenção.

No TSMServer também é possível realizar espelhamento do DB e Log de forma automática, aumentando assim, a segurança e disponibilidade do ambiente de backup. Mas isto podemos tratar mais para frente.

Mas como o TSMServer realiza a gravação desses dados ?

O TSMServer possui áreas chamadas de Storage Pool's. Estes STGPOOL's podem ser de discos ou fitas, ou seja, é possível realizar a gravação de dados simultaneamente em STGPOOL's distintos, possibilitando assim, ganho em janela de execução, uma vez que teremos mais jobs de backup executando em paralelo.

Estes STGPOOL's ou devices de armazenamento podem se conectar ao TSMServer via SCSI, LAN ou SAN.

Um detalhe importante em questão de segurança.: As fitas utilizadas para backup em um TSMServer, só podem ser lidas se existir o DB do TSMServer em que foram gravadas aquelas fitas.

Exceção.: Export node para outro server.

Tenham todos um ótimo dia.

O Início

Antes de mais nada, gostaria de apresentar o TSM - Tivoli Storage Manager, para aqueles que ainda não o conhecem e possuem interesse em aprender e a trabalhar na área.

O Tivoli Storage Manager é um software de backup corporativo desenvolvido pela multinacional IBM. Foi desenvolvido para a proteção dos dados críticos das empresas, protegendo-os contra possíveis erros de hardware ou erros manuais, operacionais. Com ele é possível proteger dados desde laptops até mainframes, deviso a sua escalabilidade, pois é possível implementá-lo em uma grande variedade de Sistemas Operacionais distintos, conectados via internet, WAN's, LAN's ou SAN's.

O modo de gerenciamento é centralizado. A configuração no início pode parecer complexa, mas uma vez configurado a política de backup, de acordo com a real necessidade do cliente, basta somente administrá-lo.

Seguem alguns tópicos que gostaríamos de compartilhar.:

-As opções de backup existentes. Tentaremos abordar todas as opções, descrevendo sua funcionalidade e qual seria o melhor momento para implementás-la;

- Configuração de políticas de retenção;

- Programação de Schedules, scripts;

- Relatórios;

- Configuração e administração das áreas de DB (Database) e Recovery Log;

- Linguagem SQL para extrair informações do TSM;

- Aplicação do TSM em diferentes sistemas de Banco de Dados, E-mail, SAP;

- Performance Tunning e sizing;

- Módulos de DR (Recuperação de desastres).... entre outros assuntos.

O blog está aberto a todos que queiram sugerir um assunto específico. Basta entrar em contato através do blog ou via e-mail.: tsmnapratica@gmail.com

Tenham todos um ótimo dia.

Olá, Sejam bem-vindos

Olá,

Sou um profissional da área de TI. Trabalho como Analista de Storage em uma grande empresa há 10 anos, sempre voltado para a área de Backup/Recuperação.

Área esta geralmente esquecida pelas empresas, outras áreas e diversos usuários, porém sempre lembrada no momento em que se precisar recuperar alguma informação crítica.

Costumo dizer que nossa área é o seguro da empresa. É sempre o último recurso utilizado. Se não houver restore, o prejuízo pode ser grande. Costumo dizer também que nossa área é aquela responsável por corrigir os erros cometidos pelas outras áreas de suporte, e portanto de vital importância.

A idéia de criação deste espaço de discussão, foi exatamente pensando em contribuição, ajuda e porque não, suporte. Todos nós temos um conhecimento único, onde a melhor coisa que podemos fazer é compartilhar este conhecimento. Trocar idéias, rotinas diárias, oportunidades de trabalho, programação de treinamentos, aplicação das melhores práticas, novidades das novas versões, visando sempre como aplicar isso no nosso dia-a-dia.

Lembre-se: Não adianta garantir 99% de execução de backup, se o cliente solicitar restore daquele 1% que falhou.