8.4. Informações Específicas do Red Hat Enterprise Linux

8.4.2.1. tar

O utilitário tar é bem conhecido dentre os administradores de sistemas UNIX. É o método de arquivamento preferido para compartilhar partes do código fonte e arquivos entre sistemas. A implementação do tar inclusa no Red Hat Enterprise Linux é o tar do GNU, uma das implementações tar mais ricas em funcionalidades.

Usar o tar para fazer backup do conteúdo de um diretório pode ser tão simples quanto invocar um comando similar a:

tar cf /mnt/backup/home-backup.tar /home/

Este comando cria um arquivo chamado home-backup.tar no diretório /mnt/backup/. O arquivo contém o conteúdo do diretório /home/.

O arquivo resultante será quase tão grande quanto os dados sendo copiados para backup. Dependendo do tipo de dados sendo copiados, comprimir o arquivo pode significar uma grande redução no tamanho. O arquivo pode ser comprimido adicionando apenas uma opção ao comando anterior:

tar czf /mnt/backup/home-backup.tar.gz /home/

O arquivo home-backup.tar.gz resultante agora foi comprimido pelo gzip [1].

Há muitas outras opções para o tar; para saber mais, leia a página man do tar(1).

8.4.2.2. cpio

O utilitário cpio é outro programa tradicional do UNIX. É um programa excelente para mover dados de uma localidade a outra e, como tal, pode servir também como programa de backup.

O comportamento do cpio é um pouco diferente do tar. Ao contrário do tar, o cpio lê os nomes dos arquivos que deve processar através do input padrão (standard input). Um método comum para gerar uma lista de arquivos para o cpio é usar programas como o find, cujo output é então enviado (piped) ao cpio:

find /home/ | cpio -o > /mnt/backup/home-backup.cpio

Este comando cria um arquivo cpio (contendo todos os dados de /home/) chamado home-backup.cpio e localizado no diretório /mnt/backup/.

	Dica
	Como o find tem uma variedade de testes de seleção de arquivos, é fácil criar backups sofisticados. Por exemplo: o comando seguinte faz um backup somente dos arquivos que não foram acessados no último ano:

find /home/ -atime +365 | cpio -o > /mnt/backup/home-backup.cpio
            

Há muitas outras opções para o cpio (e para o find). Para aprender mais sobre elas, leia as páginas man do cpio(1) e do find(1).

8.4.2.3. dump/restore: Não Recomendado para Sistemas de Arquivo Montados!

Os programas Linux dump e restore são equivalentes aos programas UNIX de mesmo nome. Sendo assim, muitos administradores de sistemas com experiência no UNIX podem pensar que o dump e o restore são boas opções para um programa de backup sob o Red Hat Enterprise Linux. No entanto, um dos métodos de uso do dump pode causar problemas. Aqui está o comentário de Linus Torvald sobre o assunto:

From:	 Linus Torvalds
To:	 Neil Conway
Subject: Re: [PATCH] SMP race in ext2 - metadata corruption.
Date:	 Fri, 27 Apr 2001 09:59:46 -0700 (PDT)
Cc:	 Kernel Mailing List <linux-kernel At vger Dot kernel Dot org>

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote:
> > I'm surprised that dump is deprecated (by you at least ;-)).  What to
> use instead for backups on machines that can't umount disks regularly? 


Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
Russian roulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)  data
corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..

		Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about it.

Dado este problema, o uso do dump/restore em sistemas de arquivo montados não é recomendado. Entretanto, o dump foi originalmente desenvolvido para fazer backup de sistemas de arquivo não montados; consequentemente, em situações nas quais é possível tornar um sistema de arquivo offline com o umount, o dump continua sendo uma tecnologia viável para backup.

8.4.2.4. O Arquivador de Disco de Rede Automático Maryland Avançado (AMANDA, The Advanced Maryland Automatic Network Disk Archiver)

AMANDA é uma aplicação de backup baseada no cliente/servidor produzida pela Universidade de Maryland. Por ter uma arquitetura cliente/servidor, um único servidor de backup (normalmente, um sistema bastante poderoso com bastante espaço livre nos discos rápidos e configurado com o dispositivo de backup desejado) pode fazer backup de muitos sistemas cliente, que não precisam mais do que o software cliente AMANDA.

Esta tática de backup faz muito sentido, pois concentra estes recursos necessários para backups em um único sistema, ao invés de precisar de hardware adicional para cada sistema que requerer serviços de backup. O design do AMANDA também serve para centralizar a gestão dos backups, facilitando bastante a vida do administrador de sistemas.

O servidor do AMANDA administra uma série de mídias de backup e alterna o uso entre elas para garantir que todos os backups sejam retidos pelo período de retenção determinado pelo administrador. Todas as mídias são pré-formatadas com dados que permitem ao AMANDA detectar se a mídia apropriada está disponível ou não. Além disso, o AMANDA pode interfacear com mídia robótica alterando unidades, possibilitando automatizar os backups completamente.

O AMANDA pode usar o tar ou o dump para fazer os backups (é preferível usar o tar sob o Red Hat Enterprise Linux devido às questões do dump abordadas na Seção 8.4.2.3). Sendo assim, os backups do AMANDA não requerem o AMANDA para restaurar os arquivos — um valor agregado.

Em operação, o AMANDA é normalmente agendado para rodar uma vez por dia durante a janela de backup do centro de dados. O servidor do AMANDA conecta aos sistemas cliente e os direciona a produzir tamanhos estimados dos backups a serem feitos. Uma vez disponibilizadas as estimativas, o servidor cria uma agenda, determinando automaticamente a ordem na qual os sistemas terão seus backups feitos.

Após os backups iniciarem, os dados são enviados através da rede, do cliente para o servidor, onde são armazenados em um disco de espera. Uma vez completo o backup, o servidor começa a gravá-lo pelo disco de espera na mídia de backup. Ao mesmo tempo, outros clientes estão enviando seus backups ao servidor para serem armazenados no disco de espera. Isto resulta num fluxo de dados contínuo disponível para gravação na mídia de backup. Conforme os backups são gravados na mídia de backup, são apagados do disco de espera do servidor.

Uma vez completos todos os backups, o administrador de sistemas recebe um e-mail com um relatório descrevendo o status dos backups, facilitando e dinamizando a revisão.

Se for necessário restaurar dados, o AMANDA contém um programa que permite ao operador identificar o sistema de arquivo, data e nome(s) do(s) arquivo(s). Após fazer isso, o AMANDA identifica a mídia de backup correta e então localiza e restaura os dados desejados. Conforme mencionado anteriormente, o design do AMANDA também possibilita restaurar dados mesmo sem a assistência do AMANDA, apesar da identificação da mídia correta ocorrer mais lentamente e manualmente.

Esta seção cobriu apenas os conceitos mais básicos do AMANDA. Para pesquisar mais sobre o AMANDA, comece pela página man amanda(8).