How to build a disaster recovery (DR) plan for your MU server

Every MU Online administrator who has been in the field long enough has a horror story: the VPS that died without warning, the database that corrupted after an update, the provider that suspended the account, the disk that failed and took down the backup that was also on it. In moments like these, what separates a scare from the end of a project is a single thing: the existence, tested and within reach, of a disaster recovery plan. This tutorial shows how to build a real DR plan for an MU server — not a backup folder you pray you never have to open, but a procedure with clear goals, layered redundancy, a recovery path, and, most importantly, tests that prove it works. The figures, providers, and times cited are examples and vary by provider/version of your infrastructure.

Prerequisites

DR presupposes something to protect: a production server with data that hurts to lose. If you are still building the base, start with how to create an MU Online server and come back to harden it. For a serious DR plan you need:

• A complete inventory of what makes up the server: database, GameServer configuration files, site/panel, launcher, and the customizations that are not in the database (spots, drops, events edited in files).
• Backups already working — DR organizes and tests them, but they must exist. If you do not yet have a backup routine, that is the foundation and comes before everything else.
• A second storage location independent of the main server: cloud, another data center, a physical machine of your own. The golden rule is that the backup copy cannot die together with the original.
• A business decision about RTO and RPO (how much time offline and how much lost data you tolerate). Without it, you do not know how much to invest.
• Access to a replacement VPS or machine for the restore tests — restoring on top of the production server is forbidden.

Step 1 — Define RTO and RPO (the plan's goals)

Before any technology, define two goals, because they dictate everything else in the plan:

• RTO (Recovery Time Objective): the maximum acceptable time the server can be offline after a disaster. It answers "it went down — in how long does it need to come back?".
• RPO (Recovery Point Objective): the maximum acceptable data loss. It answers "how far back can the data that survives be?". An RPO of 6 hours means accepting the loss of up to 6 hours of the players' progress.

These are business decisions, not technical ones. The table below shows typical MU server profiles and plausible goals — all examples, they vary by provider/version and by the project's risk appetite:

The RTO and RPO you choose determine the cost. Coming back in 15 minutes requires a second server running; coming back in a day requires only backups and a good procedure. There is no universal "right" DR — there is the DR appropriate to the goals the project can and wants to pay for.

Step 2 — Map the assets and classify by criticality

You cannot recover what you do not know exists. Take a complete inventory of the server and classify each asset by criticality and by its own RPO:

## Asset inventory (example — varies by provider/version)

CRITICAL (short RPO — losing it hurts a lot):
- SQL database (accounts, characters, inventory, guilds)
- GameServer configs NOT in the database:
    Data\Monster\ (custom spots and drops)
    Data\Item\ (edited item attributes)
    .ini/.txt files for custom events

IMPORTANT (medium RPO — recreatable with effort):
- Website/web panel and its database
- Launcher and client patch files
- Automation scripts (D:\Scripts\)

RECREATABLE (long RPO — can be rebuilt from the installer):
- Emulator binaries (GameServer.exe, ConnectServer.exe...)
- Runtime, dependencies, base client

This classification is the heart of DR. The database is irreplaceable and needs the most frequent backup. The emulator binaries, on the other hand, you can re-obtain from the installer, so they do not need constant backup — but they do need to be documented for the rebuild. The classic mistake is treating everything the same: either you over-protect recreatable binaries, or (worse) you under-protect the file-based configs, thinking that "the database backup covers everything."

Step 3 — Build layered backups (the 3-2-1 rule)

With the assets mapped, structure the backups following the 3-2-1 rule, the industry standard for resilience:

• 3 copies of the data (the original + 2 backups).
• 2 different media/locations (e.g.: local disk + cloud).
• 1 copy offsite, immune to a physical disaster at the data center.

In practice, for an MU server:

## Backup layers (example — varies by provider/version)

Layer 1 — Local, fast (for common restores):
- SQL database backup every 6h on a disk separate from the database
- Retention: 3 days

Layer 2 — Cloud, offsite (for a VPS disaster):
- Daily upload of the backup to cloud storage
- Includes: database + Data\ folder + site configs
- Layered retention: 7 daily, 4 weekly, 6 monthly

Layer 3 — Cold copy, independent of the provider:
- Weekly copy to another provider or a physical machine of yours
- Protects against: the provider suspending/losing the account

Layer 3 is the one many people skip and is precisely the one that saves you in the "the provider disappeared with my account" scenario. Keeping everything with a single cloud provider means one account suspension wipes out original and backup at once. Distribute the risk.

Step 4 — Choose the contingency strategy according to the RTO

A backup answers "did the data survive?". Contingency answers "where does it come back to run?". The choice depends on the RTO defined in Step 1:

1. Manual rebuild (loose RTO, hours to a day): you have a documented procedure to build a new server from scratch on a replacement VPS, restore the database and the configs, point the DNS, and go live. Cheaper, slower. It requires the procedure to be written and tested.
2. Pre-configured replacement VPS (medium RTO, 1-4 h): a second VPS with the emulator already installed and configured, waiting. In a disaster, you just restore the most recent backup and go live. It costs an idle VPS, but it cuts hours off the RTO.
3. Standby server with replication (short RTO, minutes): a second server that receives frequent copies of the database and can take over quickly. It is the most expensive and complex, justifiable only for large servers with revenue that downtime compromises.

For most medium-sized MU servers, option 2 is the cost-benefit sweet spot: a cheap replacement VPS, kept up to date, turns a full-day disaster into one of a few hours.

Step 5 — Write the failover procedure

The plan needs a step-by-step recovery procedure, written to be followed under stress. Example for the "main VPS died, recover on the replacement VPS" scenario:

### DR-01 — Full recovery on the replacement VPS

**Trigger:** main VPS inaccessible with no expectation of return.

**Goal:** RTO 3h, RPO 6h (example).

**Steps:**
1. Confirm the main one is really lost (not a passing outage).
   Notify the community that there is emergency maintenance.
2. Access the replacement VPS (credentials in vault X).
3. Download the most recent backup of the database + Data\ folder from the cloud.
4. Restore the database on the replacement VPS's SQL (see DR-02).
5. Copy the restored Data\ folder to the GameServer.
6. Check the connection configs (internal IPs, ports).
7. Bring the components up in order: database > DataServer >
   ConnectServer > JoinServer > GameServer.
8. Update the DNS/IP to point to the replacement VPS.
9. Test login with a test account; validate that the character loads.
10. Announce the return to the community.

**If the most recent backup fails:** use the previous one (loses more RPO).
**Escalate to:** the project owner if it exceeds 3h.

Step 1 (confirming it is a real disaster) avoids the costly mistake of starting a failover over a 10-minute outage that would have resolved on its own. Step 3 and step 4 are where most untested plans fail — which is why the next step is the most important of all.

Step 6 — Test the plan (the DR drill)

An untested DR plan is a document of hope. The test, the drill, is what reveals the holes before the disaster reveals them for you. Do it periodically:

1. Isolated restore test (monthly): restore the most recent backup in a separate environment — never in production — and confirm that the database mounts, the characters load, and the configs are present. Time it.
2. Full failover drill (quarterly): execute the entire DR-01 procedure on the replacement VPS, from scratch, following only the text of the plan. Time it and compare with the target RTO. Every hesitation is a hole to fix.
3. Worst-case test (semiannual): simulate the "provider disappeared" scenario: recover using only backup layer 3, the independent cold copy. It is the test that validates whether you truly survive the loss of the entire provider.

Record the results of each drill: real time vs. target RTO, what failed, what was missing from the plan. DR is not a document you write once — it is a cycle of testing, finding holes, and fixing them, one that only matures with repetition.

Common errors and fixes

The database-only backup error is especially cruel because it gives a false sense of safety: you have "the backup," you restore, the characters are there — and only then do you realize that months of drop and event configuration, which lived in files, are lost. A DR backup is of the entire server, not just the character table.

Release checklist

• RTO and RPO defined as a business decision and documented
• Complete asset inventory, classified by criticality
• Data\ folder and file-based configs included in the backup (not just the database)
• Layered backups following the 3-2-1 rule
• At least one offsite copy, independent of the main provider
• Cold copy on a separate provider/location (the "provider disappeared" scenario)
• Contingency strategy chosen according to the RTO (rebuild, replacement, or standby)
• Failover procedure (DR-01) written, with numbered steps and times
• Database restore procedure (DR-02) written and validated
• Recovery credentials kept in a vault accessible to the team
• Isolated restore test executed and timed
• Full failover drill executed, compared to the target RTO
• Worst-case test (cold copy only) executed at least once
• Drill results recorded and holes fixed
• Recurring test calendar defined (monthly/quarterly/semiannual)

With a real, tested, layered DR plan, your MU server stops being one failed disk away from the end. The disaster that takes down unprepared servers becomes, for you, a timed procedure with a predictable outcome. It is the invisible work nobody praises while everything works — and the only one that matters on the day everything stops.

Frequently asked questions