O que é melhor para o backup do site - rsync ou git push

Question

Eu executo 2 servidores da Web LAMP em provedores diferentes para fins de recuperação de desastres - um servidor ativo de alta capacidade e um servidor de backup de baixa potência.

Atualmente rsync todos os dados do servidor ao vivo para 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 git push seria uma técnica de backup melhor.

Eu teria que incluir a pasta de uploads ao vivo no repositório do 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, ter um gancho post commit no servidor de backup para fazer o checkout em cada push.

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

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

• É melhor calcular 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, 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, adicionando uma nova pasta de 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, adicionando 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 de 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ção

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 52M - sem alteração

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

    

Answer 1

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

O Git irá ajudá-lo com a recuperação imediata e também torna a análise de dados mais fácil, devido ao fato de que o backup é versão-ed e possui um changelog. Depois de qualquer mudança importante nos dados, você pode fazer um commit e empurrar para o git manualmente e colocar o motivo no changelog. Caso o git seja ruim, o rsync virá para o resgate, mas tenha em mente que você ainda perderá dados dependendo da freqüência do rsync.

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

    

Answer 2

O Rsync é uma ferramenta de sincronização maravilhosa, mas você tem muito mais versatilidade ao executar o Git no (s) servidor (es) e push ing ou pull ing atualiza.

Eu tenho que rastrear e fazer backup do conteúdo gerado pelo usuário em nosso servidor. O servidor production tem uma cópia do repositório git e todas as noites ele adiciona automaticamente e confirma todos os novos arquivos via cron. Esses são push ed para o nosso servidor gitolite, que então usa ganchos para sincronizar o resto dos servidores.

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

Eu acho que você tem uma boa compreensão do que ambos oferecem, eu apenas mudei sua linha de pensamento dos servidores que verificam / exportam a base de código para apenas ter seus próprios repositórios. Outro pensamento é que você poderia rsync seus arquivos de mídia (você disse 2GB para alguns desses sites, o que me faz pensar que há um monte de tipo de mídia de arquivos?) E não rastreá-los no Git.