Automating FiveM Server Backups: Preventing Data Loss

Published on | Updated

How to set up automatic backups for your FiveM server. Covers database dumps, resource file backups, scheduling, and disaster recovery procedures.

Two players stand between their cars at night on a street below the Vinewood sign in GTA V

A FiveM server keeps its data in three places: the database (player data, inventories, vehicles), the server data folder (server.cfg, scripts and assets) and txAdmin's txData folder (its own configs, data and logs). Losing the database or your scripts is catastrophic. Here's how to protect all three.

What Needs Backing Up

ComponentLocationImportance
MariaDB database/var/lib/mysql/ on Debian and Ubuntu (back it up with a dump, below)Critical
Server resourcesresources/ in your server data folderCritical
Server configserver.cfg in your server data folderHigh
Custom scripts and asset packsinside resources/, often in [bracket] category foldersCritical
txAdmin datatxData, next to run.sh on Linux by default, including admins.jsonHigh
LogstxAdmin's logs in txDataLow

Do not copy /var/lib/mysql/ while MariaDB is running. Copying data files is a physical backup, which MariaDB does with its own tool, mariadb-backup (MariaDB). For a FiveM database, a dump is simpler.

Database Backup

Automated Database Dump

First, keep the database password off the command line. MariaDB calls a password on the command line insecure, and MySQL explains that other users can see it with ps. Store the login in an option file that only you can read:

touch ~/.fivem-backup.cnf
chmod 600 ~/.fivem-backup.cnf
nano ~/.fivem-backup.cnf

[client]
user=fivem
password=YOUR_DATABASE_PASSWORD

Then create the backup script, for example /home/scripts/backup_db.sh:

#!/bin/bash
set -eo pipefail
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/home/backups/database"
mkdir -p "$BACKUP_DIR"

# One consistent InnoDB snapshot; the login comes from the option file
mariadb-dump --defaults-extra-file="$HOME/.fivem-backup.cnf" --single-transaction fivem_server | gzip > "$BACKUP_DIR/fivem_$DATE.sql.gz"

# Delete dumps once they are 8 days old
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +7 -delete

echo "Backup completed: fivem_$DATE.sql.gz"

--defaults-extra-file has to be the first option. set -eo pipefail stops the script when the dump fails, so it does not print "Backup completed" after a failed dump. On MySQL the tool is called mysqldump and takes the same two options.

Make the script executable with chmod +x /home/scripts/backup_db.sh, then add it with crontab -e as the same user, so $HOME points at the folder with the option file:

0 */6 * * * /home/scripts/backup_db.sh

This creates a compressed database dump every 6 hours. find -mtime +7 ignores the part of a day, so it deletes a dump once it is 8 days old and you always keep at least a week of them.

Database Backup Best Practices

Use --single-transaction for InnoDB tables: mariadb-dump and mysqldump run with --opt by default, and --opt includes --lock-tables, which locks the tables of each database while it dumps them. For InnoDB tables, the MariaDB and MySQL docs call --single-transaction "a much better option": it dumps a consistent snapshot without locking the tables, and it switches --lock-tables off. ESX Legacy and QBCore create their tables as InnoDB. While the dump runs, avoid ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE and TRUNCATE TABLE, because the snapshot is not isolated from them.

Test restores monthly: A backup you've never restored is a backup you can't trust.

# Test restore into a separate database
sudo mariadb -e "CREATE DATABASE fivem_test"
LATEST=$(ls -t /home/backups/database/fivem_*.sql.gz | head -n 1)
zcat "$LATEST" | sudo mariadb fivem_test
# Check the data, then drop the test database
sudo mariadb -e "DROP DATABASE fivem_test"

sudo mariadb logs in as the MariaDB root account through the Unix socket, which is how MariaDB sets up root by default.

Our MariaDB and MySQL backup guide adds the users and grants, and a full restore on a new server.

Resource File Backup

Incremental Backups with rsync

#!/bin/bash
set -eo pipefail
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/home/backups/resources"
SOURCE="/home/fivem/server"   # your server data folder, with server.cfg and resources/

mkdir -p "$BACKUP_DIR"
rsync -a --delete "$SOURCE/" "$BACKUP_DIR/latest/"
tar czf "$BACKUP_DIR/server_$DATE.tar.gz" -C "$BACKUP_DIR/latest" .

# Keep the 5 newest archives
ls -t "$BACKUP_DIR"/*.tar.gz | tail -n +6 | xargs rm -f

rsync only copies files whose size or modification time changed since the last run, and each tar archive is a full snapshot of that copy that you can restore on its own. If you deployed with txAdmin's defaults, your server data folder is a subfolder of txData, so pointing SOURCE at txData backs up txAdmin's own data in the same run.

Disaster Recovery

When things go wrong, speed matters. Practice this procedure:

Full Server Restore

  1. Stop the FiveM server
  2. Restore database:
zcat /home/backups/database/fivem_YYYYMMDD_HHMM.sql.gz | sudo mariadb fivem_server
  1. Restore server files:
tar xzf /home/backups/resources/server_YYYYMMDD_HHMM.tar.gz -C /home/fivem/server/
  1. Verify configuration (check server.cfg hasn't changed)
  2. Start the FiveM server
  3. Test: Connect and verify player data, vehicles, inventories

Partial Recovery

More commonly, you need to restore a single table or a specific script. For a table, restore the dump into a scratch database and copy that one table back, with the FiveM server stopped:

# 1. Restore the whole dump into a scratch database
sudo mariadb -e "CREATE DATABASE fivem_test"
zcat /home/backups/database/fivem_YYYYMMDD_HHMM.sql.gz | sudo mariadb fivem_test

# 2. Copy one table back; the dump drops and recreates it in fivem_server
sudo mariadb-dump --single-transaction fivem_test players | sudo mariadb fivem_server

sudo mariadb -e "DROP DATABASE fivem_test"

Replace players with the table you need: QBCore keeps player data in players, ESX Legacy in users. For a script, copy its folder out of latest/ in the resources backup.

Off-Site Backups

Local backups protect against data corruption but not hardware failure. Add off-site backup for true disaster recovery:

# Sync latest backup to remote storage
rclone sync /home/backups/ remote:fivem-backups/ --transfers 4

rclone sync makes the remote identical to your backup folder, so it also deletes remote copies once your local rotation removes them. rclone's docs warn that sync can cause data loss and suggest testing it with --dry-run first; rclone copy never deletes files on the remote. Four parallel transfers is rclone's default. rclone works with over 70 storage products, including Google Drive, Amazon S3 and Backblaze B2.

Backups on Space-Node FiveM Hosting

On Space-Node FiveM hosting, the checkout offers two optional backup add-ons for the game panel: five extra backup slots, and daily backups stored off-site that you restore from the panel. Neither is part of the plan price.

Whichever way you make backups, keep at least one copy outside the server itself.

Sources

All opened on 31 October 2026: