Backups and updates

Copies of the world

Back up now makes one immediately. While it is being made the server stops saving the world automatically, so that the archive is a whole world rather than half of two.

Copies can also be made on a schedule — every so many minutes, keeping so many of them — on Install and run.

Restore selected puts a copy back. The world that is there now is not deleted: it is renamed to world_before_restore and the date. If the copy turns out to be the wrong one, nothing has been lost.

Changing the core

Update the server core installs the version you choose and leaves the world where it is.

Create the server again is the same installation, but the world starts from nothing. The old one is not deleted either — it is renamed to world_before and the date, together with the nether and the end.

The order of steps is chosen so that a failure is harmless. The file is downloaded onto the server itself, not through your home connection, and checked against its checksum. Only then is the server stopped. The old core is renamed to its own name with the date and .bak, so going back is one move.

The state of the service is read again immediately before the swap rather than taken from the screen — otherwise the file could be replaced under a running server and reported as done while the old code was still going. A server that was stopped before stays stopped. If it does not come back up, the program says so and names the file to roll back to.

The version is read from the core itself, from the version.json inside the jar. That is the one answer that does not go stale: the log is rotated at midnight and loses the line, a note from the last installation lies if the file was swapped by hand, but the file is always the one that will actually start.

Which cores can be updated

Mojang, Paper and Fabric. All three publish a finished file at a direct link, so it can be downloaded and put in place. With Fabric it is not an installer but a small server starter that fetches the rest on the first start; mods in the folder are left alone when the loader version changes.

Forge cannot, and for a reason worth knowing. Since 1.17 a Forge server is started not by a jar but by a list of arguments whose path contains the Forge version. Updating it changes the command line in the service file, and that file belongs to root. It is not a difficulty with temporary files — it is that after the update the server has to be started differently.

The panel itself

The program looks for a newer version on its own and shows a strip when there is one, with what is new in it. Update installs it and restarts; Later leaves it alone until next time.