How to Back Up and Restore a FiveM Server

A recoverable FiveM backup pairs the database with the matching resources and configuration. Prove it by restoring that pair on an isolated server and checking player state after a restart.

Define one recovery point

Include server-data, server.cfg, permissions, required txAdmin profiles, custom resources and version records. Note the artifact and framework versions and external dependencies. Keep secrets in private backups, never public repositories.

For a consistent pair, schedule maintenance and stop FXServer and other application writers before the final database dump and file copy. Do not run schema changes during the dump. The examples below use MariaDB; MySQL installations must use their matching vendor tools and options.

Prepare database authentication

Use a dedicated backup account with the privileges required by your database features. Store its connection details in a private MariaDB option file readable only by the backup account. Keep it outside the web root and repository.

The mariadb-dump documentation explains authentication and consistent-snapshot limits. --single-transaction provides a consistent snapshot for transactional tables; it does not make nontransactional tables consistent.

Linux example

Run this as the authorized backup user after coordinating writes. Replace the database name and paths with your actual installation. The private option file must already exist:

#!/usr/bin/env bash
set -euo pipefail
umask 077
stamp=$(date -u +%Y%m%dT%H%M%SZ)
dest="/srv/backups/fivem/$stamp"
install -d -m 0700 "$dest"
mariadb-dump --defaults-extra-file=/etc/fivem/backup.cnf \
  --single-transaction --routines --events --triggers \
  --databases fivem --result-file="$dest/database.sql"
test -s "$dest/database.sql"
tar -C /srv/fivem -czf "$dest/server-data.tar.gz" server-data
tar -tzf "$dest/server-data.tar.gz" > /dev/null
sha256sum "$dest/database.sql" "$dest/server-data.tar.gz" > "$dest/SHA256SUMS"

Add any required txAdmin/configuration paths outside server-data to your backup set. Test the command under the same account and environment used by cron or a systemd timer. Alert on nonzero exit status.

Windows PowerShell example

Use the actual path to mariadb-dump.exe and a private option file. --result-file avoids shell text-encoding changes to the dump:

$ErrorActionPreference = "Stop"
$Stamp = (Get-Date).ToUniversalTime().ToString("yyyyMMddTHHmmssZ")
$Destination = "D:\FiveM-Backups\$Stamp"
New-Item -ItemType Directory -Path $Destination | Out-Null
& "C:\MariaDB\bin\mariadb-dump.exe" `
  "--defaults-extra-file=D:\FiveM-Private\backup.cnf" `
  --single-transaction --routines --events --triggers `
  --databases fivem "--result-file=$Destination\database.sql"
if ($LASTEXITCODE -ne 0) { throw "Database dump failed" }
if ((Get-Item "$Destination\database.sql").Length -eq 0) { throw "Empty dump" }
Copy-Item "D:\FXServer\server-data" "$Destination\server-data" -Recurse
Get-FileHash "$Destination\database.sql" | Format-List

Restrict the backup directory’s Windows permissions to the backup and recovery administrators. In Task Scheduler, use explicit executable paths and a dedicated account; verify its history and failure alerts.

Restore on an isolated server

1. Choose one complete backup generation and verify its checksums or archive integrity. Never combine a newer database with arbitrary older resources.
2. Extract the files into a separate test location. Prepare an isolated database service and restore database.sql with the matching MariaDB client. The dump contains the database name, so do not import it into the live service.
3. Set test-only credentials and endpoints and start the recorded artifact/framework combination. Prevent test resources from sending real payments, webhooks or player notifications.
4. Join with a test player. Verify character, inventory, jobs, housing and permissions; reconnect and restart, then verify again.
5. Record restore duration and any missing dependency. Keep multiple retained generations, an encrypted off-site copy and a backup account that cannot erase every remote generation.

Resume normal writes only after the backup set is complete. A successful scheduled job is useful evidence; a successful restore is the check that makes the backup trustworthy.