Quel est le meilleur pour la sauvegarde de sites Web - rsync ou git push

J'exécute 2 serveurs Web LAMP chez différents fournisseurs à des fins de reprise après sinistre - un serveur live haute puissance et un serveur de sauvegarde basse puissance.

Actuellement, je rsync toutes les données du serveur en direct vers le serveur de sauvegarde une fois toutes les 4 heures.

Cela fonctionne bien, mais augmente le chargement du système pendant que rsync détermine quels fichiers ont changé.

Étant donné que tous les sites Web vivent également dans des référentiels git, je me demande si une poussée git serait une meilleure technique de sauvegarde.

Je devrais inclure le dossier de téléchargement en direct dans le dépôt git; puis le processus de sauvegarde serait:

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

puis avoir un hook post commit sur le serveur de sauvegarde pour passer à la caisse à chaque push.

La taille de chaque site Web varie de 50 M à 2 Go. Je me retrouverais avec environ 50 git repos distincts.

Est-ce une "meilleure" solution que rsync?

• Git est-il meilleur pour calculer quels fichiers ont changé?
• Git push est-il plus efficace que rsync
• Qu'ai-je oublié?

Merci!

---- Données de certains tests de comparaison ------

1) dossier de 52 Mo, puis ajout d'un nouveau dossier de 500 Ko (principalement des fichiers texte)

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) Dossier 1.4G puis ajout d'un nouveau dossier 18M (principalement des images)

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) Dossier 52M puis ajout d'un nouveau dossier 18M (principalement des images)

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) Dossier 1.4G puis ajout d'un nouveau dossier 500k (principalement du texte)

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) Dossier 1.4G - pas de changement

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) Dossier 52M - aucun changement

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

En fait, je suggère d'utiliser un mélange équilibré des deux. Votre sauvegarde principale doit être validée (au moins) chaque nuit pour git. Synchronisez-le une ou deux fois par semaine sur une autre machine éloignée de la boîte de production à l'aide de rsync.

Git vous aidera à une récupération immédiate et il facilite également l'analyse des données en raison du fait que votre sauvegarde est éditée en version et possède un journal des modifications. Après toute modification majeure des données, vous pouvez faire un commit et pousser pour git manuellement et mettre la raison dans le changelog. Dans le cas où git tourne mal, rsync viendra à la rescousse, mais gardez à l'esprit que vous perdrez toujours des données en fonction de la fréquence de rsync.

Règle générale: en ce qui concerne les sauvegardes et la reprise après sinistre, rien ne peut garantir une restauration à 100%.

Rsync est un merveilleux outil de synchronisation, mais vous obtenez beaucoup plus de polyvalence lors de l' exécution Git sur le serveur (s), et pushING ou pulling mises à jour.

Je dois suivre et sauvegarder le contenu généré par les utilisateurs sur notre serveur. Le productionserveur a une copie du dépôt git, et chaque nuit il ajoute et valide automatiquement tous les nouveaux fichiers via cron. Ceux-ci sont pushédités sur notre serveur gitolite, qui utilise ensuite des crochets pour synchroniser le reste des serveurs.

Étant donné que les serveurs ont des copies du dépôt à bord, vous obtenez non seulement un instantané, mais des informations d'historique détaillées qui pourraient facilement vous sauver si quelque chose arrivait à votre serveur.

Je pense que vous avez à peu près une bonne compréhension de ce que les deux offrent, je changerais simplement votre façon de penser des serveurs vérifiant / exportant la base de code pour avoir simplement leurs propres dépôts. Une autre pensée est que vous pouvez resynchroniser vos fichiers multimédias (vous avez dit 2 Go pour certains de ces sites, ce qui me fait penser qu'il y a beaucoup de types de fichiers multimédias?) Et ne pas les suivre dans Git.