The Mud ConnectorContentsSite MapListingsContactDiscuss

Backups 101
by Alan Lenton (email: ) November 17, 2005

Do you run a MUD?

Yes? Then have you thought about what you are going to do if something goes wrong and you lose all the data? Recently, a number of high profile losses of player data in other MUDs have prompted some players to ask how safe their data is.

If you run a MUD, then you need to think about this, even if you only have a relatively small number of players. Your players have put time and effort into playing your game - it's your side of the bargain that you take steps to look after their character and other data.

There are a number of different backup strategies, and they work best if you mix and match, so that you have more than one backup strategy in place at any one time. At ibgames we use a three tier system for our Federation II game. Fortunately, we haven't needed the backups yet, but you never can tell when you might need it!

Our first line of defence is to have the production machine use a RAID disk set. For those of you who are unfamiliar with RAID, there are two separate hard drives, each capable of providing a copy of the data, so that if one drive fails the other drive can continue without interruption. If a drive becomes faulty it can be replaced, and a replacement image of the data is built on the new drive from the existing drive. You can get a RAID hardware controller, or you can implement RAID in software - but I would recommend using hardware RAID if at all possible.

This system, of course, doesn't cope with someone inadvertently, or maliciously, deleting the data. For that we have a set of regular backups. The primary backup is done at the daily 8.00am EST reset. It is, in fact, one of the main reasons for the reset. We take the game down so we can safely copy the player database for backup purposes.

At reset a copy of the player records, the player planet files, and all the associated data is made to a backup directory. This means that if something goes wrong with the files, we can restore the system to what it was at the last reset (i.e. a maximum of 24 hrs earlier).

Once a week (after the Sunday reset) the backup files are copied over to a different server in the same rack, so that if both the RAID drives on the Fed II server fail we can restore everything to the state it was after the last Sunday reset. In this case the backup server also uses RAID drives. The two servers are located in Parsippany, New Jersey, USA.

Finally, once a month, usually on the first weekday of the month, the backups are downloaded to the computer used to develop Fed II, which is in London. From there two sets of CDs are cut and kept in two different sites - one in East London, and one in West London in England. So, if the Parsippany data centre is destroyed by unseasonable weather, we can reconstruct on new servers everything that was on the production server at the start of the month.

Of course, if a nuclear strike were to simultaneously take out all of London and New Jersey, we would be screwed. But in that case I suspect players would have things other than losing their Federation II characters on their minds!

It may seem trivial to a person who runs a MUD to ask the players to re-start the game. I can assure you that your players won't look at it from that point of view. As far as they are concerned your carelessness has destroyed months of their hard work, and it will permanently sour the relationship between you and your players.

So - backup regularly. As the seat-belt ads, say 'You know it makes sense!'

Comments / Discussions about this Article

is an on-line games designer, programmer and sociologist. He is the Creative Director at ibgames.

This work is licensed under the Creative Commons Attribution-NoDerivs License. To view a copy of this license, visit or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

The Mud ConnectorContentsSite MapListingsContactDiscuss

Privacy Policy | Report Inappropriate Material | Terms of Service
The Mud Connector: copyright © 1994 - 2008 by . Graphical design created by Steve Sicherman.