Eu quero automatizar o backup dos meus bancos de dados e arquivos com o cron. Devo adicionar as seguintes linhas ao crontab?
mysqldump -u root -pPASSWORD database_name | gzip > /home/backup/database_'date +\%m-\%d-\%Y'.sql.gz
svn commit -m "Committing the working copy containing the database dump"
Em primeiro lugar, essa é uma boa abordagem?
Não está claro como especificar o repositório e a cópia de trabalho com svn?
Como posso executar o svn somente quando o mysqldump é feito e não antes? Evitando conflitos
1) Se você insistir em armazenar backups na subversão, então não há nada de errado com essa abordagem. É estranho, no entanto.
2) Você deve manter um check-out, colocar o despejo no diretório de trabalho e executar svn update e svn add conforme apropriado antes de confirmar.
3) Se você executar os comandos conforme mostrado em um script de shell, não deverá haver sobreposição.
Observe também que a compactação da saída do mysql criará binários muito diferentes e fará com que seus requisitos de disco de repositório se propaguem. Pode levar mais espaço inicial com o sql descompactado, mas os diffs de texto serão armazenados de forma muito mais eficiente no repositório. Também não há necessidade de armazenar cada um como um arquivo separado com a data no nome. Pode também ser o mesmo arquivo, pois o controle de versão permitirá que você volte o relógio.
Eu prefiro muito mais os backups com algo como os últimos 7 dias do sql zipado e depois os snapshots com uma semana de intervalo, voltando um mês ou dois. Não vejo necessidade de controlar o banco de dados por toda a eternidade.
Como eu disse, salvar o banco de dados em um repositório SVN não é uma boa prática.
Em relação ao mysqldump, tenha em mente que desta forma você também está incluindo estas opções (--opt é o padrão que é um atalho do abaixo):
--add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset
Então, se você usar o despejo completo que você criou, você sobrescreverá todos os dados inseridos após o último backup realizado.
Até que seu DB seja tão pequeno quanto você disse, aconselho você a fazer um backup com mais frequência.
Este é um bom exemplo de como você pode prosseguir.
Se o seu banco de dados for grande, armazenar centenas de cópias de um banco de dados irá exceder sua capacidade de armazenamento, provavelmente pegando você despreparado e ocupado com outra coisa. A compactação gzip quase certamente prejudicará, já que isso impede que a capacidade do SVN de compactar entre as revisões , e eu acho O SVN já usa uma biblioteca zip internamente. Você pode levar alguns dias de backups e experimentá-los nos dois sentidos e ver qual deles usa menos disco. Provavelmente também será útil ordenar o dump de alguma forma, como com - ordem por primária ; caso contrário, o SVN terá que desperdiçar disco representando reordenações frívolas do mysqldump, com as quais você não se importa.
Mas, eventualmente, você simplesmente precisa descartar os dados. Uma abordagem interessante que vi foi pelo nome de "backups logarítmicos". A ideia é que os backups mais recentes sejam mais importantes do que os backups mais antigos, para que você salve mais e expire a maioria deles à medida que envelhecem. Então você acaba com
Esta é uma abordagem semelhante à ferramenta RRD , na qual os dados são consolidados em um representante objeto. Você acaba com mais de 20 backups e a capacidade de recuperar dados de curta duração do passado recente e dados de longa duração de um passado distante.
Na verdade, respondendo à pergunta
Como seus dados são relativamente pequenos e provavelmente não mudam muito, o SVN pode não ser uma abordagem ruim.
Eu tenho um processo semelhante para colocar sites de interesse no SVN, que eu modifiquei para atender às suas necessidades. Coloque isso em seu cron.daily ou whereever, e você vai conseguir terminar. Você precisará inicializar o repositório primeiro e ajustá-lo para atender às suas necessidades, mas este é um bom começo:
#!/bin/bash
# check out to temp dir
DIR='mktemp -d'
cd $DIR
# check out repository
svn co $1 .
# dump db
mysqldump --order-by-primary -u root -pPASSWORD database_name
# if changed, commit
svn commit -m 'Nightly backup'
cd ..
rm -rf $DIR
Descarregando seu banco de dados para um arquivo e o commit do arquivo para o svn é uma boa abordagem. Há um par de coisas que eu recomendo mudar embora ... Você deve substituir o mesmo arquivo toda vez que você despejar (remover a data do nome do arquivo) e remover o zip.
Assim como editar seu código-fonte, você está essencialmente modificando o arquivo de despejo do banco de dados. Além disso, como alguém mencionou, se você não compactar, a longo prazo ele será compactado muito melhor no servidor porque os diffs serão muito menores.
A grande parte desta abordagem é que ela liga o banco de dados ao código em um determinado momento. Por exemplo, você precisa executar a revisão 1428. Não há problema ... atualize seu repositório local para rev 1428 e você terá todo o código e o despejo de banco de dados que é executado com 1428. Carregue esse despejo, compile seu código e você estará nos negócios.