Centos 6 - Backup e Restauração / Recuperação

Question

Eu estou tentando testar e documentar um procedimento de backup e restauração para o Centos 6. Aqui é onde eu estou, mas há algumas áreas onde eu preciso de um pouco de clareza. A documentação de backup / restauração do CentOS na net é um sucesso e um fracasso.

Plano geral de backup e restauração

• Faça backup de seus sistemas todos os dias usando seu software de backup favorito. Eu não vou entrar nisso em grande profundidade, mas digamos que você tenha um sistema de backup adequado que permita fazer um backup de um sistema e restaurá-lo para outro.

• Fumaça e chama envolvem um dos seus servidores! Depois de lidar com o perigo imediato, você percebe que um sistema importante está irreparavelmente danificado. Você precisa restaurá-lo para um hardware diferente.

• Verifique os arquivos de backup. Veja o backup do arquivo /etc/redhat-release do sistema com falha. Use isto para estabelecer qual versão (nível de correção) do CentOS o sistema com falha estava usando? Agarre a instalação mídia para esta versão.

• Usando a mídia de instalação, faça uma instalação mínima do sistema operacional no hardware de substituição, particionando os discos conforme apropriado para o uso final do sistema.

• Após a instalação do sistema mínimo, desative temporariamente o selinux, echo ‘0’> /selinux/enforce stop iptables, service iptables stop e instale o cliente de backup.

• Recupere-se do backup, excluindo os seguintes arquivos da recuperação:

/proc
/sys
/tmp
/dev
/var/lock <- don't exclude from restore - see answer
/var/run <- don't exclude from restore - see answer
/var/tmp
/etc/fstab
/etc/mdadm.conf
/etc/mtab
/etc/resolv.conf
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/kernel
/etc/hosts
/etc/modprobe*
/etc/networkmanager <- to ensure that IP isn't restored - see answer
/etc/udev
/lib/modules
/boot

• Quando a restauração estiver concluída, reinicialize e observe os erros

• Verifique se a configuração da rede está correta. Pode ser necessário usar system-config-network para fazer alterações nas configurações de sua rede.

• Alguns aplicativos como Apache e MySQL podem não iniciar corretamente após a restauração. Como /var/run foi excluído da restauração, as subpastas como /var/run/httpd não existirão e, assim, os aplicativos não poderão criar arquivos PID adequadamente. Você precisa restaurar pastas como /var/run/httpd/ e /var/run/mysqld/ e dar a elas as permissões corretas. Isso não deve ser um problema, desde que você não exclua / var / run e / var / bloquear a partir da restauração - veja a resposta.

• Após concluir a ação corretiva, certifique-se de que os aplicativos sejam exibidos corretamente.

• Se você estiver executando um banco de dados MySQL, ainda pode ser OK sem ter que restaurá-lo a partir de qualquer backup flatfile que você possa ter feito. Você pode verificar o estado do banco de dados executando mysqlcheck -c -u root –p******** --all-databases . Se você vir algum erro, execute mysqlcheck -c -u root –p******** --all-databases --auto-repair para repará-los. Você deve sempre garantir que tenha um backup adequado do banco de dados, conforme indicado na resposta abaixo. Eu pessoalmente uso o mysqldump.

• Atualize o sistema para o nível mais recente usando yum update .

• Após a reinicialização para garantir que o sistema volte a verificar de forma clara e completa as mensagens / var / log / messages em busca de erros, teste a funcionalidade do sistema para garantir que esteja funcionando corretamente. Quando esse for o caso, use system-config-network para alterar o endereço IP para o sistema com falha original.

Questões / Perguntas

• A exclusão de /var/run/* da restauração faz com que as subpastas usadas para conter PIDs de alguns aplicativos não sejam criadas quando você as restaura. É realmente necessário excluir /var/run/* da restauração? É uma maneira melhor de simplesmente não restaurar os arquivos PID?

• Quando o sistema foi restaurado, o endereço IP do 'sistema defeituoso' também foi restaurado. Eu não queria isso. Eu devo ter perdido um arquivo da minha lista "excluir da recuperação". Alguma idéia onde está?

• Ao atualizar, recebo muitas mensagens como /sbin/ldconfig: /usr/lib64/libblah.so is not a symbolic link . Quando eu reiniciar o sistema depois de atualizar alguns serviços não aparecem corretamente. Gostaria de saber se isso é algo a ver com o sistema de backup restaurando os arquivos que os links simbólicos apontam para os próprios links simbólicos. Se eu executar o ldconfig e olhar para um dos objetos compartilhados que ele reclama, o objeto compartilhado é um arquivo real em vez de um symlink. Alguém mais viu isso?

Answer 1

1. Excluindo /var/run

Como você já percebeu, excluir /var/run durante uma restauração completa de um sistema do CentOS 6 causa problemas, porque também exclui diretórios criados por pacotes instalados. A exclusão de /var/lock também pode causar problemas semelhantes, porque alguns pacotes também criam subdiretórios.

(Pode não haver tais problemas em distribuições Linux mais recentes que usam systemd - em tais distribuições /var/lock e /var/run (realmente /run ) podem ser colocadas em tmpfs , e quaisquer subdiretórios necessários são criado durante cada inicialização, no entanto, o CentOS 6 é muito mais antigo e não tem nenhum suporte para a criação automática de subdiretórios em /var/lock ou /var/run .)

No entanto, excluir realmente /var/run e /var/lock não é necessário para uma restauração adequada, porque o script /etc/rc.d/rc.sysinit no CentOS 6 inclui o seguinte comando:

find /var/lock /var/run ! -type d -exec rm -f {} \;

Este comando removerá todos os arquivos obsoletos de bloqueio ou pid (ou quaisquer outros arquivos que não sejam de diretório, como sockets e links simbólicos) durante a inicialização do sistema. Portanto, você deve remover /var/lock e /var/run da lista de exclusões de restauração.

2. Localização dos arquivos de configuração de rede

Você já excluiu /etc/sysconfig/network* ao restaurar o backup; isso deve corresponder ao arquivo /etc/sysconfig/network (configuração de rede global) e ao diretório /etc/sysconfig/network-scripts (arquivos de configuração por interface ifcfg-* ). No entanto, esses arquivos são usados somente pelo estilo antigo scripts de configuração de rede incluídos no pacote initscripts , e o CentOS 6 tem outro sistema de configuração de rede - NetworkManager , cuja configuração está armazenada em /etc/NetworkManager . Tente também excluir esse diretório ao restaurar o backup.

3. O problema com links simbólicos substituídos por arquivos

Se você ver que os links simbólicos foram substituídos por arquivos simples após a restauração, isso significa que seu programa de backup / restauração não foi configurado corretamente ou (se não houver opção para salvar e restaurar links simbólicos reais) o programa usado não é adequado para backup / restauração do sistema Linux. Você pode usar um programa que não suporta links simbólicos apenas se o programa for usado para fazer backup e restaurar apenas alguns dados específicos que definitivamente não conterão links simbólicos. Note que você pode encontrar links simbólicos em lugares onde você não os esperava - por exemplo, em alguns casos, links simbólicos podem ser usados em diretórios de banco de dados MySQL (para armazenar algumas partes de dados em um dispositivo diferente), portanto confiando na suposição “sem links simbólicos” pode ser perigoso.

4. Backup MySQL

Se o seu programa de backup simplesmente copia arquivos de um servidor em execução, o seu backup não é realmente “consistente”, porque arquivos diferentes (e até mesmo blocos diferentes de um mesmo arquivo) são copiados em momentos diferentes, portanto você não obterá realmente um instantâneo consistente do banco de dados no seu backup. (Isso se aplica a qualquer tipo de banco de dados, não apenas ao MySQL.)

Existem várias maneiras de fazer backup de bancos de dados MySQL usando apenas um backup em nível de arquivo:

1. Use mysqldump para criar um despejo SQL antes de iniciar o backup em nível de arquivo; faça backup do arquivo de despejo em vez do diretório do banco de dados. Esse é o formato de backup mais portátil, mas tanto o despejo quanto a restauração podem ser lentos.

2. Pare o servidor MySQL antes de iniciar o backup, faça um backup em nível de arquivo e inicie o servidor MySQL novamente. Para restaurar, restaure todos os arquivos no novo servidor e inicie o servidor normalmente. Esse tipo de backup é rápido, mas requer um tempo de inatividade significativo durante o backup.

3. Para reduzir o tempo de inatividade do servidor MySQL exigido pelo método anterior, você pode criar um instantâneo do sistema de arquivos depois de parar o servidor, iniciar o servidor MySQL novamente, montá-lo, executar um backup em nível de arquivo e excluir o instantâneo. Você precisa ter o sistema de arquivos em um volume LVM com algum espaço livre no grupo de volumes para o instantâneo.

4. Para reduzir ainda mais o tempo de inatividade, você pode usar FLUSH TABLES WITH READ LOCK antes de tirar o instantâneo em vez de parar o servidor, conforme descrito aqui ; neste caso, o instantâneo conterá tabelas MyISAM em um estado consistente e tabelas InnoDB em um estado consistente com falhas (a recuperação do InnoDB será necessária após uma restauração no nível do arquivo).

Leia esta documentação para mais informações sobre o backup do MySQL .

    

Answer 2

Combinando a lista de exclusão neste thread da Pergunta, e um tutorial da Rackspace, eu pude fazer a configuração abaixo trabalhar de forma confiável para replicar / copiar um servidor CentOS instalado inteiro.

Minha configuração é o CentOS 6.7 + Virtualmin. No entanto, isso possivelmente funcionaria com o CentOS 6.X sem nenhum painel de controle.

O procedimento que criei está abaixo:

• Instale o Centos 6.X no servidor de destino mínimo
• Instale o Virtualmin a partir do install.sh
• Efetue logout do servidor de destino, mas deixe-o
• Restaurar backup do servidor com rsync do servidor de backup
• Reinicializar servidor de destino
• Faça o login no Virtualmin
• IPs corretos com a ferramenta Virtualmin (Ele já perguntará)
• Nome do host correto
• Restaurar backups de servidor virtual (site) do servidor de backup (caso você esteja usando servidores virtuais e tenha alguma conta lá)
• Remova php_value, php_admin_value do httpd.conf se o virtualmin os adicionar
• Verificar a configuração do Virtualmin na ferramenta Virtualmin

Se você não estiver usando o Virtualmin, possivelmente precisará deixar itens do Virtualmin.

A lista de arquivos de exclusão para copiar para o servidor remoto está abaixo:

/boot
/proc
/sys
/tmp
/dev
/var/tmp
/etc/fstab
/etc/mdadm.conf
/etc/mtab
/etc/resolv.conf
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/kernel
/etc/hosts
/etc/modprobe*
/etc/networkmanager
/etc/udev
/lib/modules
/var/lock
/etc/conf.d/net
/etc/network/interfaces
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/hostname
/etc/HOSTNAME
/etc/modules
/net
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*

Créditos:

link

    

Answer 3

Há um excelente projeto de fonte aberta ReaR (Relax and Recover) que fez coisas incríveis na área de criação de um backup de estilo de imagem do Linux (incluindo o CentOS e o Red Hat). De particular interesse é a forma legal como eles capturam o layout do sistema de arquivos e incorporam isso em seu disco de recuperação para fazer com que a restauração do layout do sistema de arquivos funcione muito bem. O melhor de tudo, está escrito em bash (e muito bem escrito bash to boot!).

Nós não temos nenhuma conexão com o projeto, além de que escrevemos um rápido tutorial link .