the advanced features of a MineOS setup

a brief overview of MineOS design rationale


An ideal server is compact, fully-featured, secure, and fast. I have tried to address all these components and provide my rationale for how it can improve your Minecraft setup. In fact, this distro can be set up in such a fashion that it runs rediculously faster than most minecraft servers--read to the end to find out how....


Running a Minecraft server directly on an existing Linux server has its advantages, such as:

On the other hand, there are many downsides:

MineOS addresses these issues by attempting to have the smallest possible memory footprint. Using all the settings in the guide, Windows7 VirtualBox overhead is approximately 36MB. Using features like VirtualBox headless mode, you can remove this unnecessary GUI memory cost, reclaiming megabytes and making the server cost equal to exactly what you allocate it.

The memory footprint of this operating system is approximately 50MB. That is, the totality of ALL features included in MineOS without a running world is 50MB--including HTTP/SSH/SCP/scheduling services. Compared to an existing server and adding minecraft, this might be considered unnecessary 'overlap', since your existing setup might already be providing these services.

On the other hand, if you're turning an old box sitting in your closet into a server, the best way to maximize its potential is by avoiding bloated operating systems such as Windows (IIS), or even regular mainstream Linux distros. These distros may be geared towards desktop use and has unnecessary bloat like Xfree86 (GUIs) that don't help servers.

In addition, with Minecraft's notorious server memory leaks, sharing resources with Minecraft may experience slowdown or downtime if Minecraft+Java consume all the available memory. By using a virtualized environment, you protect your memory so only Minecraft's jailed environment is affected by its leaks and bugs--and it may be restarted without affecting other services on your machine!

After all, MineOS is a server-distribution. Every part about it was designed to serve. Like all Linux distros, all the power of SSH is retained, and the unique server-manager web interface helps for the simple management of multiple worlds.

To further illustrate how little it requires to host a server, you can even use this distribution on a machine WITHOUT a keyboard, mouse or monitor--or even a hard drive!


Running Minecraft OS gives you every ounce of extendability that a regular Linux server offers. Setting up mods and plugins uses the same exact steps as any Linux/Minecraft setup and the admin web interface already supports the incredibly popular bukkit server mod right from the get-go.

Tons of scripts exist for updating your server jars and mods. As would be expected, this server does the same: with a simple click of a button, the Minecraft server and bukkit mods are downloaded and updated--no additional configuration necessary, and no need to leave your browser!

Dozens of scripts exist for backing up Minecraft worlds, as well. However, one problem that exists with these scripts is that each and every one simply archives your world and moves on. More sophisticated scripts go even farther and save backups for up to X days--so that you do not waste space on obsolete backups. Here, using a complete server solution like MineOS means you are not limited weak scripts for wasteful archive backups.

Incoming, a long-winded explanation of a superior backup method:

Incremental, differencing backups with rdiff-backup

Minecraft saves all its world data in a 'chunk'--a file containing all the information of a 16x16x128 volume of space. To see why differencing backups are superior, you must first consider how much of the world is actually affected by a player--or a group of players, in the case of SMP. Imagine the following scenarios:

  • In a brand new world, hundreds of chunks are generated immediately around the spawn. Directly around the a player, the server generates anything a player can see, such as blocks up to 160 spaces away, or 10 chunks out in every direction. So even if these chunks are not active in memory (saplings/trees dont grow & animals dont spawn), they must be generated. However, of the hundreds of chunks a player generates, a player only physically affects a miniscule percentage of them! Even when building your own house/mansion and its surrounding farmland, a player changes fewer chunks than you think...
  • If you build a square house that is 50 blocks x 50 blocks x [height], you only affect 16 chunks! Incidentally, just by existing and everywhere you run, the server generates 81+ chunks around you. Building your 50x50xh house, assuming you never left its borders--generated 441 chunks!

    Even if you ran around chopping down trees and digging dirt every 16 blocks, you're changing one chunk per few dozen that you generate...and even less when clay-surfing! Face it, most chunks in a world never get touched.

Now, if we accept that most of the world does not change in any significant manner, we can see how archiving worlds is an inefficient method. Even though 95%+ of the world (probably more) never changes, archival backups still process those chunks and take up space.

One of the largest backups I've seen came from redstonewire forums where the user claims the world is "344MB in raw form and 250MB compressed." This is one of the larger worlds I've heard reported, but using this as an example you can see how inefficient it is.

Each backup takes 250MB. Assuming one backup per DAY (and keeping only those up to 7 days old), that is 1750MB total. And backups can only be restored to precision of a day, no older than a week.

On the other hand, the backup method of rdiff (which uses rsync algorithm), mirrors the live data completely upfront: 344MB. And as chunks are modified, only the chunks that actually changed get backed up--but not just a direct copy, a difference copy at the KB level, saving insane amounts of space!

This means, you can have the backups at more regular frequency without waste. 344MB stays 344MB if you don't log in for a week. With archival backups, 1750MB will be occupied at all times.

For illustration, a gigantic 344MB world doesn't change 1% per day (probably not even .1%). But 344MB archived daily still takes 250MB. 1% per day difference-backed up takes about 3.4MB. Put another way, you can backup once a day (without deleting old backups) for over a year before you reach 1750MB. Or you can backup every hour for 17 days before you reach 1750MB. Or every half hour for over a week--and thats assuming 1% of the world is constantly changed every half hour! That's a lot of restore points!

Of course, these are all hypothetical approximations--but the point is clear: if the world changes little, only save the differences!

Oh yeah...and I realize that the average SMP server might even be closer to 75MB so "the space isn't a big deal"--but waste is waste--why have it? And also, see how this ties into the "ramdisk server"

Note: I am aware the actual/in-practice algorithm will work with different ratios, because rdiff doesnt actually backup by chunk--it backs up by smaller units, which ultimately saves even more space, but also one must include the accummulating cost of filesystem overhead and checksum saving. I also understand that difference backups involve a lot of processing work, but so does tar.gzip/bz2'ing. Ultimately, given the same backup timeframe, (daily/hourly/etc) I assert difference backups save way more space and provide greater backup protection.


Linux has a reputation for being secure. All the same could be said about this distribution and its deployment. How does Minecraft OS keep your system secure?

Most of MineOS's main deployment I expect to be virtualized. Because of this, no matter what hack or flaw or hole can be discovered against the Minecraft server, lighttpd webserver, ssh server, or any other app in this distro, a hacker never has access to more than just Minecraft and its world. Installing on a regular Windows/Linux machine potentially gives access to other production/confidential material on the server. This is strictly an advantage to virtualizing, and this is what the 50MB memory footprint pays for.

The model I have used to build this distribution is quite modular. This means, as often as I care or need to, I can re-distribute a brand new version of MineOS--a single download can directly replace the previous scripts and web-ui and will not require ANY reconfiguration/importing/etc. More, the ISOs are directly interchangeable. And, even more, if you choose to upgrade the packages manually, you can do so without affecting the web interface and scripts within.


Last but not least are speed concerns--probably the most noticable issue! This ties together all the parts.

Envision a Minecraft server with a 100MB world and 2048MB RAM allocated using:

java -Xmx2048M -Xms2048M -jar minecraft_server.jar nogui

A 100MB world is pretty large in general, but more importantly, 1948MB of RAM has only marginal difference from 2048MB. One possible setup of MineOS is full-RAMDISK. RAMDISK means that your world is loaded FULLY into RAM all the time. This means that when anybody joins the server or goes boating, all the chunk loads/dumps come from primary memory--which means these operations occur at the speed of the RAM! As is, when a player goes clay-surfing, the server must simultaneously generate dozens of new chunks per second, load existing chunks from disk, and unload/save/dump distant chunks from memory to disk. This cripples performance by being DISK I/O bottlenecked. A full-RAMDISK server means space is dedicated from RAM specifically for 'acting as a hard disk.' Therefore, when clay-surfing, the server can generate dozens of new chunks, load chunks from RAM, and save chunks to RAM--blazingly faster than the typical model.

But RAMDISK? Aren't those volatile?

Absolutely! But consider how often dedicated/virtual dedicated servers just breakdown and die. For a well managed server (and MineOS), not often at all. Uptime is just awesome. And more--by combining RAMDISK speeds with differencing backups, backup cycles can occur faster than ever! A setup can exist where a cronjob tells Minecraft to force-dump all chunks from RAMDISK every 15 minutes or 5. Then a difference backup can be made to a persistent storage to safeguard against failure and to permit server stops/reboots/etc. In other words, all server actions run at RAM speed all the time and has the benefit of being backed up and restorable to a precision of 5, 10, 15 minutes--which is already more frequent than the 24/12 hour backups common in archiving.

...And how nice it is to backup from a griefer with 15 minute precision rather than a whole day lost...

This is MineOS