A FiveM server stores data in two places: the database (player data, inventories, vehicles) and resource files (scripts, configurations, assets). Losing either is catastrophic. Here's how to protect both.
What Needs Backing Up
| Component | Location | Importance | Size | |-----------|----------|------------|------| | MariaDB database | /var/lib/mysql/ | Critical | 100MB-10GB | | Server resources | /server/resources/ | Critical | 1-20GB | | Server config | server.cfg | High | < 1MB | | Vehicle images | /resources/[assets]/ | Medium | 100MB-2GB | | Custom scripts | /resources/[custom]/ | Critical | 10-500MB | | Logs | /server/logs/ | Low | 50-500MB |
Database Backup
Automated MySQL Dump
Create a backup script:
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/home/backups/database"
mkdir -p "$BACKUP_DIR"
# Dump database
mysqldump -u fivem -p'password' fivem_server | gzip > "$BACKUP_DIR/fivem_$DATE.sql.gz"
# Keep only last 7 days
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +7 -delete
echo "Backup completed: fivem_$DATE.sql.gz"
Schedule with cron:
0 */6 * * * /home/scripts/backup_db.sh
This creates a compressed database dump every 6 hours and keeps the last 7 days of backups.
Database Backup Best Practices
Lock tables during backup: mysqldump does this automatically for InnoDB tables, ensuring data consistency.
Test restores monthly: A backup you've never restored is a backup you can't trust.
# Test restore (to a different database)
mysql -u root -p -e "CREATE DATABASE fivem_test"
zcat /home/backups/database/fivem_latest.sql.gz | mysql -u root -p fivem_test
# Verify data, then drop test database
mysql -u root -p -e "DROP DATABASE fivem_test"
Resource File Backup
Incremental Backups with rsync
#!/bin/bash
DATE=$(date +%Y%m%d_%H%M)
BACKUP_DIR="/home/backups/resources"
SOURCE="/home/fivem/server/resources"
rsync -a --delete "$SOURCE/" "$BACKUP_DIR/latest/"
tar czf "$BACKUP_DIR/resources_$DATE.tar.gz" -C "$BACKUP_DIR" latest/
# Keep last 5 full backups
ls -t "$BACKUP_DIR"/*.tar.gz | tail -n +6 | xargs rm -f
rsync copies only changed files, making the process fast. The tar compression creates archival snapshots.
Disaster Recovery
When things go wrong, speed matters. Practice this procedure:
Full Server Restore
- Stop the FiveM server
- Restore database:
zcat /home/backups/database/fivem_YYYYMMDD_HHMM.sql.gz | mysql -u root -p fivem_server
- Restore resources:
tar xzf /home/backups/resources/resources_YYYYMMDD_HHMM.tar.gz -C /home/fivem/server/
- Verify configuration (check server.cfg hasn't changed)
- Start the FiveM server
- Test: Connect and verify player data, vehicles, inventories
Partial Recovery
More commonly, you need to restore a single table or a specific script:
# Extract single table from dump
zcat backup.sql.gz | sed -n '/^-- Table.*`vehicles`/,/^-- Table/p' > vehicles_only.sql
mysql -u root -p fivem_server < vehicles_only.sql
Off-Site Backups
Local backups protect against data corruption but not hardware failure. Add off-site backup for true disaster recovery:
# Sync latest backup to remote storage
rclone sync /home/backups/ remote:fivem-backups/ --transfers 4
rclone supports Google Drive, S3, Backblaze B2, and dozens of other storage providers.
Hosting-Included Backups
Space-Node FiveM hosting includes automatic backup slots. The panel handles scheduling, retention, and one-click restore without manual scripting.
For critical servers, combine hosting backups with your own automated off-site backups. Redundancy is the foundation of data safety.
