Skip to Content
txAdminBackups
Open in ChatGPTOpen in Claude

txAdmin Backups

txAdmin manages your FiveM server and stores administration data, but do not assume that txAdmin automatically schedules full server-file and SQL backups. A txAdmin profile, game resources and an external framework database are different data stores and may need different backup tools.

What you must protect

ComponentTypical locationWhy it matters
txAdmin settings and profilestxData/ (actual path may vary)Admin configuration, logs and deployed profile references
Game server dataRecipe deployment directory, resources/, server.cfgCustom scripts, configuration and world assets
Framework databaseMariaDB/MySQL on this host or anotherCharacters, inventories, transactions and other persistent player data
Custom persistenceResource-specific files or KVPState not necessarily stored in SQL

Never assume that archiving txData alone includes an external SQL database.

Safe manual backup on Linux

  1. Announce maintenance and stop game writes. Stop the server through txAdmin; for a consistent snapshot, stop txAdmin/FXServer as necessary and confirm the relevant processes have exited.

  2. Back up the actual, configured data directory. Replace the example path with your own:

    umask 077
tar -czf "$HOME/fivem-files-$(date +%F).tar.gz" \
  -C /opt/fivem txData

  3. If resources/server configuration live outside txData, include those paths in a separate backup.

  4. For a MariaDB/MySQL framework, use a database-aware backup tool with credentials stored securely. For example:

    mariadb-dump --single-transaction --quick \
  --user=BACKUP_USER --password --databases YOUR_DATABASE \
  > "$HOME/fivem-db-$(date +%F).sql"

    This example prompts for a password. Its consistent-snapshot behavior depends on the table engines in use; test your actual database.

  5. Encrypt and copy both backups to storage outside the server, with controlled access. Resume the server and check that it starts.

Do not rely on the web panel’s logs or restart functions as evidence of a successful backup.

Automate with tools you control

Use a hosting-provider snapshot, scheduled host backup, database backup service, or tested scripts/cron/systemd timers. Configure retention, failure reporting, off-server copies and encryption in that backup system.

Recommended minimum: frequent SQL backups for active roleplay data, daily or change-based file backups, and a copy isolated from server failure or compromise. Set recovery point and recovery time objectives based on the community’s needs rather than a universal “seven copies” rule.

Test a restore before you need one

  1. Use an isolated staging server and do not overwrite production.
  2. Verify archive checksums and inspect all expected files.
  3. Restore the file backup into a new data directory.
  4. Restore the SQL backup into a new test database using a test-only user.
  5. Start the test server with a matching tested artifact and resources. Check that characters, inventories and settings persist.
  6. Document the artifact revision, backup timestamps, SQL version and time needed to recover.

A backup that has not passed a restore test is not proof of recoverability.

Avoid these mistakes

  • Backing up only server.cfg while forgetting the database.
  • Archiving a changing SQL data directory without a database-aware snapshot.
  • Storing the only copy on the same VPS or drive.
  • Posting backups or database connection strings to GitHub.
  • Assuming the txAdmin recipe deployer has a built-in “restore everything” history button.

See Server Backups, txAdmin Security and txAdmin official features .

RecipesDeployer