A usable FiveM backup contains the resources, configuration, database and the information needed to restore them together. A copied folder is incomplete when player, inventory, housing or economy state lives in MariaDB/MySQL.
Define the backup set
- resource folders and custom scripts
server.cfg, permissions and deployment configuration- txAdmin profiles and recipes you actually need
- a consistent database dump
- version notes for artifacts, framework and dependencies
Exclude caches, logs and generated files unless they are required for an investigation. Never place secrets in a public repository.
For MariaDB, verify the current options in the official mariadb-dump documentation instead of copying credentials or flags from an unrelated server.
Windows: PowerShell and Task Scheduler
Create a PowerShell script that stops or coordinates writes, exports the database with your database vendor’s dump tool, copies the server files and writes into a timestamped directory. Use explicit paths and fail when the database export fails.
$Stamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$Destination = "D:\FiveM-Backups\$Stamp"
New-Item -ItemType Directory -Path $Destination | Out-Null
Copy-Item 'D:\FXServer\server-data' "$Destination\server-data" -Recurse
# Run the database dump command documented for your database installation.
In Task Scheduler, create a dedicated low-privilege service account, run whether the user is logged on or not, set the PowerShell program and script path explicitly, and configure failure/retry history. Test the task manually before relying on its schedule.
Linux: script and cron/systemd timer
#!/usr/bin/env bash
set -euo pipefail
stamp=$(date -u +%Y%m%dT%H%M%SZ)
dest="/srv/backups/fivem/$stamp"
install -d -m 0700 "$dest"
tar -C /srv/fivem -czf "$dest/server-data.tar.gz" server-data
# Add the authenticated database dump command for your MariaDB/MySQL setup.
Run it through a systemd timer or cron with a dedicated account. Log exit status and alert on failure. Do not hardcode database passwords in a world-readable script.
Use the 3-2-1 rule
Keep three copies, on two storage types, with one copy off-site. Encrypt off-site archives, define retention, and prevent the production server from deleting every remote generation if its credentials are compromised.
Restore validation
- Provision a clean staging host.
- Restore the database and files from one selected recovery point.
- Start the exact artifact/framework combination recorded with the backup.
- Join as a normal player and verify character, inventory, jobs, housing and permissions.
- Record restore time and missing dependencies, then repair the backup process.
A scheduled “success” means only that the job exited. A completed restore test is the proof.
