quarta-feira, 7 de outubro de 2009

Backup para um Diretorio.

Foi uma descoberta e tanto esse procedimento de backup para um diretorio. Aconteceu que eu estava enfrentando um problema com backups de logical logs remoto, ou seja , estava enviando os logical logs diretamente a outros servidores, porem me deparei com o problema de nao atualização da flag (B) do Logical Log, foi onde resolvi abrir um chamado na IBM para tentar sanar o problema, e o Suporte da IBM, onde fui muito bem atendido, me indicaram esse metodo de backup, que particularmente achei muito interessante.

Se você optar por fazer um Backup em diretorios, não sera mais necessario o uso de fitas, que convenhamos da medo, principalmente se for fita DAT. Em vez de, você fazer o backup num diretorio local, que não seria nada seguro, podemos fazer o backup em uma file system montada de um outro servidor, ou seja, usar uma NFS.
O usuario que executa o backup deve obrigatoriamente ter permissão de escrita no diretorio (777). O diretorio deve ter espaço o suficiente para manter os backups dos dados. Voce pode usar o ferramentas do sistema operacional para compactar os arquivos apos o backup.

Vantagens de fazer o backup em um diretorio:
  • Pode-se fazer backup's de varias instancias simultaneamente;
  • Voce pode usar ferramentas do sistema operacional para compactar os arquivos;
  • Voce pode facilmente configurar o sistema de backup de logs para fazer backup automatico qdo os arquivos de logs encherem.
Configurando o caminho do diretorio

Use o parametro de configuração TAPEDEV para especificar o caminho absoluto do diretorio onde sera efetuado o backup. Este e o destino onde o ontape escreve os dados de backup e tambem onde o ontape le os arquivos para restore. Voce também deve especificar um diretorio para o parametro de configuração LTAPEDEV para os backup de Logical Logs.

Use a opção -d com o ontape para desligar o prompt interativo, qdo se efetuar um backup para um diretorio.


Renomeação de arquivos existentes

Quando o ontape repete uma operação archive, ele renomeia os arquivos para que os arquivos existentes nao sejam reescritos. Um timestamp é adicionado ao nome do arquivo.

Convenção de renomeação
  • Archive: Os times de checkpoint são adicionados no archive, e tem esse formato filename_YYYYMMDD_hhmmss_archive-level.
  • Arquivos de Logical Logs: O time do backup é adicionado, e possui esse formato filename_YYYYMMDD_hhmmss.
Exemplo, My_instance_L0 é renomeado para My_instance_20091007_134100_L0.

Quando houver necessidade de restauração do sistema, o ontape exige que o storage-space e os arquivos de logical logs sejam identicos aos especificados pelo parametro TAPEDEV e LTAPEDEV. Se os arquivos foram renomeados, pelo proprio ontape ou manualmente pelo usuario, é necessario uma intervenção manual e voltar os nomes como especificado nos parametros citados.

Voce pode mudar o nome padrao dos backups usando a variavel IFX_ONTAPE_FILE_PREFIX.

quinta-feira, 1 de outubro de 2009

exports - Sistema de Arquivos NFS a ser exportado (para kernel baseado em NFS)

SINOPSE
                  /etc/exports
DESCRIPTION
O arquivo do server /etc/exports, é um arquivo de lista de controle de acesso para sistesmas de arquivos que podem ser exportadas para clientes NFS. Ele é usado pelo exportfs(8) para dar informações ao mountd(8) e para o Kernel baseado no daemon nfsd(8).

O formato do arquivo é similar ao arquivo da SunOS. Cada linha contem um ponto de exportação e um espaço em branco separando as permissões dos clientes para montar o sistema de arquivos naquele ponto. Cada cliente pode ser incluso imediatamente seguido por um parentesis, e as opções separadas por virgulas para esse cliente. Não e permitido espaços em branco entre um cliente e sua lista de opção.

Linhas em brancos são ignoradas. Um ("#") introduz um comentario ate o final da linha. As entradas de dados podem ser prosseguida atraves de novas linhas usando uma barra invertida ("\"). Se um nome exportado contem espaços deve-se usar aspas duplas (" "). Voce tambem pode especificar espaços ou outros caracteres incomuns para a exportação usando uma barra seguido do codigo octal.
Formato de Nomes
O cliente NFS pode ser especificado varias maneiras:
Unico host
este e o formato mais comum. Voce pode especificar um host quer por um nome abreviado reconhecido pelo DNS, um nome de dominio qualificado ou por um endereço IP.

Netgroups
netgroups NIS pode ser usado no formato @grupo. Somente serão autenticados hosts de cada membros dos grupos que são considerados membros habilitados. Hosts vazios ou aquele que contem um traço simples (-) serão ignorados.

Curingas
Nomes de maquinas podem contem caracteres curingas (*) e (?). Podem ser usados para criar arquivos exports menores; por exemplo, *.cs.foo.edu correspondente a todos o hosts do dominio cs.foo.edu. Com esses caractares podemos combinar pontos em um nome de dominio, o modelo citado ira corresponder a todos os hosts dentro do subdominio cs.foo.edu. 

Endereços de Rede IP 
Voce tambem pode exportar diretorios para todos os hosts da rede simultaneamente. Isto é feito especificando um endereço IP e a Mascara de Rede como endereço/mascara onde a mascara pode ser especificada no formato com pontos e numeros decimais, ou  como umas mascara de comprimento contiguos ( por exemplo, este '/255.255.255.0' ou '/22' . Curingas geralmente não trabalha com endereços IP's, embora eles possam trabalhar quando as pesquisas reversas de DNS falhar.

Segurança RPCSEC_GSS
Para restringir acesso a uma exportação usando o rpcsec_gss, use a string especial "gss/krb5" como no cliente. Isto não possibilitara requisições simultaneas rpcseg_gss e fara exigencia sobre o endereço IP do cliente.

Opções Gerais
exportfs compreende as seguintes opções:

secure - Esta opção requer que os pedidos sejam originadas em uma porta menor que 1024. Esta opção é ativado por padrão. Para desligar, especifique insecure.

rw - Habilita leitura e escrita nesse volume NFS. Por padrão isso é desabilitado,o padrão é ro.

async - Esta opção permite que o Servidor NFS viole o protocolo NFS e responda ao pedido antes de quaisquers alterações feitas nos arquivos.
usando esta opção geralmente melhora o desempenho, mas ao custo de perder a integridade dos dados em caso de um crash no servidor, isso pode causar danos, perdas ou dados corrompidos.
Em versões do nfs-utils incluindo ate a versão 1.0.0, essa opção foi padrão. Em lançamentos futuros, sync é padrão, e async tem que necessariamente ser declarado. Para ajudar os administradores de sistemas a tomar conhecimento desta alteração, 'exportfs' ira emitir um aviso se sync ou async for declarado.

no_wdelay - Esta opção não tera efeito caso o async seja definido. O Servidor NFS normalmente demora a fazer um comit de escrita para disco e se o NFS Server suspeitar que há outra requisição solicitando a gravação. Isso permite que multiplas solicitações de gravações requisitadas sejam comitadas para o disco. Se o servidor de NFS recebe pequenos pedidos relacionados, este comportamento pode realmente diminuir a performance, assim no_wdelay esta disponivel como off. Por padrao a opção wdelay é on.
nohide - Esta opção é baseada na opção do IRIX NFS. Normalmente, se um servidor exporta dois sistema de arquivos que esta dentro de um, então o cliente tera que montar dois sistemas de arquivos explicitamente para ter acesso aos sistemas de arquivos. Se ele apenas monta o pai, ele vai ver o outro diretorio vazio onde o outro sistema de arquivo é montado. Esse sistemad e arquivo esta escondido.
Configurando a opção nohide em um sistema de arquivo, faz com que ele não se seja oculto, e um cliente devidamente autorizado se capaz de se mover por ele e seu pai, sem perceber a mudança.
Entretanto, alguns clientes NFS não lidam muito bem com essa situação.
A opção nohide somente é eficiente em single hosts, ele não funciona de forma confiavel com netgroup, subnet ou curingas.
Esta opção pode ser muito util em algumas situações, mas deve ser usado com cuidado, e somente depois de confirmar se o cliente lida com a situação de forma eficaz.
Esta opção pode ser desabilitada com hide.
no_subtree_check - essa opção desabilita a verficação do subtree, que tem implacações de segurança media, mas pode melhorar a confiabilidade em algumas circunstancias.
Se um subdiretorio de um sistema de arquivo é exportado, o servidor deve verificar não so o arquivo que é acessado no sistema de arquivo apropriado (que é mais facil) mas também o que esta na arvore exportada (que é mais dificil). Essa checagem esta ligada a opção subtree_check.
A fim de checar essa verificação, o servidor deve incluir algumas informações sobre a localização do arquivo "filehandle" que é dada ao cliente. Isto pode causar problemas com acessos a arquivos que são renomeados enquanto que um cliente tem esses arquivos abertos (embora em muitos casos simples, ele continuara a funcionar).
subtree também é usado para certificar-se que que os arquivos dentro dos diretorios somente é acessado pelo root, se o sistema de arquivos é exportado com a opção no_root_squash (veja abaixo), então o arquivo é acessado com mais direitos em geral.
Como orientação geral, o sistema de arquivos home, que é normalmente exportado na raiz e podem mudar o nome dos arquivos com frequencia, devem ser exportados com a opção subtree desabilitada. Um Sistema de arquivos que somente leitura, e não possua arquivos que serão renomeados (exemplo, /usr ou /var) e para os quais podem ser subdiretorios, provavelmente deve ser exportado com o subtree ON.
O padrão traz o subtree como habilitado.