2024-06-06 09:54:26 +02:00
|
|
|
---
|
|
|
|
|
title: "Alex"
|
|
|
|
|
summary: "Minecraft server wrapper that automates world backups"
|
|
|
|
|
type: "project"
|
2024-06-06 10:24:56 +02:00
|
|
|
params:
|
|
|
|
|
links:
|
|
|
|
|
- name: Source
|
|
|
|
|
url: 'https://git.rustybever.be/Chewing_Bever/alex'
|
2024-06-06 09:54:26 +02:00
|
|
|
---
|
|
|
|
|
|
2024-06-06 17:07:01 +02:00
|
|
|
Alex was created to solve an issue I'd been having: inconcistent Minecraft
|
|
|
|
|
server backups.
|
2024-06-06 09:54:26 +02:00
|
|
|
|
2024-06-06 17:07:01 +02:00
|
|
|
My original backup system involved compressing the server world and config
|
|
|
|
|
directories in a tarball. While this usually worked, the command regularly
|
|
|
|
|
failed due to conflicts while reading a file the server was writing to. Because
|
|
|
|
|
the Minecraft server is unaware of the fact it's being backed up, it
|
|
|
|
|
continuously writes data to disk, preventing the tar command from doing its
|
|
|
|
|
job.
|
|
|
|
|
|
|
|
|
|
My solution for this consisted of designing a process that wraps the Minecraft
|
|
|
|
|
server process and interacts with its standard input. The Minecraft server
|
|
|
|
|
accepts certain commands (`save-all` and `save-on`/`save-off`) that allow an
|
|
|
|
|
admin to control when and if the server writes data to disk. Using this, the
|
|
|
|
|
wrapper process tells the server to flush all data, stop writing to disk, and
|
|
|
|
|
only resume writing after a successful backup has been created.
|
|
|
|
|
|
|
|
|
|
This idea was then expanded to implement incremental backups, which greatly
|
|
|
|
|
reduced the time and disk size needed for the backups. For reference, our
|
|
|
|
|
~2.5GB world folder can be backed up incrementally in less than 5 seconds, with
|
|
|
|
|
backups running every thirty minutes, without ever turning off the server.
|
