Alternatives to Git for Minecraft server backup/version control [closed]

Question

Currently my Minecraft server, residing on a CentOS server, uses Git as a means of version control and 'catastrophe-management'. This works very well except for two issues:

1. It's big. Because the server has a central repository, master branch (on which the server actually runs) and a test-server branch, each containing every committed change ever made fills the SSD up no-end (using approximately 70GB from the last 1.5 months of usage)

2. It's slow. After having so much data stored in the objects directory, commits, pushes and pulls are slow as it tries to compress/uncompress and parse all this data.

I'm looking for either a solution to make Git more effective for this application, or a replacement. Here are some of the reasons I chose to use Git:

• Incremental backups - I don't have to save the whole 8GB uncompressed/2GB compressed server each time I want to backup!
• Cherry-pick restoration - I need to be able to restore certain parts of the server easily (such as a specific plugin configuration without restoring people's changes to the main worlds)
• Ability to clone the project to home computers for offsite backup and testing
• Ability to make a branch for a testing server to try unstable features before rolling them out

When we used to use a precise tarballing bash script to backup the server, we usually removed backups that were more than 2 weeks old. With incremental backups, this period should be one month or greater.

If you're unfamiliar with Minecraft's structure, it goes a bit like this:

.
|-- 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

Any ideas anyone?

Answer 1

One option you might consider, in order to store the binary/large files, is git-annex, which is designed for managing large objects inside of git. It would let you check in those huge files without cluttering the central git database itself. But, it would require some rethinking about how you mess with those files and let them change over time. It does have a nice push/pull/backup component that would likely work well, but you'll run into other "new ways of thinking" that you'll need to deal with. Try it on a test system first, of course.