Alternativas a Git para la copy de security del server Minecraft / control de versiones

Actualmente mi server de Minecraft, que reside en un server CentOS, usa Git como un medio de control de versiones y 'gestión de catástrofes'. Esto funciona muy bien excepto por dos cuestiones:

  1. Es grande. Como el server tiene un repository central, una twig principal (en la que se ejecuta realmente el server) y una twig de server de testing, cada uno de los cuales contiene cambios comprometidos completa el disco SSD sin finalización (utilizando aproximadamente 70 GB de los últimos 1,5 meses de uso) )

  2. Es lento. Después de tener tantos datos almacenados en el directory de objects, los commits, push y pull son lentos cuando intenta comprimir / descomprimir y analizar todos estos datos.

Estoy buscando una solución para hacer que Git sea más efectivo para esta aplicación o un reemploop. Estas son algunas de las razones por las que elegí usar Git:

  • Copias de security incrementales: no tengo que save todo el server comprimido de 8 GB comprimido / 2GB cada vez que quiero hacer una copy de security.
  • Restauración de recogida de cerezas: necesito poder restaurar ciertas partes del server fácilmente (como una configuration de complemento específica sin restaurar los cambios de las personas en los mundos principales)
  • Posibilidad de clonar el proyecto en computadoras caseras para realizar copys de security y testings externas
  • Posibilidad de hacer una twig para que un server de testing pruebe características inestables antes de implementarlas

Cuando solíamos utilizar una secuencia de commands tarballing bash precisa para hacer una copy de security del server, por lo general eliminamos las copys de security que tenían más de 2 semanas de antigüedad. Con copys de security incrementales, este período debería ser de un mes o más.

Si no está familiarizado con la estructura de Minecraft, se parece un poco a esto:

. |-- plugins |-- SomePlugin |-- config.yml |-- SomePlugin.jar |-- world |-- region |-- (binary files of chunks, a 2000x2000 world is often 1GB in size) |-- mcmmo_data (third party plugin) |-- x coordinate |-- y coordinate |-- small flatfile |-- level.dat |-- stuff.txt |-- properties.yml |-- server.jar 

¿Alguna idea a alguien?

Una opción que puede considerar, para almacenar los files binarys / grandes, es git-annex , que está diseñado para administrar objects grandes dentro de git. Te permitiría comprobar esos enormes files sin saturar la database central de git. Pero, requeriría un replanteamiento acerca de cómo meterse con esos files y dejarlos cambiar con el time. Tiene un buen componente push / pull / backup que probablemente funcionará bien, pero te encontrarás con otras "nuevas forms de pensar" con las que tendrás que lidiar. Pruébalo primero en un sistema de testing, por supuesto.