Quale è meglio per il backup del sito Web - rsync o git push

Eseguo 2 server Web LAMP presso diversi provider per scopi di ripristino di emergenza: un server live ad alta potenza e un server di backup a bassa potenza.

Attualmente sincronizzo tutti i dati dal server live al server di backup una volta ogni 4 ore.

Funziona bene, ma carica il sistema spike mentre rsync scopre quali file sono stati modificati.

Dal momento che tutti i siti web vivono anche in repository git, mi chiedo se una git push sarebbe una migliore tecnica di backup.

Dovrei includere la cartella dei caricamenti dal vivo nel repository git; e quindi il processo di backup sarebbe:

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

e quindi disporre di un hook post commit sul server di backup per effettuare il checkout ad ogni push.

Ogni sito Web ha dimensioni che vanno da 50 a 2 GB. Vorrei finire con circa 50 repository git separati.

È una soluzione "migliore" di rsync?

• Git è meglio nel calcolare quali file sono cambiati?
• Git push è più efficiente di rsync
• Cosa ho dimenticato?

Grazie!

---- Dati di alcuni test comparativi ------

1) cartella da 52 MB quindi aggiunta di una nuova cartella da 500k (principalmente file di testo)

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

idiota

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) cartella 1.4G quindi aggiunta di una nuova cartella 18M (principalmente immagini)

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

idiota

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) Cartella 52M quindi aggiunta di una nuova cartella 18M (principalmente immagini)

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

idiota

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) Cartella 1.4G quindi aggiunta di una nuova cartella 500k (principalmente testo)

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

idiota

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) Cartella 1.4G - nessuna modifica

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

idiota

nothing to commit (working directory clean)

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

5) Cartella 52M - nessuna modifica

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

idiota

nothing to commit (working directory clean)

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

In realtà suggerirei di utilizzare un mix bilanciato di entrambi. Il backup principale deve essere eseguito (almeno) ogni notte per eseguire il git. Sincronizzalo una o due volte a settimana su un altro computer che è tenuto lontano dalla scatola di produzione usando rsync.

Git ti aiuterà con il ripristino immediato e semplifica anche l'analisi dei dati grazie al fatto che il backup è aggiornato e ha un log delle modifiche. Dopo qualsiasi modifica sostanziale ai dati, puoi eseguire un commit e spingere per git manualmente e inserire il motivo nel log delle modifiche. Nel caso in cui git vada male, allora rsync verrà in soccorso, ma tieni presente che perderai comunque i dati a seconda della frequenza di rsync.

Regola empirica: quando si tratta di backup e disaster recovery, nulla può garantire un ripristino del 100%.

Rsync è uno strumento di sincronizzazione meraviglioso, ma ottieni molta più versatilità quando esegui Git sui server e quando aggiorni pusho pullaggiorni.

Devo tenere traccia e eseguire il backup dei contenuti generati dagli utenti sul nostro server. Il productionserver ha una copia del repository git e ogni notte aggiunge e memorizza automaticamente tutti i nuovi file tramite cron. Questi vengono modificati pushsul nostro server gitolite, che quindi utilizza gli hook per sincronizzare il resto dei server.

Poiché i server dispongono di copie del repository integrato, non solo si ottiene un'istantanea, ma informazioni dettagliate sulla cronologia che potrebbero salvarti facilmente se accadesse qualcosa al tuo server.

Penso che tu abbia una buona comprensione di ciò che entrambi offrono, cambierei semplicemente il tuo modo di pensare dai server che controllano / esportano la base di codice per avere solo i propri repository. Un altro pensiero è che potresti risincronizzare i tuoi file multimediali (hai detto 2 GB per alcuni di questi siti, il che mi fa pensare che ci siano molti tipi di file multimediali?) E non rintracciarli in Git.