Backups on a 7 Days to Die server

A 7 Days to Die save is a folder, not a file. That is why so many copies turn out incomplete at the moment of restoring.

The save is a folder

World, player data and server settings sit in separate files. Copying only one gives a world with no players, or the reverse.

What usually destroys a world

A removed mod, a failed update and a process interrupted mid-write. Hardware failure is the rarest cause.

Why one copy is not enough

Damage is rarely noticed the same evening. A missing part of a base is found days later.

How many generations to keep

A week of daily copies and a month of weekly ones is enough. The saves are not large.

Where to store them

A copy on the same machine protects against mistakes, not against losing the machine. At least one belongs elsewhere.

Before every mod change

Removing a mod erases its blocks from bases. The copy taken beforehand is the only protection.

Before every update

A new version can change the save format. A copy beforehand is the cheapest insurance available.

Stop the server with a command

An interrupted write gives a file that opens but is missing part of the world.

Test the restore

A copy that has never been restored is an assumption. One attempt on a separate server shows whether the folder is complete.

Name copies with the date

A date and a short note make restoring fast.

Check the copies appear

A configured schedule and a working schedule are two different things.

Most of what precedes is a matter of organisation rather than technique: the decisions are made before you start, the backups have to actually run, and the rules are written while nothing has gone wrong yet. Our 7 Days to Die server hosting takes on the part there is no reason to do by hand — automatic backups, mod management and instant setup, along with a panel where settings, files, mods and restarts are handled without ever opening a command line.