Saltar al contenido
Blog

Backup de un servidor FiveM y su base de datos + test de restore

mysqldump para oxmysql, archivos del servidor, cifrado, prueba de restore semanal y cómo devolver el inventario a un jugador sin hacer rollback de la ciudad.

Por Termi

11 min de lectura
  • Backups
  • Database
  • oxmysql
En esta página

Para hacer un backup de un servidor FiveM, vuelca con mysqldump --single-transaction la base MySQL o MariaDB a la que se conecta oxmysql, comprime server.cfg, tus resources y txData, cifra ambos y cópialos fuera de la máquina. Un backup solo cuenta cuando lo has restaurado, así que carga uno cada semana en una base de datos desechable. Para devolverle el inventario a un jugador, restaura en esa base desechable y copia solo sus filas.

Esta guía lo hace todo a mano con herramientas gratuitas, en Linux o en Windows con Git Bash. Nada de lo que hay aquí necesita FiveDock. Al final verás lo mismo hecho por nosotros, incluido Deploy Guard, que hace un backup antes de cada reinicio.

Qué tiene que incluir un backup de FiveM

  • La base de datos. Personajes, dinero, inventarios, vehículos, casas, mensajes del teléfono: todo lo que guardan ESX, QBCore, Qbox y ox_inventory vive aquí. Cambia cada minuto, así que es lo que más a menudo necesita backup.
  • server.cfg. El orden de tus resources, los convars, los permisos, la contraseña de la base y tu sv_licenseKey.
  • resources. Tus scripts, mapas y vehículos, con todos los cambios que hayas hecho a scripts comprados.
  • txData. Los ajustes de txAdmin, los admins y el historial de jugadores.

Deja fuera cache: FXServer lo reconstruye en el siguiente arranque y suele ser la carpeta más grande del disco. Los logs también pueden quedarse fuera.

Encontrar la base de datos que usa oxmysql

oxmysql lee la conexión de server.cfg:

server.cfg
set mysql_connection_string "mysql://fivem:[email protected]/fivem?charset=utf8mb4"

Es decir, usuario fivem, contraseña secret, host 127.0.0.1 y base fivem. Algunos servidores usan la forma antigua server=127.0.0.1;database=fivem;userid=fivem;password=secret, que lleva los mismos cuatro valores.

Volcar la base de datos con mysqldump

Pon las credenciales en un archivo que solo tú puedas leer, para que la contraseña no aparezca en la lista de procesos ni en el historial del shell:

bash
cat > "$HOME/.fivem-backup.cnf" <<'EOF'
[client]
user=fivem
password=secret
host=127.0.0.1
EOF
chmod 600 "$HOME/.fivem-backup.cnf"

Después vuelca la base mientras el servidor sigue encendido:

bash
mysqldump --defaults-extra-file="$HOME/.fivem-backup.cnf" \
  --single-transaction --quick --no-tablespaces \
  --default-character-set=utf8mb4 --hex-blob \
  fivem | gzip > "fivem-$(date +%F-%H%M).sql.gz"
  • --single-transaction lee todas las tablas InnoDB en un snapshot consistente sin bloquearlas: los jugadores siguen jugando y el dinero de users coincide con los items de ox_inventory.
  • --quick envía las filas en streaming en lugar de cargar tablas enteras en memoria, algo que importa cuando los logs y las tablas del teléfono llegan a millones de filas.
  • --no-tablespaces evita un error de privilegios en MySQL 8 (mira los errores).
  • --default-character-set=utf8mb4 y --hex-blob mantienen intactos los emojis de los nombres de personaje y las columnas binarias.

En MariaDB el mismo comando también se llama mariadb-dump, con las mismas opciones. Si tus scripts usan stored procedures, añade --routines.

Comprueba si hay tablas MyISAM

El snapshot solo cubre las tablas InnoDB. Una tabla MyISAM se lee en un momento algo distinto al del resto, así que un backup hecho durante un intercambio puede tener el dinero de antes y el item de después. ALTER TABLE name ENGINE=InnoDB; convierte una tabla.

Hacer backup de los archivos del servidor

bash
tar -czf "files-$(date +%F-%H%M).tar.gz" \
  --exclude='server-data/cache' \
  -C /home/fivem server-data txData

Apunta -C a la carpeta que contiene server-data y txData. En Windows, tar viene incluido en Windows 10 y 11 y acepta las mismas opciones.

Cífralo antes de que salga de la máquina

Un volcado de la base contiene los identifiers de todos los jugadores, y server.cfg contiene la contraseña de la base y tu clave de licencia. Quien consiga una copia puede leerlo todo o arrancar un servidor con tu clave. Cifra con age y una clave pública: el servidor puede cifrar los backups pero no abrirlos, así que un servidor robado no entrega sus propios backups.

Genera el par de claves en tu propio ordenador, no en el servidor:

bash
age-keygen -o fivem-backup.key
# Public key: age1q9x...

Guarda fivem-backup.key en tu gestor de contraseñas y dale al servidor solo la clave pública, la que empieza por age1:

bash
age -r age1q9x... -o fivem-2026-10-15-0400.sql.gz.age fivem-2026-10-15-0400.sql.gz

Si pierdes la clave privada, pierdes con ella todos los backups que cifró. Guarda dos copias en dos sitios distintos.

Guarda copias fuera del servidor

Un backup en el mismo disco se pierde cuando el disco falla, cuando el hosting te rescinde el contrato o cuando alguien formatea la máquina. Copia cada backup a un almacenamiento de objetos como Backblaze B2, Cloudflare R2 o S3 con rclone. Dale al servidor una clave de almacenamiento que pueda subir archivos pero no borrarlos, para que quien entre en el servidor tampoco pueda borrar tus backups.

Ejecútalo cada noche

Todo lo anterior en un solo script:

backup.sh
#!/usr/bin/env bash
set -euo pipefail

STAMP=$(date +%F-%H%M)
OUT=/var/backups/fivem
RECIPIENT=age1q9x...
mkdir -p "$OUT"

mysqldump --defaults-extra-file="$HOME/.fivem-backup.cnf" \
  --single-transaction --quick --no-tablespaces \
  --default-character-set=utf8mb4 --hex-blob \
  fivem | gzip | age -r "$RECIPIENT" > "$OUT/db-$STAMP.sql.gz.age"

tar -czf - --exclude='server-data/cache' -C /home/fivem server-data txData \
  | age -r "$RECIPIENT" > "$OUT/files-$STAMP.tar.gz.age"

rclone copy "$OUT" b2:my-city-backups --include '*.age'
find "$OUT" -name '*.age' -mtime +14 -delete

set -o pipefail importa más de lo que parece. Sin él, mysqldump | gzip tiene éxito siempre que gzip lo tenga, así que con una contraseña equivocada te queda cada noche un archivo de 20 bytes y un log que dice que todo salió bien. Con él, el script se detiene en el primer fallo.

Ejecútalo cada día a las 04:00 con cron:

crontab -e
0 4 * * * /home/fivem/backup.sh >> /var/log/fivem-backup.log 2>&1

En Windows, ejecuta backup.sh con Git Bash desde el Programador de tareas. Haz un backup extra a mano antes de cada actualización de un framework o de un script de inventario.

Prueba el restore o no tienes backup

La mayoría de los rollbacks fallan la noche en que hacen falta: el volcado se cortó a la mitad, la contraseña cambió hace tres meses, nadie guardó la clave privada. Una prueba semanal detecta los tres casos. Hazla en una máquina que tenga la clave privada y MySQL o MariaDB, como tu ordenador o un servidor de pruebas:

bash
age -d -i fivem-backup.key db-2026-10-15-0400.sql.gz.age | gunzip > restore.sql
tail -n 1 restore.sql
# -- Dump completed on 2026-10-15  4:00:03

mysql -e 'DROP DATABASE IF EXISTS restore_test; CREATE DATABASE restore_test'
mysql restore_test < restore.sql

Un volcado completo termina con la línea -- Dump completed. Si falta, el volcado se cortó. Cuando esté importado, compara el backup con el servidor en producción. En QBCore y Qbox usa players en lugar de users:

SQL
SELECT table_schema, COUNT(*) AS tables
FROM information_schema.tables
WHERE table_schema IN ('fivem', 'restore_test')
GROUP BY table_schema;

SELECT
  (SELECT COUNT(*) FROM fivem.users)        AS players_now,
  (SELECT COUNT(*) FROM restore_test.users) AS players_in_backup;

El mismo número de tablas y una cifra de jugadores parecida a la de hoy significan que el backup está entero. Para probar también los archivos, descomprime el archivo junto a una copia de FXServer, apúntalo a restore_test y arráncalo.

Hacer rollback de todo el servidor

Úsalo tras un exploit de duplicación, una economía rota o una actualización que dañó la base de datos. Todos los jugadores pierden lo ocurrido desde el backup, así que avísales antes.

  1. Detén el servidor en txAdmin. No lo reinicies: el framework guarda a cada jugador conectado desde la memoria con su temporizador y al cerrar, y eso sobrescribiría el restore.
  2. Haz un backup del estado roto, por si el restore empeora las cosas.
  3. Importa el backup de antes de que empezara el problema.
  4. Arranca el servidor.
bash
mysqldump --defaults-extra-file="$HOME/.fivem-backup.cnf" \
  --single-transaction --quick --no-tablespaces \
  --default-character-set=utf8mb4 --hex-blob \
  fivem | gzip > before-rollback.sql.gz

age -d -i fivem-backup.key db-2026-10-15-0400.sql.gz.age | gunzip | mysql fivem

El volcado borra y vuelve a crear cada tabla que contiene. Una tabla creada después del backup se queda como está.

Restaurar el inventario de un jugador sin hacer rollback de todos

Un jugador perdió su inventario por un bug, o un cheater vació su cuenta. Un rollback de la ciudad le costaría a todos los demás un día de juego. En su lugar, importa el backup en restore_test en el mismo servidor de base de datos, como en la prueba de restore, y copia de vuelta solo las filas de ese jugador.

Primero busca su identifier. En ESX es la columna identifier de users, y con ox_inventory su inventario está en la misma fila. En QBCore y Qbox es citizenid en players. Después expulsa al jugador y mantenlo fuera del servidor hasta terminar, o el framework escribirá su estado actual encima del restore en su siguiente guardado.

ESX

SQL
SET FOREIGN_KEY_CHECKS = 0;
START TRANSACTION;

REPLACE INTO fivem.users
  SELECT * FROM restore_test.users WHERE identifier = 'char1:3f2a9c...';

DELETE FROM fivem.owned_vehicles WHERE owner = 'char1:3f2a9c...';
INSERT INTO fivem.owned_vehicles
  SELECT * FROM restore_test.owned_vehicles WHERE owner = 'char1:3f2a9c...';

COMMIT;
SET FOREIGN_KEY_CHECKS = 1;

QBCore y Qbox

SQL
SET FOREIGN_KEY_CHECKS = 0;
START TRANSACTION;

REPLACE INTO fivem.players
  SELECT * FROM restore_test.players WHERE citizenid = 'KX81F2QD';

DELETE FROM fivem.player_vehicles WHERE citizenid = 'KX81F2QD';
INSERT INTO fivem.player_vehicles
  SELECT * FROM restore_test.player_vehicles WHERE citizenid = 'KX81F2QD';

COMMIT;
SET FOREIGN_KEY_CHECKS = 1;

REPLACE sobrescribe la fila del jugador con la del backup: dinero, inventario y posición. Los vehículos se borran y se insertan de nuevo, así que un coche comprado después del backup también desaparece. Si un coche cambió de manos desde el backup, el INSERT se detiene por una clave duplicada y la transacción deja todo como estaba. Decide quién se lo queda y vuelve a ejecutarlo.

Si el jugador intercambió algo desde el backup, restaurarlo le devuelve lo que ya entregó y el item pasa a existir dos veces. Revisa sus transacciones antes de restaurar a alguien que dice haberlo perdido todo.

Errores con los que probablemente te toparás

Access denied; you need the PROCESS privilege

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces aparece en MySQL 8.0.21 y posteriores. Añade --no-tablespaces. Una base de FiveM no tiene tablespaces que merezca la pena volcar.

Access denied when using LOCK TABLES

mysqldump: Got error: 1044: Access denied for user 'fivem'@'localhost' to database 'fivem' when using LOCK TABLES significa que el volcado corrió sin --single-transaction e intentó bloquear todas las tablas. Añade la opción. Es también la razón de que el volcado ya no congele el servidor.

Unknown collation utf8mb4_0900_ai_ci

ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci' significa que un volcado de MySQL 8 se está importando en MariaDB, que no conoce esa collation. Reemplázala antes de importar:

bash
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' restore.sql

Lo mismo, hecho por FiveDock

Todo lo anterior es lo que hace Time Machine de FiveDock desde dentro de tu servidor, a través del mismo agente que ejecuta el resto de FiveDock. No hay script que mantener ni tarea de cron que olvidar.

  • Cifrado con tu clave. El agente cifra cada backup en tu máquina con una clave creada para ese servidor y que se te muestra una sola vez. No podemos leer tus backups, nombres de archivo incluidos, y un server.cfg filtrado solo abre los de ese servidor.
  • Consistente e incremental. Cada tabla se lee en un snapshot consistente y el backup te dice qué tablas son MyISAM. Solo se sube lo que cambió, y un backup borrado queda bloqueado 30 días para que nadie pueda eliminar tu historial.
  • Probado cada semana. FiveDock restaura un backup en una base desechable en tu propio servidor y lo marca como restore probado, así que descubres un backup roto semanas antes de necesitarlo.
  • Retrocede justo lo que se rompió. El servidor entero, la base de datos, una tabla, un resource, un archivo o un jugador, con el recuento de lo que va a cambiar antes de confirmar y un backup de seguridad antes. Se niega a restaurar a un jugador que sigue conectado y se niega a restaurar la base mientras ESX, QBCore o Qbox esté en marcha.
  • Deploy Guard. Un backup antes de cada reinicio, un veredicto diez minutos después que nombra el resource que dio problemas, y un clic para volver a como estaba antes del reinicio.
  • Un backup cuando la economía se rompe. Cuando salta una alerta de economía, se hace un backup en ese mismo segundo, antes de que el daño se extienda.

Todos los planes hacen un backup diario. Restaurar una tabla o un jugador, las pruebas de restore semanales, los backups cada hora y Deploy Guard vienen con Metro. En Precios está la lista completa, y Funciones muestra el resto de Time Machine.

FAQ

¿Cada cuánto debo hacer backup de un servidor FiveM?

Haz backup de la base al menos una vez al día, y otro a mano antes de cada actualización del framework o del inventario. Si tu economía está muy activa, hazlo cada hora: un exploit de duplicación descubierto a las 22:00 con un backup de las 04:00 le cuesta 18 horas a cada jugador.

¿Puedo hacer backup de la base con el servidor encendido?

Sí. mysqldump --single-transaction lee las tablas InnoDB en un snapshot consistente sin bloquearlas, así que los jugadores no notan nada. Solo las tablas MyISAM quedan fuera del snapshot.

¿txAdmin hace backup de mi base de datos?

No. txAdmin arranca, reinicia y vigila el servidor, pero no vuelca tu base MySQL o MariaDB. Usa mysqldump con una programación, o una herramienta que lo haga por ti.

¿Cómo hago rollback de un servidor FiveM tras un exploit de dupe?

Detén el servidor en txAdmin, haz un backup del estado actual, importa el último backup anterior al exploit y vuelve a arrancar el servidor. Si solo unos pocos jugadores se beneficiaron, restaura o limpia sus filas en lugar de hacer rollback a todos.

¿Cómo restauro el inventario de un solo jugador?

Importa el backup en una base de datos aparte en el mismo servidor, mantén al jugador desconectado y copia sus filas de users (ESX) o players (QBCore y Qbox), más sus vehículos, a la base en producción en una sola transacción.

¿Dónde está la base de datos que usa oxmysql?

En server.cfg, en la línea set mysql_connection_string. Lleva el usuario, la contraseña, el host y el nombre de la base que necesita mysqldump.

Todos los artículos