Cuál es mejor para la copia de seguridad del sitio web: rsync o git push

Ejecuto 2 servidores web LAMP en diferentes proveedores para fines de recuperación ante desastres: un servidor en vivo de alta potencia y un servidor de respaldo de baja potencia.

Actualmente, sincronizo todos los datos del servidor en vivo al servidor de respaldo una vez cada 4 horas.

Esto funciona bien, pero aumenta la carga del sistema mientras que rsync descubre qué archivos han cambiado.

Dado que todos los sitios web también viven en repositorios git, me pregunto si un empuje git sería una mejor técnica de respaldo.

Tendría que incluir la carpeta de cargas en vivo en el repositorio de git; y luego el proceso de respaldo sería:

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

y luego tener un enlace de confirmación de envío en el servidor de respaldo para pagar en cada inserción.

Cada sitio web tiene un tamaño de 50M a 2GB. Terminaría con unos 50 repositorios de git separados.

¿Es esta una solución "mejor" que rsync?

• ¿Es git mejor para calcular qué archivos han cambiado?
• ¿Es git push más eficiente que rsync?
• Que he olvidado

¡Gracias!

---- Datos de algunas pruebas de comparación ----

1) carpeta de 52MB y luego agregar una nueva carpeta de 500k (principalmente archivos 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) Carpeta 1.4G y luego agregar una nueva carpeta 18M (principalmente imágenes)

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) Carpeta 52M y luego agregar una nueva carpeta 18M (principalmente imágenes)

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) Carpeta 1.4G y luego agregar una nueva carpeta 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) Carpeta 1.4G - sin cambios

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) Carpeta 52M - sin cambios

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 realidad, sugeriría usar una mezcla equilibrada de ambos. Su copia de seguridad principal debe ser comprometida (al menos) todas las noches a git. Sincronícelo una o dos veces por semana a otra máquina que se mantenga lejos de la caja de producción usando rsync.

Git lo ayudará con la recuperación inmediata y también facilita el análisis de datos debido al hecho de que su copia de seguridad está editada en versión y tiene un registro de cambios. Después de cualquier cambio importante en los datos, puede realizar una confirmación y presionar para git manualmente y poner el motivo en el registro de cambios. En caso de que git salga mal, rsync vendrá al rescate, pero tenga en cuenta que aún perderá datos dependiendo de la frecuencia de rsync.

Regla general: cuando se trata de copias de seguridad y recuperación ante desastres, nada puede garantizarle una recuperación del 100%.

Rsync es una herramienta de sincronización maravillosa, pero se obtiene una versatilidad mucho más cuando se ejecuta en el servidor Git (s), y el pushing o pulling actualizaciones.

Tengo que rastrear y respaldar el contenido generado por el usuario en nuestro servidor. El productionservidor tiene una copia del repositorio de git, y cada noche agrega y confirma automáticamente todos los archivos nuevos a través de cron. Esos son pusheditados a nuestro servidor gitolite, que luego usa ganchos para sincronizar el resto de los servidores.

Dado que los servidores tienen copias del repositorio a bordo, no solo obtiene una instantánea, sino también información detallada del historial que podría salvarlo fácilmente si algo le sucediera a su servidor.

Creo que tienes una buena comprensión de lo que ambos ofrecen, simplemente cambiaría tu forma de pensar de los servidores que verifican / exportan la base de código a tener sus propios repositorios. Otra idea es que podrías sincronizar tus archivos multimedia (dijiste 2 GB para algunos de estos sitios, lo que me hace pensar que hay muchos tipos de archivos multimedia) y no rastrearlos en Git.