Práticas recomendadas para fazer backup de bancos de dados

Question

Eu perguntei isso em stackoverflow , mas alguém apontou que seria melhor perguntar aqui.

Vamos assumir o Subversion e o MySQL em um NAS RAID. Quais são as melhores práticas para fazer backup de dados?

Eu estava pensando em colocar o mysqldumps sob controle subversion, e então talvez fazer o backup do repositório svn periodicamente com o 7zipping de tudo.

A menos que você esteja armazenando backups svn em um disco rígido físico diferente, não parece que fazer backups do repositório ajudaria. Isso é verdade? Se não, por quê?

Finalmente, com que frequência os backups devem ser feitos e quantos devem ser salvos?

    

Answer 1

Primeiro, não faça a versão controlar seus backups de banco de dados.
Um backup é um backup - um ponto no tempo. Usar o controle de versão soa como uma boa idéia, mas perceber que isso significa que você precisará restaurar todo o repositório SVN (ZOMG Freaking ENORME ) se você tiver uma falha catastrófica e precisar recupere seu banco de dados. Isso pode ser um tempo de inatividade adicional que você não pode pagar.

Em segundo lugar, certifique-se de que seus backups estão saindo do site de alguma forma. Um backup na máquina local é ótimo se você precisar restaurar os dados porque você bagunçou e derrubou uma tabela. Não adianta nada se os discos do seu servidor morrerem.
As opções incluem um disco rígido externo ou o envio dos backups para uma máquina remota usando o rsync. Existem até mesmo provedores de serviços de armazenamento, como o rsync.net, que se especializam nisso.

Em terceiro lugar, em relação à frequência de backups: apenas você sabe com que frequência precisa fazer isso.
Minha empresa atual tem um banco de dados escravo com replicação quase em tempo real de nossos dados de produção. Esse escravo é armazenado em backup todas as noites em uma máquina local, que é sincronizada com uma instalação de armazenamento externo. No caso de uma falha de hardware de produção, ativamos o escravo. A perda de dados deve ser mínima, assim como o tempo de inatividade. No caso de uma exclusão acidental de tabela, podemos restaurar a partir do backup local (perdendo até 1 dia de dados). No caso de um incidente catastrófico, podemos restaurar a partir do backup externo (o que leva um tempo, mas novamente só perderá até 1 dia de dados). Se esse tipo de esquema de backup funciona para você depende dos seus dados: Se ele mudar com frequência, talvez seja necessário investigar uma estratégia de backup que permita a recuperação pontual (as soluções de envio de logs geralmente podem fazer isso). Se é basicamente estático, você só precisa fazer o backup uma vez por mês. A chave é garantir que você capture alterações em seus dados dentro de um tempo razoável de quando elas são feitas, garantindo que você não perca essas alterações no caso de um incidente grave.

    

Answer 2

conselho genérico:

• monitore seus backups
  • verifique se eles terminaram com sucesso [por exemplo, resultado do mysqldump em busca da linha de chegada; verifique os códigos de erro retornados pelos comandos dump],
  • se o tamanho do backup for razoável
• execute testes de recuperação de vez em quando - talvez a cada 3-6 meses
• backup para mídia offline para que você não perca os dados em caso de ataque mal-intencionado
• mantenha os backups fora do local para que você não perca os dados em caso de um desastre natural

conselho específico:

• mysqldumps bombeados para o svn para o versionamento soa como um exagero - remover qualquer coisa do svn é bastante difícil. que tal usar rdiff-backup para manter o último backup e 'diffs' para alguns anteriores?
• svn - use o svnadmin dump - este é o jeito 'apropriado' de pegar os dumps do svn
• se você quiser ser extra-seguro - use lvm e obtenha adicionalmente lvm snapshots dos diretórios de dados mysql e svn
• use o mecanismo de armazenamento innodb para fazer backups sem bloqueio