How to back up a RedM server, and what you will wish you had backed up

Every RedM server owner has one of two stories: the night the database was lost and the server closed, or the night the database was lost and the backup from four hours earlier saved it. Which story you get is decided before anything goes wrong. This guide is what to back up, how to automate it on the Windows box most RedM servers run on, and the restore test that turns a folder of files into an actual backup.

What to back up, in order of how much it hurts to lose

1. The database. Characters, money, inventories, jobs, stashes, housing, every script's tables. Nothing else on this list matters if this is gone, and it is the one thing you cannot download again.
2. server.cfg. Start order, convars, ACE permissions, the licence key line. Rebuilding it from memory takes a day and produces a server that behaves slightly differently.
3. Configs inside resources. Every config.lua you edited. The scripts you can re-download; your job names, locations and prices you cannot.
4. Escrow licence files. Every escrowed resource holds a small .fxap file tied to your server key. Without it the script will not load, and fetching it again means another portal download per script.
5. txData. txAdmin's own settings, admins, schedules and bans live here.
6. The rest of resources. Convenient, not essential, as long as your Tebex account still exists.

The database: mysqldump on a schedule

mysqldump ships with MySQL and MariaDB and writes a plain SQL file you can restore anywhere. The command for a VORP database looks like this:

mysqldump -u backup_user -p"PASSWORD" --single-transaction --routines vorpcore > D:\backups\vorp-%DATE%.sql

Three rules make it a real backup rather than a file:

• It runs without you. Windows Task Scheduler, nightly, from a batch file. A backup you have to remember is a backup that stops after three weeks.
• It lands on a different disk, and ideally a different machine or cloud folder. The disk that fails is the disk the server is on.
• It keeps history. Seven daily copies at least. Corruption or a bad script update often goes unnoticed for days, and the only good copy is the one from before it.

Files: copy, do not zip in place

For server.cfg, txData and the resources folder, a nightly robocopy to the backup location with a dated folder name is enough:

robocopy "D:\server\txData" "E:\backups\%DATE%\txData" /MIR /R:1 /W:1

Exclude cache folders; they are large and rebuilt on start. Include the resources folder so the .fxap files and edited configs come along.

Doing it with one program

Server Controller (from $2.99/mo) is the above with a dashboard. It runs beside the server as a Windows program, not a resource, so there is no server.cfg change and it works with any framework. Scheduled mysqldump backups with retention and one-click restore, scheduled file backups with per-folder exclusions, Discord notifications when a backup runs or fails, hands-free txAdmin updates, and remote management from your home PC behind an auth key and IP whitelist. There is a free tier, and the paid tiers add the rest. We built it because our own backups were a batch file that stopped running one night and nobody noticed for a month.

The restore test

A backup nobody has restored from is a hope. Once, on a spare database, do this:

1. Create an empty database and restore last night's dump into it: mysql -u root -p vorp_test < vorp-yesterday.sql.
2. Count the characters table in both. They should match.
3. Point a test server at it and log in. If your character loads with the right money and inventory, the backup is real.

Then put a reminder in the calendar to do it again every few months. Scripts add tables, and a dump that skipped one is a dump you will not notice until the restore.

Before you update anything

The most common moment to need a backup is the minute after a script update. Take one first, every time. Scripts that run on Poggy Core (Free) back up every file they replace in poggy_core/update_backups/ before writing, and never touch your database beyond adding tables and columns, but the database dump from last night is still what you want in your hand before a restart.

What is not in the database

Two things people assume are backed up with the database and are not. Some scripts keep player data client-side in KVP, which lives on each player's machine and is not yours to back up; a script that saves presets that way says so. And container definitions on VORP live in memory only, which is why Poggy Storage (Free) registers every storage again on each start; the items are in the database, the definitions are in the config, and both need to be in the backup.