Losing your FiveM server data is every server owner nightmare. Whether it is a corrupted database, an accidental deletion, or a failed update that breaks everything, having reliable backups is the difference between a quick recovery and starting over from scratch. This guide covers what to back up, how to automate the process, and how to restore your server when things go wrong.

What to Back Up

A complete FiveM server backup includes several components. Missing any one of them could leave you unable to fully restore your server:

• txData folder — Contains your txAdmin configuration, player data, bans, whitelist, and admin settings. Losing this means reconfiguring txAdmin from scratch and losing all player management data.
• Resources folder — All your scripts, MLOs, vehicles, and custom resources. While you can re-download most scripts, your custom configurations within each resource are irreplaceable without a backup.
• server.cfg — Your server configuration file with resource load order, convars, license keys, and server settings.
• Database — Your MySQL or MariaDB database contains player characters, inventories, vehicles, housing, bank accounts, job data, and everything else that persists between sessions. This is the most critical component to back up.
• Custom files — Any custom scripts, configuration files, or data files you have created outside the standard resource structure.

Manual Backup Steps

If you are just getting started with backups, here is how to do it manually:

Step 1: Stop the Server

For a clean backup, stop your FiveM server first. This prevents file changes during the backup process and ensures database consistency. If you cannot afford downtime, you can back up while running, but database dumps should still use proper locking.

Step 2: Copy Server Files

Copy your entire server directory to a backup location. On Linux:

cp -r /home/fivem/server /home/fivem/backups/server-$(date +%Y%m%d)

On Windows, use File Explorer or a tool like 7-Zip to create a compressed archive of your server folder.

Step 3: Export the Database

Use mysqldump to create a database export:

mysqldump -u root -p your_database_name > /home/fivem/backups/db-$(date +%Y%m%d).sql

This creates a SQL file containing all your tables, data, and structure. It is a complete snapshot of your database at that moment.

Step 4: Verify the Backup

Always verify your backup files are not corrupted:

• Check file sizes — a database dump should not be 0 bytes
• Open the SQL file and verify it contains valid SQL statements
• Check that your server file archive is not corrupted by listing its contents

Automated Backup Scripts

Manual backups are tedious and easy to forget. Automating the process ensures consistent, reliable backups without manual intervention.

Linux Cron Job

Create a backup script and schedule it with cron:

backup.sh:

#!/bin/bash
BACKUP_DIR="/home/fivem/backups"
SERVER_DIR="/home/fivem/server"
DB_NAME="fivem_db"
DB_USER="root"
DB_PASS="your_password"
DATE=$(date +%Y%m%d_%H%M)

# Database backup
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME > $BACKUP_DIR/db_$DATE.sql

# Server files backup (excluding cache)
tar -czf $BACKUP_DIR/server_$DATE.tar.gz --exclude="cache" $SERVER_DIR

# Remove backups older than 14 days
find $BACKUP_DIR -name "*.sql" -mtime +14 -delete
find $BACKUP_DIR -name "*.tar.gz" -mtime +14 -delete

echo "Backup completed: $DATE"

Schedule it with crontab:

crontab -e
# Run backup daily at 5 AM
0 5 * * * /home/fivem/backup.sh >> /home/fivem/backups/backup.log 2>&1

Windows Task Scheduler

On Windows, create a similar .bat script and schedule it through Task Scheduler. Use the same logic: dump the database, compress server files, and clean up old backups.

Database Dump Best Practices

The database is the most critical backup component. Follow these practices for reliable database backups:

• Use --single-transaction — For InnoDB tables (which most FiveM databases use), this flag creates a consistent snapshot without locking tables: mysqldump --single-transaction -u root -p dbname > backup.sql
• Include routines and triggers — Add --routines --triggers to capture stored procedures and triggers if your scripts use them.
• Compress large dumps — Pipe the output through gzip for smaller files: mysqldump ... | gzip > backup.sql.gz
• Test your dumps regularly — At least monthly, restore a backup to a test database to verify it works. A backup you cannot restore is not a backup.

Storing Backups

Where you store backups matters as much as making them. Follow the 3-2-1 rule:

• 3 copies of your data
• 2 different storage types (local disk + cloud, for example)
• 1 offsite copy (not on the same server)

Local Storage

Keep recent backups on the same machine for fast recovery. Use a separate disk or partition if possible, so a single disk failure does not take both your server and backups.

Cloud Storage

Upload backups to cloud storage for offsite protection. Popular options:

• Amazon S3 — Reliable and cheap for backup storage. Use the S3 Glacier tier for older backups to save costs.
• Backblaze B2 — Very affordable cloud storage with S3-compatible API.
• Google Drive / OneDrive — Viable for smaller servers. Use rclone to automate uploads.
• SFTP to another server — If you have a second server, rsync or SFTP your backups there.

Add a cloud upload step to your backup script using tools like rclone, aws cli, or s3cmd.

Restore Procedure

When disaster strikes, follow this process to restore your server:

Step 1: Assess the Damage

Determine what was lost. Is it just the database? The entire server? A single resource? This determines which backup components you need to restore.

Step 2: Stop the Server

If the server is still running (even partially), stop it before restoring to prevent conflicts.

Step 3: Restore Database

Import your database backup:

mysql -u root -p your_database_name < backup.sql

If restoring a compressed backup:

gunzip < backup.sql.gz | mysql -u root -p your_database_name

Step 4: Restore Server Files

Extract your server file backup to the correct location:

tar -xzf server_backup.tar.gz -C /home/fivem/

Step 5: Verify Configuration

Check your server.cfg, database connection strings, and license keys. If restoring to a new machine, some paths and credentials may need updating.

Step 6: Start and Test

Start the server and verify everything works. Check that players can connect, inventories are intact, vehicles are present, and jobs function correctly.

Backup Frequency Recommendations

Component	Frequency	Retention
Database	Every 6 hours	14 days
Server files	Daily	7 days
Full server + DB	Weekly	30 days
Cloud offsite copy	Daily	30 days

Adjust these frequencies based on your server activity. A busy server with 100+ players and active economy changes warrants more frequent database backups. A smaller server with less activity can get away with daily database backups.

Final Thoughts

Backups are insurance — you hope you never need them, but when you do, nothing else matters. Set up automated backups today, test your restore procedure at least once, and store copies offsite. The hour you spend setting up backups will save you hundreds of hours of rebuilding if something goes wrong. Do not wait until after a disaster to start backing up your server.

Protect Your Server Investment with Quality Scripts

A well-maintained server is only as good as the scripts running on it. Browse VertexMods for premium, regularly-updated FiveM resources:

• jobs-creator-7 — 60€ — Jobs Creator — stable, regularly updated
• drugs-creator — 50€ — Drugs Creator — optimized performance
• robbery-creator — 65€ — Robbery Creator — tested on hundreds of servers
• quasar-inventory-v3 — 35€ — Quasar Inventory V3 — battle-tested inventory