atomicidade de backup do sistema de arquivos Linux

Question

Na minha máquina Linux, estou usando um script de backup feito em casa, que na verdade são algumas chamadas de rsync. Eu testei minhas restaurações e tudo parece estar funcionando, mas há algum problema com essa configuração?

Minha principal preocupação é a atomicidade deste backup. Tanto quanto sei, os arquivos no Linux não estão bloqueados. Os arquivos podem ser copiados se apenas parcialmente escritos? É possível que bancos de dados, arquivos xml ou quaisquer outros arquivos gravados com frequência que tenham uma estrutura ou uma sintaxe possam acabar quebrados ou inutilizáveis em um local de backup?

    

Answer 1

Para um backup atômico, você precisa, idealmente, interromper todo o acesso de gravação à área que está sendo armazenada, o que significa interromper todos os serviços que possam gravar para eles.

Se você usar o LVM, o recurso de captura instantânea tornará isso muito menos oneroso, pois você só precisará interromper os serviços pelo tempo necessário para criar o instantâneo somente leitura, que é quase instantâneo. Você pega o backup do snapshot e o remove até que um novo seja necessário para a próxima execução do backup. Consulte o link para obter mais detalhes.

Não deixe o (s) snapshot (s) ativo (s) por mais tempo do que o necessário, pois há implicações de desempenho (embora isso seja um problema muito menor do que ter um período de inatividade total enquanto os backups são executados).

    

Answer 2

Em relação às bases de dados, por vezes, é mais seguro despejar os dados e, em seguida, fazer o backup do despejo. Por exemplo, o MySql vem com essa ferramenta mysqldump que pode realizar isso.

Eu uso Bacula para fazer meus backups, e eu o tenho configurado para executar o mysqldump para despejar os bancos de dados em um diretório para os dumps e então o bacula faz o backup deste diretório. Eu faço algo similar para o SVN.

Eu não tenho o procedimento de restauração automatizado, mas pelo menos eu tenho os dados em um formato fácil de importar para MySql e provavelmente em outros bancos de dados, já que o arquivo de despejo é apenas SQL

    

Answer 3

Sim, eles ainda podem ser copiados. Como sugerido acima, eu despejaria os bancos de dados em um arquivo, bzip-los para uma boa compactação, em seguida, rsync-los para onde for

# mysqldump --all-databases -u user -p | bzip2 -c > mysqlbackup.sql.bz2
# <rsync stuff here>

Em seguida, carregue-o no novo banco de dados

# bzip2 -d mysqlbackup.sql.bz2
# mysql -u user -p < mysqlbackup.sql

Para facilitar ainda mais a paranóia, às vezes eu reverti para lsof -F | grep <keyword> para ver se o arquivo que desejo transferir está realmente em uso ou aberto. Se lsof retornar null, então sei que estou certo em continuar. Você poderia usá-lo para procurar por uma tabela MySQL aberta como o MySQL está escrevendo para ela. Quando lsof retornar null, você poderá continuar transferindo arquivos.

    

Answer 4

De acordo com esta página , você deve fazer o backup do banco de dados em um arquivo e depois pará-lo antes do rsync. Não é ideal porque você precisa fazer backup de todo o banco de dados toda vez. Um procedimento especializado de backup de banco de dados é o melhor.