iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A dependable FiveM backup includes the complete server data directory, the txAdmin txData directory, and every external database used by your framework or resources. Stop the server, or otherwise prevent writes, while copying and exporting data so the files and database represent the same point in time. Keep one protected local copy and at least one copy on another disk or host, then verify the process by restoring to an isolated server.
What a complete FiveM backup must contain
Backing up only the folder that contains your resources is not enough. A rebuild also depends on txAdmin state, deployment configuration and, in many installations, a database that lives outside the FXServer files. Treat the following as separate backup targets and document where each one is stored.
Recommended Free Tools
1. The complete server data directory
Copy the entire data directory selected when the server was created or registered. It normally contains resources, scripts, stream assets, server.cfg, permissions and other deployment files. Preserve the directory structure rather than selecting individual resources; a missing manifest, permission file or configuration include can prevent an otherwise healthy server from starting.
The txAdmin getting-started guidance for an existing server explicitly says to select the existing server data folder and its configuration file, then “Back up that folder and your txData before making changes.” The practical interpretation is to make the data directory a single backup unit, including hidden files and files generated by deployment tasks.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
2. The txAdmin txData directory
txData is txAdmin’s own data directory. The environment reference describes it as containing “the txAdmin logs, configs, and data.” It is not the same thing as your server data directory, and copying one does not automatically copy the other.
Do not assume a universal absolute path. The TXHOST_DATA_PATH environment variable can override the location. When it is not overridden, the documented default is under the parent of the FXServer artifact on Windows and under the directory containing run.sh on Linux. A managed host may set a different path, so inspect the provider’s startup configuration or environment rather than copying a guessed folder.
3. Every external database
txAdmin has a backup tool for its self-contained player database, but that tool is not a universal backup for the rest of the server. A framework installed through a recipe can use MySQL or MariaDB, and individual resources may use the same or another external database. Export each database that holds player, character, inventory, economy, permission or resource state.
Use the native dump utility for the database engine and provider you actually run. The exact command depends on the engine, host, port, account permissions and credentials, so use the provider’s current documentation rather than copying a command intended for a different deployment. Align the dump timestamp with the file-copy timestamp and record which database and schema the dump represents.
4. Secrets and deployment metadata
Keep a separate, access-controlled record of license and configuration values needed to bring the server online. Configuration files and database dumps can contain credentials, identifiers or keys. Never place those values in a public repository, paste them into a support request, or include them in a tutorial example. The txAdmin backup password should be treated as a secret as well.
Find the folders and databases before scheduling backups
Identify the active data directory
Use the existing-server profile in txAdmin and note the data-folder and configuration-file selections. If you run FXServer as a service, check the service or startup definition for the path passed to the server. Back up the directory that is actually active; an old staging folder can look complete while production writes to a different location.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Locate txData without guessing
- Check whether the startup environment defines
TXHOST_DATA_PATH. - If it does, use that directory as the txAdmin backup target.
- If it does not, on Windows inspect the path under the parent of the FXServer artifact; on Linux inspect the path under the directory containing
run.sh. - For a managed host, ask the provider where its startup configuration places txAdmin data and whether the path is persistent across reinstalls.
Inventory database dependencies
Review the framework configuration and each resource that stores persistent data. Record the engine (for example, MySQL or MariaDB), database name, host, port, account and the provider’s approved export method. The inventory should distinguish production from test databases so a restore does not accidentally point a new instance at live data.
Safe, consistent backup workflow
A file copy made while resources are writing can capture half-written data or a configuration change that does not match the database dump. Use a maintenance window whenever possible.
- Announce maintenance. Tell players and administrators when writes will stop and how long the window is expected to last.
- Stop or quiesce the server. Stop FXServer cleanly, or use an operational procedure that prevents resources and scheduled jobs from writing while the snapshot is taken. Do not rely on a file copy made during active gameplay as your only recovery point.
- Copy the complete data directory. Preserve permissions, timestamps where your storage system supports them, hidden files and the original directory hierarchy. Include
server.cfgand deployment files. - Copy
txData. Use the resolved path from the startup configuration, not a default guessed from another operating system or host. - Export external databases. Run the native dump process for every framework or resource database. Keep the export in the same dated backup set as the file copies.
- Record identity and timing. Write down the backup date and time, FXServer artifact version, framework and resource versions, operating system, database engine and the txAdmin profile used. This metadata makes a later rebuild less ambiguous.
- Create a second copy. Put the completed set on a different disk or host. An external USB hard drive or SSD is a straightforward physical option; encrypted cloud or object storage provides an off-site option.
- Protect access. Encrypt off-host copies, restrict who can read them and keep the txAdmin backup password and other secrets out of shared notes.
- Record retention generations. Keep multiple dated sets instead of allowing a new copy to overwrite the only previous one. More than one generation protects against corruption or an accidental deletion that is discovered late.
- Restart and verify. Bring the server back, confirm that players can connect, and check that the expected resources, permissions and database-backed data are available.
Using txAdmin’s own backup features correctly
What txAdmin includes
txAdmin is included with FXServer; it is not normally installed as a separate FiveM resource. During registration, the official setup flow asks the owner to set a backup password. Keep that password private and store it in the same protected credential system used for other server secrets.
txAdmin’s player-database backup tool is useful for that self-contained database. It does not copy your resource scripts, stream assets, server.cfg, permissions, external framework database or the rest of txData. A txAdmin database export should therefore be an additional artifact inside a broader server backup, not a substitute for one.
Be cautious with recipe tasks
Recipes can download resources, write files, connect to databases and execute queries. Read the recipe before running it and make a fresh backup of production files and databases first. Do not test destructive recipe tasks against production data; use a cloned profile or isolated host.
Choosing a backup arrangement
The right arrangement depends on how quickly you must recover, how much off-host durability you need and how much operational work your team can maintain. Every option below assumes that the complete data directory, txData and required database dumps are included.
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
| Arrangement | Coverage | Consistency | Recovery speed | Off-host durability | Security and retention considerations |
|---|---|---|---|---|---|
| Single local copy | Can include all files and database exports | Requires stopping or quiescing writes first | Fast when the original machine is healthy | None if the disk is lost | Keep permissions restricted; it should never be the only generation |
| Local copy plus external USB drive or SSD | Full scope when both copies are made from the same dated set | Consistent if the source was quiesced before copying | Usually quick to attach and restore | Protects against a single-machine failure, but not against loss of both locations | Encrypt the removable drive and maintain more than one dated generation |
| Local copy plus encrypted cloud or object storage | Full scope when database dumps and both directories are uploaded | Depends on the same quiesced snapshot procedure | Depends on network bandwidth and provider retrieval time | Provides an off-site copy | Use encryption, least-privilege access and retention that prevents immediate deletion of every generation |
Measure your choice against seven questions: does it cover files, txAdmin data and databases; are writes quiesced; how fast can a replacement host be prepared; is at least one copy off the original machine; are secrets encrypted and access-controlled; how many generations are retained; and how much effort is required to test a restore?
How to name and organize backup sets
Use a dated directory or archive that identifies the server and the point in time, then keep the artifacts together. A practical layout is:
server-data/— the complete FiveM data directory, includingserver.cfg.txData/— the resolved txAdmin data directory.database/— one native dump per external database, with the engine and database name in each filename.metadata/— artifact, framework and resource versions, backup timestamp, host details and restore notes.secrets/— preferably not inside a broadly shared archive; keep references or an encrypted record in a restricted credential store.
Do not place a live credential file in a public code repository merely because it is convenient for deployment. If an archive must contain a secret to support an emergency rebuild, encrypt the archive and limit access to the administrators who perform recovery.
Restoring after a disk failure
Perform the first restore as a controlled drill on an isolated instance. The same sequence becomes your emergency runbook when the production disk fails.
- Provision a replacement host. Install a compatible FXServer artifact and operating-system prerequisites. Use the recorded version information to avoid introducing an unplanned upgrade during recovery.
- Keep the replacement isolated. Use a separate server profile, network identity or test endpoint so the restored instance cannot accept production traffic or write to the live database.
- Restore the server data directory. Place the copied directory at the path expected by the txAdmin profile and verify that resources, stream assets, permissions and
server.cfgare present. - Restore
txData. Set or confirmTXHOST_DATA_PATHso txAdmin uses the restored directory. On managed hosting, follow the provider’s persistent-path procedure rather than assuming the replacement machine uses the old default. - Recreate database access. Provision the required MySQL or MariaDB service, create the intended database and account, then import the corresponding native dump using the provider’s documented process. Keep the replacement isolated while checking the import.
- Reapply secrets securely. Supply license and configuration values from the protected record. Do not copy secrets into chat, tickets or public files.
- Start without exposing production. Launch the isolated profile and inspect startup logs, resource errors, database connections and permissions.
- Verify behavior. Confirm that the server loads the expected resources, player records and framework state. Check administrative access and txAdmin data as well as gameplay-critical data.
- Document differences. Note missing files, version mismatches, changed paths or manual fixes, then update the backup metadata and runbook before declaring the drill complete.
Restore testing that catches real failures
A backup is only useful if it can rebuild the service. Schedule a restore drill often enough that the people responsible for recovery can perform it without improvising. Use a disposable profile or host and never point a test import at the production database.
- Confirm that the archive opens and every expected directory is present.
- Check that the database dump is readable by the intended engine and that its timestamp matches the file snapshot.
- Start with the restored
server.cfgand verify that paths, permissions and resource names resolve. - Log in through txAdmin and confirm that its restored logs, configuration and data are available.
- Test representative player and administrative actions that read and write persistent state.
- Measure the elapsed time from an empty host to a functioning isolated server and record the result in the runbook.
- Destroy the test instance and securely remove temporary copies when the drill ends.
Common backup mistakes and their fixes
Only copying resources
Symptom: the replacement server has scripts but lacks permissions, configuration or generated deployment files. Fix: copy the complete server data directory, not a hand-picked resources folder.
Rank #4
- Easily store and access 4TB of content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Assuming txAdmin backs up everything
Symptom: txAdmin player data is available but the framework’s characters, inventory or economy are missing. Fix: export every external database separately and store its dump with the file backup.
Using the wrong txData path
Symptom: txAdmin starts with an empty profile or old logs after a restore. Fix: inspect TXHOST_DATA_PATH and the provider’s startup configuration, then restore to the path actually used by the replacement profile.
Copying while the server is writing
Symptom: the server starts but recent player changes or resource state is inconsistent. Fix: schedule maintenance and stop or quiesce writes before copying files and exporting the database.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteKeeping one copy on one disk
Symptom: the backup disappears with the failed disk or is overwritten by corruption. Fix: maintain a local recovery copy, an off-host copy and multiple dated generations.
Publishing credentials with the backup
Symptom: a repository, ticket or shared archive exposes database credentials, keys or tokens. Fix: remove secrets from public material, encrypt restricted archives and store the txAdmin backup password separately.
Running a recipe directly on production
Symptom: a recipe changes files or database records in ways that are difficult to reverse. Fix: read the recipe, create a fresh backup and test it on an isolated clone before touching production.
Recommended minimum standard
For a small community server, the minimum defensible routine is a maintenance-window copy of the full server data directory and txData, a native dump of each external database, a second encrypted copy on another disk or host, and a documented restore drill on an isolated profile. Record versions and timestamps with every set. This scope addresses the files and state needed to rebuild rather than preserving only the visible resources.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
As the server grows, improve the process by automating the same sequence without changing its boundaries: quiesce writes, capture all three data classes, protect secrets, retain generations and verify restoration. Automation that omits the database or txData merely creates incomplete backups faster.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
