The 3-2-1 backup rule: a simple plan that protects your data

People usually discover whether their backups work on the worst day: after a corrupted world, a deleted database or a failed disk. The 3-2-1 rule is a short, well-known plan that avoids most backup disasters. It is easy to remember and works for a hobby Minecraft world as well as a business website.

The rule

• 3 copies of your data: the original plus two backups.
• 2 different kinds of storage, so one failure type cannot take out everything.
• 1 copy stored off site, away from the original.

That is all. Each part guards against a different failure.

Why each part matters

Three copies. One backup can be damaged or forgotten. With two backups, a single bad copy does not leave you stranded.

Two kinds of storage. If both copies sit on the same disk, or the same type of device, one fault kills both. Using, for example, your server's disk plus a download to your computer, or an object storage service, spreads the risk.

One off site. Fire, theft, a provider incident, an account compromise or a mistaken "delete everything" can destroy everything in one location. A copy elsewhere survives. For server owners, "elsewhere" means a different provider or your own computer, not another folder on the same machine.

What counts as a backup

A real backup is separate from the thing it protects and can be restored. These are not backups:

• A copy in the same folder. Deleting the folder deletes both.
• A mirror that syncs deletions. If a file is removed or encrypted by an attacker, the sync copies the damage.
• RAID. It protects against a disk failing, not against mistakes, corruption or ransomware.
• A snapshot on the same host, which is helpful, but it shares the host's fate.

Applying it to a game server

Suppose you run a Minecraft world.

1. Copy 1: the live world on the server.
2. Copy 2: scheduled backups from the panel, kept on the server's storage. See Creating and restoring backups.
3. Copy 3: a download to your own computer, or cloud storage, weekly. Do this before big changes such as updating the version or installing mods.

Now you have three copies, two places (the server and your computer) and one off site. Restoring is covered in Upload a Minecraft world, and corruption recovery in How to repair a corrupted Minecraft world.

Applying it to a VPS

1. Copy 1: your live application and database.
2. Copy 2: nightly dumps and archives on the same VPS in a backup folder, for quick restores.
3. Copy 3: a copy pushed to a different provider or machine, with rsync over SSH.

Include these items:

• Application files and uploads
• Database dumps (see MariaDB or PostgreSQL)
• Configuration files, such as /etc/nginx and service files
• Environment files and keys, stored securely

Applying it to a bot

For a Discord bot, your code should live in version control, which is already a copy. Back up the data that changes: its database and any uploaded files. Keep tokens out of the repository and stored separately. See Environment variables and keeping your bot token safe.

Make it automatic

A backup that depends on you remembering will stop being made. Schedule it. On Linux, cron is the standard tool, and the panel has its own scheduler for game servers, as in Schedule automatic restarts and backups.

Test your restores

The most important step is also the one people skip. A backup you have never restored is only a hope. Every few months:

1. Restore to a different location or a test server.
2. Open the files, start the world, or import the database.
3. Check the data is complete and recent.
4. Note how long it took, so you know what to expect in an emergency.

Protect the backups too

• Encrypt sensitive backups before sending them off site.
• Restrict access. A backup account should not be able to delete older backups if the main server is compromised. Where possible, use credentials that can only add data.
• Keep history. Retain several generations, such as daily for a week and weekly for a month, so you can go back before a problem began. Silent corruption can sit unnoticed for days.
• Watch the size. Backups consume space. See Fixing "No space left on device".

A simple schedule

Data	How often	Keep
Game world	Daily	7 days
World, off site	Weekly	4 weeks
Database dump	Daily	14 days
Config files	After each change	Latest 10

Adjust it for how much work you can afford to lose. Ask yourself: if the server vanished right now, how many hours of progress could I lose? Back up at least that often.

Summary

Three copies, two kinds of storage, one off site, automated and tested. It takes an afternoon to set up and can save months of work.

---

Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.