Backing Up Configs, Bans and Stats Automatically

The files that make your server yours — the configs you tuned over months, your ban list, your admin roster, your stats database — are tiny, and almost nobody backs them up until the day a disk dies or a fat-fingered command wipes them. The game files you can re-download in minutes; the state you built up you cannot. This is a short, practical routine for backing up exactly what matters and nothing you do not need.

1. Know what is worth saving

Back up state, not the game install. The high-value files on a typical AMX Mod X server:

• cstrike/server.cfg, cstrike/mapcycle.txt, cstrike/motd.txt and any custom .cfg files — your tuning.
• cstrike/addons/amxmodx/configs/ — users.ini (admins), amxx.cfg, plugins.ini, maps.ini, plugin config files.
• Engine ban lists — cstrike/banned.cfg (SteamID bans) and cstrike/listip.cfg (IP bans).
• Stats: if you run CSStats/AMXX stats, the csstats.dat file; if you run a MySQL-backed system (AMXBans, a stats web panel), the database, not a file.
• Any custom maps you cannot re-download, and your FastDL mirror is worth a copy too.

You do not need to back up hlds_linux, the base valve/ and cstrike/ game assets, or compiled .amxx binaries you can rebuild from source.

2. Back up the flat files with a dated archive

A single tarball with the date in its name gives you versioned history for free. Put this in a script:

#!/bin/bash
# backup-cs.sh
SRC=/home/steam/hlds/cstrike
DST=/home/steam/backups
STAMP=$(date +%Y-%m-%d_%H%M)
mkdir -p "$DST"
tar czf "$DST/cs-config-$STAMP.tar.gz" \
  -C "$SRC" \
  server.cfg mapcycle.txt motd.txt \
  addons/amxmodx/configs \
  banned.cfg listip.cfg 2>/dev/null
# keep only the last 30 archives
ls -1t "$DST"/cs-config-*.tar.gz | tail -n +31 | xargs -r rm --

The last line is the part people forget: without pruning, dated backups fill the disk. Keeping the newest 30 gives you a month of daily history in a few megabytes.

3. Back up a MySQL stats/ban database properly

If your stats or bans live in MySQL (AMXBans, PsychoStats, a web panel), copying files is useless — you need a logical dump while the database is consistent:

mysqldump --single-transaction -u csbackup -p'PASSWORD' amxbans \
  | gzip > /home/steam/backups/amxbans-$(date +%Y-%m-%d).sql.gz

--single-transaction takes a consistent snapshot without locking the tables, so live play is not interrupted. Create a dedicated read-only backup user rather than dumping as root, and never put the password on a shared command line in production — use a ~/.my.cnf with 0600 permissions instead.

4. Schedule it with cron

Run the flat-file script nightly and the database dump nightly too. Edit the crontab for the game user:

crontab -e

# minute hour dom mon dow  command
30 5 * * *  /home/steam/hlds/backup-cs.sh
45 5 * * *  /home/steam/hlds/backup-db.sh

Pick an hour when the server is quiet. Make the scripts executable (chmod +x) and test them by hand once before trusting cron — a cron job that silently fails is worse than no backup, because it gives you false confidence.

5. Get the copies off the box

A backup on the same disk as the original dies with that disk. Push the archives to a second machine or object storage after each run. rsync over SSH is the simplest:

rsync -az --delete /home/steam/backups/ \
  [email protected]:/srv/cs-backups/

Set up SSH key auth so cron can run this without a password prompt. Now a full box loss costs you at most one day of bans and stats, and your carefully tuned configs are safe. This pairs naturally with an auto-restart supervisor: one keeps the server up, the other lets you rebuild it from scratch.

Common errors

• Backup archive is empty or tiny — the SRC path is wrong, or a listed file does not exist. Run the script by hand and read the tar errors instead of suppressing them.
• Stats \"restore\" does not work — you copied a live .dat or database files mid-write. Use mysqldump for SQL; for csstats.dat, back up while the server is stopped or accept a slightly stale copy.
• Cron job never runs — the script is not executable, uses a relative path that cron cannot resolve, or the crontab is under the wrong user. Cron runs with a minimal environment; use absolute paths everywhere.
• Disk full after a few weeks — no pruning. Cap the number of retained archives.
• Password leaked in process list — you passed -pPASSWORD on the command line, visible to ps. Use a protected .my.cnf.

Verification

A backup you have never restored is a guess. Prove it end to end: extract yesterday's archive into a scratch directory and confirm your users.ini and banned.cfg are intact and current.

mkdir /tmp/restore-test
tar xzf /home/steam/backups/cs-config-*.tar.gz -C /tmp/restore-test
ls -l /tmp/restore-test/addons/amxmodx/configs/users.ini

For the database, restore the dump into a throwaway schema and count the ban rows. Do this once when you set the system up, and you will trust it on the day you actually need it.