How to Back Up and Restore a FiveM Server and Database

A recoverable FiveM backup includes the server’s resources and configuration, its txAdmin profile data and every external database used by the framework. Capture them at a consistent point and restore them together. A file archive or an admin tool’s own player-data backup does not, by itself, establish that a roleplay framework’s SQL database is protected.

What belongs in the backup set?

Recovery inventory
Component	Include or record
Server files	Resources, server.cfg, nested configuration and persistent local data
txAdmin	Actual txData/profile location and any customized paths
SQL state	Every application database, required schema objects and a separate record of account/grant setup
Runtime	OS, FXServer artifact, framework, resource and database versions
Secrets	Protected recovery copies of required credentials; never a public dataset
Operations	Startup service, scheduled jobs, network rules and external integrations

Keep a timestamped manifest that ties these components together. Record how much progress you can afford to lose and how long a restore can take. Those objectives determine the schedule and retention; a once-daily backup may be inadequate for a community that cannot lose a day of activity.

1. Stop writes for a straightforward recovery point

Announce maintenance and stop the game server cleanly. Prevent automatic restarts.
Pause other writers, such as web shops, bots and scheduled jobs, that update the same data. Stopping FXServer alone may not stop all writes.
Export the database and archive the associated files within this quiet interval. Record UTC start/end times and versions.
Check command success and archive readability, copy the set to independent storage, and only then reopen the service.

2. Export a MariaDB database

The example below uses the MariaDB client utilities and a database named fivem. Replace the host, user, database and timestamp. Use an account with the privileges required for the selected objects. The password option prompts rather than placing a password in shell history.

mariadb-dump --host=127.0.0.1 --user=backup_operator --password --single-transaction --quick --routines --events --result-file=fivem-YYYYMMDDTHHMMSSZ.sql fivem

Use a new output filename: --result-file can overwrite an existing file even when an error occurs. Require a successful exit status and inspect the error output; a nonempty file is not proof of a completed dump. --single-transaction provides a consistent view for transactional tables such as InnoDB, not arbitrary table engines. Avoid concurrent schema changes during the export. Routines and events are explicitly included here; triggers are included by default.

If the application uses nontransactional tables or additional databases, adapt the backup method with the database documentation. For MySQL, use its matching client and version-specific instructions instead of assuming every MariaDB option and output format is interchangeable.

3. Restore into an isolated test database

Provision an empty test database with the required character set/collation and a compatible database server. Keep it separate from production. Review stored routines, events and account/DEFINER requirements before importing; do not disable those objects silently just to obtain a successful exit code.

# Linux Bash, not PowerShell. restore_test must already exist.
mariadb --host=127.0.0.1 --user=restore_operator --password restore_test < fivem-YYYYMMDDTHHMMSSZ.sql

The export above deliberately omits --databases so the command can select a separate destination. Still inspect the dump and any embedded cross-database references before restoring. Keep scheduled events disabled on the isolated database server during the rehearsal. Use firewall isolation and test credentials to prevent external side effects.

Restore the matching server files into a private instance and configure its database connection to the test database.
Disable payment hooks, public listings where applicable, bots and other outbound integrations that must not act twice.
Start with the recorded artifact and resource versions. Read SQL and resource errors before admitting testers.
Check representative characters, inventory, money, vehicles, permissions and any custom persistent features.
Make a harmless test change and restart. Confirm it persists in the test database, then record restore duration and any missing recovery steps.

4. Keep evidence and a usable rollback point

Record the backup identifier, checksums, successful export/import status and application checks. Retain more than one generation and an off-server copy with restricted access. Backups can contain player information, passwords and registration secrets; they need the same access discipline as the live service.

During a real recovery, keep the failed state intact for diagnosis and stop all writers before restoring a matched set. If reopening has already created new data, decide how to preserve that progress before reverting again. A database from one date and resource configuration from another can produce a service that starts but behaves incorrectly.

See resource installation for changes that should trigger an extra backup. When comparing FiveM hosting, ask which files and databases are covered, how copies are retained and how restores are performed. This procedure has been checked against documentation; no live EnderHost database restore is claimed here.