Backup et restauration complète d'un serveur FiveM

Introduction

Un serveur FiveM, c'est deux choses : les fichiers (resources, server.cfg, txData) et la BDD MySQL (identifiants, économie, characters). Les deux doivent être sauvegardés de manière cohérente. Une sauvegarde de fichiers sans la BDD = quasi inutile pour un serveur RP/économique.

Prérequis

• Un serveur FiveM chez VeryCloud (panel Wisp)
• Une BDD MySQL associée (locale ou externe)
• Optionnel : un VPS externe pour l'offsite

Étape 1 : Identifier ce qu'il faut backup

Étape 2 : Schedule Wisp pour les fichiers

Dans Wisp → Schedules :

1. Create Schedule
2. Name : Daily files backup 3 AM
3. Cron : 0 3 * * *
4. Only when online : oui
5. Add Task : Create Backup, nom daily-{date}

Wisp snapshot tout /home/container/ (resources + config + txData).

Étape 3 : Backup MySQL avec mysqldump

Wisp ne backup PAS la BDD (elle est externe au conteneur FiveM). Tu dois le faire toi-même.

Sur ton serveur MySQL (ou un VPS externe avec accès distant) :

#!/bin/bash
# /usr/local/bin/mysql-backup-fivem.sh
set -e

DB_HOST="ton.mysql.host"
DB_USER="fivem_backup_user"
DB_PASS_FILE="/root/.mysql_pass"   # chmod 600
DB_NAME="fivem_db"

DEST="/backups/mysql"
mkdir -p "$DEST"

DATE=$(date +%Y%m%d_%H%M%S)
FILE="$DEST/fivem_${DATE}.sql.gz"

mysqldump \
  -h "$DB_HOST" -u "$DB_USER" -p"$(cat $DB_PASS_FILE)" \
  --single-transaction --quick --lock-tables=false \
  --routines --triggers --events \
  "$DB_NAME" | gzip > "$FILE"

echo "Backup: $FILE ($(du -h $FILE | cut -f1))"

# Rotation : garder 14 jours
find "$DEST" -name "fivem_*.sql.gz" -mtime +14 -delete

Cron :

0 2 * * * /usr/local/bin/mysql-backup-fivem.sh >> /var/log/mysql-backup.log 2>&1

Note : --single-transaction est essentiel pour ne pas locker la BDD pendant le dump.

Étape 4 : Créer l'utilisateur backup MySQL dédié

Avec privilèges minimaux :

CREATE USER 'fivem_backup_user'@'IP_DU_BACKUP_HOST' IDENTIFIED BY 'mdp_solide';
GRANT SELECT, SHOW VIEW, LOCK TABLES, EVENT, TRIGGER ON fivem_db.* TO 'fivem_backup_user'@'IP_DU_BACKUP_HOST';
FLUSH PRIVILEGES;

Pas de DROP, pas d'INSERT — uniquement de la lecture.

Étape 5 : Offsite avec rclone vers B2 / S3

Sur ton VPS de backup :

# Une fois pour configurer
rclone config

# Sync quotidienne
rclone sync /backups/mysql b2:mybucket/fivem-mysql \
  --transfers 4 \
  --backup-dir b2:mybucket/fivem-old/$(date +%F)

Cron :

30 4 * * * rclone sync /backups/mysql b2:mybucket/fivem-mysql --transfers 4

Étape 6 : Tester une restauration

Une fois par mois minimum. Sur un environnement de test :

Restaurer les fichiers :

1. Crée un serveur FiveM staging (autre instance Wisp)
2. Wisp → Backups → restore le dernier backup vers cet env

Restaurer la BDD :

# Decompresse
gunzip < /backups/mysql/fivem_20260516_020000.sql.gz > /tmp/restore.sql

# Import
mysql -h STAGING_DB_HOST -u staging_user -p staging_db < /tmp/restore.sql

Démarre le serveur staging, vérifie que les joueurs/véhicules/maisons sont là. Si c'est cohérent, ta chaîne marche.

Étape 7 : Restaurer en cas d'incident (procédure)

Scénario : ton serveur prod a été compromis ou des données ont disparu.

Étape 1 — Communique

Annonce en Discord/Twitter une maintenance immédiate. Empêche les joueurs de se reconnecter (sv_maxClients 0 ou stop serveur).

Étape 2 — Identifie le point de restauration

Le dernier backup AVANT le problème. Pas de panique, prends 5 min.

Étape 3 — Restaure les fichiers

Wisp → Backups → ton serveur → restore le backup choisi.

Étape 4 — Restaure la BDD

# Important : drop l'ancienne BDD ou recree pour eviter conflits
mysql -h DB_HOST -u root -p
DROP DATABASE fivem_db;
CREATE DATABASE fivem_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
exit

# Restore
gunzip < /backups/mysql/fivem_GOOD_DATE.sql.gz | \
  mysql -h DB_HOST -u root -p fivem_db

Étape 5 — Redémarre + vérifie

Start serveur, check les logs, valide rapidement (te connecte en jeu, regarde un personnage connu).

Étape 6 — Communique le retour

Étape 8 : Backups avant grosse modif

Avant toute action risquée :

• Update de framework (ESX, QBCore)
• Import de scripts custom
• Modification de schéma BDD
• Maj artifacts FiveM

→ Snapshot manuel Wisp + dump MySQL manuel. 2 minutes, ça vaut toujours la peine.

# Dump rapide manuel
mysqldump -u user -p --single-transaction db_name | gzip > manual_$(date +%F_%H%M).sql.gz

Étape 9 : Stratégie 3-2-1 récap

• 3 copies : Wisp local + VPS backup + cloud (B2/S3)
• 2 supports : Wisp + ton VPS externe
• 1 offsite : cloud distant

Pour 5-10€/mois en stockage cloud, tu protèges des centaines d'heures de gameplay accumulé.

Étape 10 : Monitoring des backups

Tu veux savoir si un backup a échoué :

• Healthchecks.io : ping après chaque backup OK
• Discord webhook : envoie un message Discord à chaque succès/échec
• Alerte mail si pas de backup depuis >25h

Exemple Discord webhook dans le script de backup :

curl -X POST -H "Content-Type: application/json" \
  -d "{\"content\":\"MySQL backup OK: ${FILE}\"}" \
  https://discord.com/api/webhooks/.../...

Dépannage

mysqldump: Got error: 1142: SELECT, LOCK TABLES command denied

• Le user backup n'a pas LOCK TABLES — GRANT LOCK TABLES
• Ou utilise --lock-tables=false (combo avec --single-transaction)

Backup gigantesque (plusieurs Go)

• Logs ou table de cache trop grosse — tronque avant backup
• Active la rotation logs côté framework

Restauration BDD plante au milieu

• Conflit de schéma (collation, version MySQL différente)
• Vérifie que staging/prod ont la même version MySQL

Backup Wisp dépasse le quota

• Augmente le plan ou réduit la rétention
• Exclus le cache (FiveM cache/ est regenerable)

Commandes utiles

# Dump rapide compresse
mysqldump --single-transaction db | gzip > db.sql.gz

# Verifier la taille
du -sh /backups/

# Restore rapide
gunzip < backup.sql.gz | mysql db

# Tester l'integrite
gunzip -t backup.sql.gz

Conclusion

Backup FiveM complet = Wisp Schedules (fichiers) + mysqldump cron (BDD) + offsite cloud. 3 niveaux indépendants, retesté chaque mois, et tu dors tranquille. Le piège classique = backup uniquement Wisp en oubliant la BDD. Une économie de RP qui disparaît, c'est ta communauté qui se barre.

Pour aller plus loin : automatisation complète via CI, healthchecks + alerting Discord/Slack, dedup avec restic pour optimiser le stockage.

Ressources

• MySQL Documentation — mysqldump
• rclone — Documentation
• Healthchecks.io — Cron monitoring
• Wisp Schedules