Qual é melhor para o backup de sites - rsync ou git push

Eu corro 2 servidores Web LAMP em diferentes fornecedores para fins de recuperação de desastre - um servidor ativo de alta potência e um servidor de backup de baixa potência.

Atualmente, sincronizo todos os dados do servidor ativo com o servidor de backup uma vez a cada 4 horas.

Isso funciona bem, mas aumenta a carga do sistema, enquanto o rsync descobre quais arquivos foram alterados.

Como todos os sites também vivem em repositórios git, estou pensando se um push git seria uma melhor técnica de backup.

Eu precisaria incluir a pasta de envios ao vivo no repositório git; e então o processo de backup seria:

live$ git add .
live$ git commit -a -m "{data-time} snapshot"
live$ git push backup live_branch

e, em seguida, instale um gancho de confirmação de postagem no servidor de backup para efetuar o checkout em cada envio.

Cada site varia em tamanho de 50M a 2GB. Eu acabaria com cerca de 50 repositórios Git separados.

Esta é uma solução "melhor" que o rsync?

• O git é melhor no cálculo de quais arquivos foram alterados?
• O git push é mais eficiente que o rsync
• O que eu esqueci?

Obrigado!

---- Dados de alguns testes de comparação ------

1) pasta de 52MB e, em seguida, adicionando uma nova pasta de 500k (principalmente arquivos de texto)

rsync

sent 1.47K bytes  received 285.91K bytes  
total size is 44.03M  speedup is 153.22

real    0m0.718s    user    0m0.044s    sys     0m0.084s

git

Counting objects: 38, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (37/37), 118.47 KiB, done.
Total 37 (delta 3), reused 0 (delta 0)

real    0m0.074s     user   0m0.029s    sys     0m0.045s

2) pasta 1.4G, em seguida, adicionando uma nova pasta 18M (principalmente imagens)

rsync

sent 3.65K bytes  received 18.90M bytes
total size is 1.42G  speedup is 75.17

real    0m5.311s    user    0m0.784s    sys     0m0.328s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.21 MiB/s, done.
Total 107 (delta 0), reused 0 (delta 0)

real    0m15.334s    user   0m5.202s    sys     0m1.040s

3) pasta 52M e depois adicionar uma nova pasta 18M (principalmente imagens)

rsync

sent 2.46K bytes  received 18.27M bytes  4.06M bytes/sec
total size is 62.38M  speedup is 3.41

real    0m4.124s    user    0m0.640s    sys     0m0.188s

git

Counting objects: 108, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (106/106), done.
Writing objects: 100% (107/107), 17.34 MiB | 5.43 MiB/s, done.
Total 107 (delta 1), reused 0 (delta 0)

real    0m6.990s    user    0m4.868s    sys     0m0.573s

4) pasta 1.4G, adicionando uma nova pasta 500k (principalmente texto)

rsync

sent 2.66K bytes  received 916.04K bytes  612.47K bytes/sec
total size is 1.42G  speedup is 1547.14

real    0m1.191s    user    0m0.180s    sys     0m0.268s

git

Counting objects: 49, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (48/48), done.
Writing objects: 100% (48/48), 177.90 KiB, done.
Total 48 (delta 3), reused 0 (delta 0)

real    0m1.776s    user    0m0.390s    sys     0m0.497s

5) pasta 1.4G - sem alterações

rsync

sent 1.72K bytes  received 716.44K bytes  287.26K bytes/sec
total size is 1.42G  speedup is 1979.18

real    0m1.092s    user    0m0.168s    sys     0m0.272s

git

nothing to commit (working directory clean)

real    0m0.636s    user    0m0.268s    sys     0m0.348s

5) pasta de 52 milhões - sem alterações

rsync

sent 528 bytes  received 88.40K bytes  59.29K bytes/sec
total size is 62.38M  speedup is 701.41

real    0m0.779s    user    0m0.044s    sys     0m0.144s

git

nothing to commit (working directory clean)

real    0m0.156s    user    0m0.057s    sys     0m0.097s

Na verdade, eu sugiro usar uma mistura equilibrada de ambos. Seu backup principal deve ser confirmado (pelo menos) todas as noites para o git. Sincronize uma ou duas vezes por semana com outra máquina que é mantida longe da caixa de produção usando o rsync.

O Git ajudará você na recuperação imediata e também facilitará a análise dos dados devido ao fato de que o backup é feito na versão e possui um registro de alterações. Após qualquer alteração importante nos dados, você pode fazer um commit e enviar push para o git manualmente e colocar o motivo no changelog. Caso o git fique ruim, o rsync será útil, mas lembre-se de que você ainda perderá dados, dependendo da frequência do rsync.

Regra prática: quando se trata de backups e recuperação de desastres, nada pode garantir uma recuperação de 100%.

Rsync é uma ferramenta de sincronização maravilhoso, mas você obter muito mais versatilidade ao executar Git no (s) servidor, e pushing ou pulling atualizações.

Eu tenho que rastrear e fazer backup de conteúdo gerado pelo usuário em nosso servidor. O productionservidor possui uma cópia do repositório git, e toda noite ele adiciona e confirma automaticamente todos os novos arquivos via cron. Esses são pusheditados em nosso servidor gitolite, que usa ganchos para sincronizar o restante dos servidores.

Como os servidores têm cópias do repositório a bordo, você obtém não apenas um instantâneo, mas também informações detalhadas sobre o histórico que poderiam salvá-lo facilmente se algo acontecesse ao seu servidor.

Eu acho que você tem um bom entendimento do que os dois oferecem, eu mudaria sua linha de pensamento, desde os servidores fazendo check-out / exportando a base de código para apenas tendo seus próprios repositórios. Outro pensamento é que você pode sincronizar novamente seus arquivos de mídia (você disse 2 GB para alguns desses sites, o que me faz pensar que existem muitos tipos de arquivos de mídia?) E não rastreá-los no Git.