A server holds two things worth keeping: the databases and the settings file. Everything else comes back out of a release archive.
On Windows, GoMMO Manager Does This
On an RF Online server run from GoMMO Manager, press Backups. It copies every database in db/ into backups/<date>_<reason>/ while the servers keep running, takes one by itself every 24 hours while the game server runs, keeps the newest 10, and restores one with the servers stopped. On MySQL it runs mysqldump for you when the MySQL client tools are installed. It does not copy settings/: keep a copy of that yourself whenever you change it.
The rest of this page is what to do anywhere else.
What to Copy
| Path | Holds | Losing it means |
|---|---|---|
db/ | Accounts, characters, everything players did | Starting over |
settings.ini | Database credentials, ports, keys | Reconfiguring by hand |
logs/ | Nothing you need | Nothing |
server/, tools/, client/ | Program files | Re-download the release |
On MySQL the databases are not in db/. Back them up with mysqldump instead:
mysqldump --single-transaction --databases gommo_accounts gommo_<game> > backup.sql--single-transaction is what makes the dump consistent without locking players out.
How Often
Once a day is enough for most servers. A backup is worth what you would lose between it and the failure, so a busy server wants more.
Keep more than one. A backup taken after the corruption is a copy of the corruption.
Prove It Works
An untested backup is a guess. Restore one into a scratch directory and start the server against it:
- Copy the backup somewhere else.
- Point a second copy of
settings.iniat it, on a different port. - Start the server and sign in.
Do this once when you set backups up, and again whenever you change the database backend. Most backup failures are discovered during the restore that was supposed to fix something else.
Before an Upgrade
Take one. A release can change the schema, and the change is not reversible by downgrading.