Fazer backup de um banco de dados MySQL no Git é uma boa ideia?

Antes de perder qualquer dado, deixe-me tentar introduzir uma perspectiva sysadmin para esta questão.

Existe apenas uma razão para criar backups: para possibilitar a restauração quando algo der errado, como invariavelmente ocorrerá. Como tal, um sistema de backup adequado tem requisitos que vão muito além do que o git pode lidar razoavelmente.

Aqui estão alguns dos problemas que posso prever ao tentar fazer backup do banco de dados no git:

• O repositório crescerá drasticamente com cada "backup". Desde que o git armazena objetos inteiros (embora compactados) e então difesta-os mais tarde (por exemplo, quando você executa git gc ) e mantém o histórico para sempre , você tem uma quantidade muito grande de dados armazenados que você realmente não precisa ou nem deseja. Pode ser necessário limitar o período ou o período de retenção de backups que você faz para economizar espaço em disco ou por motivos legais, mas é difícil remover revisões antigas de um repositório do git sem muitos danos colaterais.
• A restauração é limitada a pontos no tempo que você armazenou no repositório e, como os dados são muito grandes, voltar mais do que uma quantidade de tempo trivial pode ser lento. Um sistema de backup projetado para esse propósito limita a quantidade de dados armazenados enquanto potencialmente fornece mais granularidade e fornece restaurações mais rápidas, reduzindo o tempo de inatividade no caso de um desastre. As soluções de backup com reconhecimento de banco de dados ( exemplo ) também podem fornecer backup contínuo , garantindo que nem uma única transação é perdida.
• As confirmações provavelmente também são lentas e ficam mais lentas à medida que o banco de dados aumenta. Lembre-se que o git é essencialmente um armazenamento de dados de valores-chave mapeado em um sistema de arquivos e, portanto, está sujeito às características de desempenho do sistema de arquivos subjacente. É possível que esse período eventualmente exceda o intervalo de backup e, nesse ponto, você não poderá mais atender ao seu SLA. Os sistemas de backup apropriados também demoram mais para fazer backup, à medida que os dados aumentam, mas não tão drasticamente, já que eles gerenciam automaticamente seu próprio tamanho com base na política de retenção que você configurou.

Apesar do fato de que existem aparentemente várias coisas interessantes você pode fazer com um despejo de banco de dados Se você colocá-lo no git, no geral eu não posso recomendá-lo com a finalidade de manter backups. Especialmente desde que os sistemas de backup estão amplamente disponíveis (e muitos são mesmo de código aberto) e funcionam muito melhor para manter seus dados seguros e possível recuperar o mais rápido possível.

Meus dois centavos: não acho que seja uma boa ideia. O GIT faz algo como "armazenar instantâneos de um conjunto de arquivos em diferentes pontos no tempo", então você pode usar perfeitamente o GIT para algo assim, mas isso não significa que você deva . O GIT é projetado para armazenar código-fonte, então você perderia a maior parte de sua funcionalidade, e você estaria trocando muito desempenho por um pouco de conveniência.

Suponha que a principal razão pela qual você está pensando nisso é "manter uma cópia dos dados e do código em sincronia", e isso significa que você está preocupado com a versão 2.0 do seu código que precisa de um esquema de banco de dados diferente que a versão 1.0. Uma solução mais simples seria armazenar o esquema do banco de dados, como um conjunto de scripts SQL com CREATE , ao longo do código-fonte em seu repositório Git. Então, uma parte do procedimento de instalação seria executar esses scripts em um servidor de banco de dados instalado anteriormente.

Os conteúdos reais dessas apenas CREATE -d tabelas não têm nada a ver com a versão do seu código-fonte. Imagine que você instale seu software, versão 1.0, no servidor A e no servidor B, que são usados em diferentes empresas por equipes diferentes. Depois de algumas semanas, o conteúdo das tabelas será muito diferente, mesmo que os esquemas sejam exatamente os mesmos.

Como você deseja fazer backup do conteúdo do banco de dados, sugiro que você use um script de backup que marque o despejo de backup com a versão atual do software ao qual o despejo pertence . O script deve estar no repositório do GIT (para que tenha acesso à string de versão do código-fonte), mas os próprios dumps não pertencem a um sistema de controle de versão.

EDITAR :

Depois de ler a postagem original que motivou a pergunta , acho isso ainda mais duvidoso idéia. O ponto principal é que o comando mysqldump transforma o estado atual de um banco de dados em uma série de instruções SQL INSERT , e o GIT pode diferenciá-las para obter somente as linhas atualizadas da tabela.

A parte mysqldump é boa, pois isso é um dos métodos de backup listado na documentação do MySQL. A parte do GIT é onde o autor não percebe que os servidores de banco de dados mantêm um log de transações para se recuperar de falhas, incluindo o MySQL . É usando este log , não o GIT, que você deveria crie backups incrementais para seu banco de dados. Isto tem, em primeiro lugar, a vantagem de poder rodar ou descarregar os logs após a recuperação, em vez de inchar um repositório GIT no infinito e além ...

Pessoalmente, não acho que seja uma boa idéia usar um sistema de versão de controle de origem para armazenar os arquivos de backup, porque o controle de versão do GIT é projetado para arquivos de dados, não para binários ou arquivos de despejo como um arquivo de despejo de backup do MySQL . O fato de você poder fazer isso não significa automaticamente que você deve fazê-lo. Além disso, seu repositório, considerando um novo backup de banco de dados para cada novo commit, crescerá drasticamente, usando muito espaço no disco rígido e o desempenho do GIT será afetado, resultando em um sistema de controle de origem lento. Para mim, é bom executar uma estratégia de backup e sempre ter um arquivo de backup pronto quando você precisar restaurar o banco de dados quando algo errado der errado, mas as ferramentas de controle de código-fonte não são feitas para armazenar dados binários.

Por esses motivos, não vejo utilidade em armazenar os arquivos de backup para o dia 1 e para o dia 2 e, depois, ver as diferenças entre os dois arquivos de backup. Isso exigirá muito trabalho extra e inútil. Em vez de usar GIT para armazenar backups de banco de dados ao confirmar um novo código, armazene os backups de banco de dados em um caminho diferente, separado por data e hora e insira em seu código alguma referência aos novos backups de banco de dados criados para cada versão, usando as tags como alguém já sugeriu.

Minha nota final sobre os backups de banco de dados e GIT : Um administrador de banco de dados, quando precisa restaurar um banco de dados porque alguns dados foram perdidos, não precisa verificar as diferenças entre o arquivo de backup para o dia 1 e o arquivo de backup para o dia 2, ele precisa apenas saber qual é o último arquivo de backup que permitirá a restauração do banco de dados, sem qualquer erro e perda de dados, reduzindo o tempo de inatividade. Na verdade, a tarefa de um administrador de banco de dados é disponibilizar os dados para recuperação o mais rápido possível, quando o sistema, por alguns motivos, falha. Se você armazenar os backups do banco de dados no GIT, vinculados aos seus commits, você não permitirá que o administrador do banco de dados restaure os dados rapidamente, porque seus backups são limitados a pontos armazenados no repositório do GIT e para reduzir o tempo de inatividade do sistema, porque o desempenho do seu repositório GIT será drasticamente reduzido com muitos dados para armazenar.

Então, eu não recomendo armazenar os backups usando o GIT, use uma boa solução de software de backup (existem alguns deles aqui ), que fornecerá mais granularidade e permitirá que você mantenha seus dados seguros e protegidos e torne sua recuperação de dados simples e rápida em caso de desastres.

Você não deve armazenar dados binários no Git - especialmente no banco de dados.
Mudanças de código e alterações de banco de dados DML são coisas totalmente diferentes.

O MySQL e o Oracle podem gravar logs de arquivos para serem restaurados a qualquer momento. Basta fazer backup desses registros em algum lugar seguro e você ficará bem.

Usar o Git para fazer o backup desses "logs de arquivo" não faz sentido. Logs de arquivamento em ambientes de produção são bastante pesados e devem ser removidos após a realização de backups completos regulares. Também é inútil colocá-los no git - esses já são um repositório em algum sentido.