#summary Onsite and Offsite Backups

= Introduction =

You've probably heard this one: there are two types of people in the world -- those who have lost data and those who will.  Whether through mechanical failure, ISP going out of business, or corruption/accidental deletion of game files, the odds of your game experiencing some sort of need for some sort of restoration during its lifespan are nontrivial.  Whether, where, and how often you back up will determine whether your players lose a few hours, a few days, or a few years of their efforts -- the last case usually spells the end of a game.

Deciding on a backup strategy and setting it up to happen automatically takes less than an hour up front, but can save you countless hours of frustration when the inevitable happens.  This article is intended to give you a generic backup strategy that you can modify as your own particular needs/capacities require.

= Assumptions =

This article assumes you have installed PennMUSH on a linux server with the default options including gzip compression, and no use of "make customize".  If you've gone beyond the defaults, hopefully you're aware enough of the difference to modify the instructions below to adapt accordingly.

= Where to back up =

Your backup storage location is dependent on several factors, including your quota on your host, backup policies your host may provide (and that you trust), and any other server space you might have access to.  Backups fall in to two categories: onsite and offsite.

  * Onsite.  This refers to backing up your game files on the same server it runs on.  This is typically fast, easy, and provides for backups for most of the common needs, including file corruption, accidental deletion of objects on the game, attacks using softcode/hardcode bugs, etc.

  * Offsite.  In the event your game server becomes inaccessable/unrecoverable due to hardware failure, theft, you didn't pay your host provider's bill, or your server admin quits your staff in a snit and changes the password.  While these situations are more rare, having a database elsewhere that is more recent than last year can make the difference in a game's survival.

= When to back up =

  * You should always back up before (and after, presuming success) performing any significant manipulation of your game data such as switching patchlevels, switching between patches and subversion (svn), doing a lot of building/coding work on the game, performing major rewrite of help/theme/other game files, etc.

  * How often you back up is primarily a function of how often your game information changes and your level of comfort in recreating work.  A minimum suggested interval is a daily onsite backup and two times per month for off site backups.  Your needs may vary.

  * Backups work best when they are done automatically and you don't have to remember to do them.  This article will assist you in setting up automated daily on-site and semimonthly off-site backups.

= What to back up =

There is no need to save copies of the PennMUSH source code, compiled files, or temporary files.  Should the need arise you can always download new copies of the latest version.  What you're most interested in are the data files specific to your game.  These are:

  * Your current database.  All of the *db.gz files in the game/data directory.

  * Your text files.  All of the *.txt files in the game/txt directory.  Note that help.txt, news.txt, and events.txt are built by the code from files in the hlp, nws, and evt subdirectories.  You don't need these three files but if you have modified any of the files in the subdirectories you should copy those as well.

  * Your configuration files.  All of the *.cnf files in the game directory.  Possibly options.h and restart but these are easily rebuilt.

  * (Optional) Your log files.  Contents of the game/log (current) and game/save (previous) directories.

= The Big Picture  =

  # We'll set up a script to do an on-site backup.
  # We'll set up a cron job to execute this script daily.
  # Assuming we don't have unlimited quota, we'll only keep the last 2 days of daily backups.
  # Two times a month we'll copy the daily backup file somewhere else just in case the "worst case" happens.

= A backup script =