Cómo actualizar artifacts FiveM sin perder datos: guía paso a paso

Aprende a actualizar artifacts FiveM sin perder datos del servidor, base MySQL ni configuraciones. Procedimiento completo con backup, swap y rollback.

Mantener los artifacts de FiveM actualizados es parte de la operación básica de cualquier servidor serio — builds antiguas acumulan vulnerabilidades, pierden compatibilidad con scripts modernos y degradan performance en sesiones largas. El problema es que muchos owners tratan la actualización como “bajé el zip nuevo, sobreescribí todo, salió mal” — y amanecen con la base MySQL corrupta, resources desaparecidos o txAdmin pidiendo setup desde cero.

Este tutorial es para owner de servidor FiveM (Windows o Linux) que necesita subir la versión de los artifacts manteniendo base de datos, configuraciones, conexiones con MySQL, token de txAdmin y la carpeta de resources intactos. El procedimiento sirve tanto para migración entre recommended versions como para ir de una build legacy a una actual.

Tiempo estimado: 15-20 minutos para la primera ejecución cuidadosa, 5-7 minutos cuando ya lo hayas hecho algunas veces.

Prerrequisitos

Antes de empezar, confirma que tienes acceso e información suficiente para hacer rollback si algo sale mal.

Prerrequisitos

Acceso SSH (Linux) o RDP (Windows) al servidor con permiso de admin. Espacio en disco libre equivalente al doble del tamaño actual de la carpeta de los artifacts (para el backup). Conocimiento de la versión actual instalada y de la versión objetivo. Ventana de mantenimiento de al menos 10 minutos con jugadores avisados.

Identifica dónde está tu instalación actual. En Linux, el patrón es /home/fivem/server/ o /opt/fivem/. En Windows, suele estar en C:\FXServer\ o dentro de la carpeta del usuario. La estructura típica es:

Carpeta de los artifacts server/ o FXServer/
Carpeta de resources resources/ (FUERA de los artifacts)
Configuración server.cfg
Datos txAdmin txData/
Base MySQL externa (puerto 3306)

La regla de oro: la carpeta resources/ y el server.cfg quedan SEPARADOS de los binarios de los artifacts. Si tu instalación tiene todo mezclado dentro de la misma carpeta, este tutorial todavía funciona, pero el backup necesita ser más cuidadoso — vas a sobreescribir solo los binarios, no la carpeta entera.

Identificar la versión actual y la versión objetivo

Antes de bajar cualquier cosa, confirma lo que tienes hoy. Esto facilita el rollback si algo se rompe.

01

En Linux, entra en la carpeta de los artifacts y revisa el número de la build:

cd /home/fivem/server
ls -la
cat citizen/release.txt 2>/dev/null || head -1 components/citizen-server-impl/CMakeLists.txt

La versión aparece como un número de 4 dígitos (ej: 12559). Si el archivo release.txt no existe, busca el número en el nombre de la carpeta donde descomprimiste originalmente.

02

En Windows, abre PowerShell en la carpeta de los artifacts y ejecuta:

Get-ChildItem -Name | Select-Object -First 5
Get-Content citizen\release.txt -ErrorAction SilentlyContinue

Anota la build actual en algún lugar — la vas a necesitar para el rollback si es necesario.

03

Accede a https://runtime.fivem.net/artifacts/fivem/ e identifica la build recommended actual. La página lista builds en orden cronológico inverso; la recommended está marcada explícitamente. Anota el número de la build objetivo.

Backup antes de cualquier cambio

El backup es no-negociable. Incluso en una actualización que parece trivial, es el seguro contra error humano y regresión de build. Backup completo = artifacts + resources + server.cfg + txData + dump del MySQL.

01

Detén el servidor. En txAdmin, haz clic en “Stop Server” y espera a que el proceso termine. Desde la terminal, encuentra y mata el proceso:

ps aux | grep FXServer
sudo systemctl stop fivem 2>/dev/null || pkill -f FXServer

En Windows, cierra la ventana de FXServer.exe o detén el servicio de txAdmin desde el Panel de Servicios.

02

Haz backup de la carpeta de los artifacts. En Linux:

cd /home/fivem
tar -czf backup-artifacts-$(date +%Y%m%d-%H%M).tar.gz server/
ls -lh backup-artifacts-*.tar.gz

En Windows, copia la carpeta entera a un destino seguro (preferentemente disco diferente o storage externo). Nómbrala con fecha clara: FXServer-backup-2026-05-29.zip.

03

Haz dump de la base MySQL. Este paso es separado porque la base es independiente de los artifacts — pero si estás haciendo mantenimiento, es el momento ideal para tener un snapshot fresco:

mysqldump -u fivem_user -p fivem_db > backup-db-$(date +%Y%m%d-%H%M).sql
gzip backup-db-*.sql

Sustituye fivem_user y fivem_db por los nombres reales de tu setup. Confirma que el archivo .sql.gz no esté vacío antes de seguir.

Verifica el backup antes de continuar

Un backup que no probaste es solo “esperanza de backup”. Lista el contenido del archivo tar con tar -tzf backup-artifacts-*.tar.gz | head y confirma que ves los binarios esperados. Para el dump del MySQL, abre el .sql.gz y confirma que aparecen CREATE TABLE al inicio.

Bajar e instalar la nueva versión

Con el backup validado, ahora cambias los binarios. La técnica es “swap por carpeta” — extrae la nueva versión en una carpeta paralela, valida que esté completa, después haz el intercambio atómico.

01

Baja el artifact objetivo. En el sitio de runtime.fivem.net, copia el link del .tar.xz (Linux) o .zip (Windows) de la build recommended. En Linux:

cd /home/fivem
mkdir -p server-new
cd server-new
wget https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/12559-COMMIT_HASH/fx.tar.xz
tar -xJf fx.tar.xz
rm fx.tar.xz

Sustituye el número de la build y el COMMIT_HASH por los valores de la build que estés instalando.

02

Verifica que la extracción haya traído los binarios esperados. Debes ver FXServer, la carpeta alpine/ (Linux) o FXServer.exe + DLLs (Windows):

ls server-new/
file server-new/FXServer

Si el FXServer es ejecutable ELF (Linux) o PE32+ (Windows), está OK. Si la carpeta vino vacía o sin el binario, repite la descarga — probablemente el link estaba mal o se interrumpió.

03

Haz el intercambio atómico. La idea es renombrar la carpeta antigua para que quede de fallback y mover la nueva al nombre canónico:

cd /home/fivem
mv server server-old-$(date +%Y%m%d)
mv server-new server

En Windows, haz el equivalente en el Explorador: renombra FXServer a FXServer-old y la carpeta nueva a FXServer. Demora un parpadeo — pero garantiza que si algo sale mal en los próximos pasos, reviertes con otro rename instantáneo.

No borres la carpeta antigua todavía

Mantén server-old-YYYYMMDD/ en disco por al menos 48 horas después de la actualización. Es tu rollback rápido si el servidor crashea o si un resource crítico deja de funcionar con la build nueva. Solo bórrala después de validar que todo está estable.

Reconectar resources, configuración y txAdmin

La carpeta server/ nueva tiene solo los binarios — necesitas apuntar al server.cfg, a la carpeta resources/ y al directorio txData/ que quedaron preservados.

01

Confirma que las carpetas externas estén en el lugar correcto. La estructura esperada después del intercambio:

/home/fivem/
├── server/              (binarios nuevos)
├── resources/           (preservada)
├── server.cfg           (preservada)
├── txData/              (preservada  tokens, perfiles, ban list)
└── server-old-20260529/ (backup rápido)

Si antes tenías todo dentro de la carpeta de los binarios, ahora es hora de copiar resources/, server.cfg y txData/ desde server-old-*/ hacia fuera. Usa cp -r (Linux) o copy/paste (Windows).

02

Edita la ruta de inicialización si es necesario. Si usas script de start en run.sh o start.bat, confirma que apunta a server/FXServer (no server-old) y referencia el server.cfg correcto:

#!/bin/bash
cd /home/fivem
./server/run.sh +exec server.cfg

En Windows, el .bat típico es:

@echo off
cd /d C:\FXServer
server\FXServer.exe +exec server.cfg
pause
03

Sube el servidor:

sudo systemctl start fivem
journalctl -u fivem -f

O ejecuta directamente el run.sh/start.bat en una terminal interactiva para ver los logs en tiempo real durante el boot.

Verificación

La verificación tiene tres niveles: el servidor sube sin error crítico, el txAdmin responde, y un cliente logra conectarse.

01

Verifica los logs de boot. Busca mensajes [citizen-server-impl] Server started. o equivalente. Errores típicos post-update aparecen como Couldn't load resource X o Error parsing server.cfg. Resuelve cualquier error rojo antes de seguir.

02

Accede a txAdmin en el puerto por defecto:

URL txAdmin http://TU_IP:40120
Puerto servidor 30120 (UDP+TCP)
Login Ciudadano / token existente

Si txAdmin pide setup completo desde cero, la carpeta txData/ no fue preservada — detente, restaura el backup, y rehaz manteniendo txData/ fuera del intercambio de binarios.

03

Conecta un cliente FiveM al servidor y prueba 2-3 resources críticos de tu gamemode (economía, garaje, banco). Si todo responde normalmente, la actualización está concluida.

Resolución de problemas

El servidor sube pero los resources no cargan

La causa más común es incompatibilidad entre la build de los artifacts y la versión de algún resource. Builds modernas remueven natives deprecated. Revisa el changelog de CitizenFX entre la versión antigua y la nueva, y actualiza los resources afectados (ESX, QBCore, ox_inventory suelen tener releases sincronizados).

Error “could not load database connection”

La base MySQL no fue tocada por el update — entonces el problema es configuración. Confirma que server.cfg todavía tiene el convar mysql_connection_string correcto y que el servicio MySQL está corriendo. Prueba la conexión manualmente: mysql -u fivem_user -p -h localhost fivem_db.

txAdmin pide setup nuevo después del update

Significa que no encontró txData/. Detén el servidor, mueve txData/ a la ubicación correcta (generalmente un nivel arriba de la carpeta server/), y súbelo de nuevo. Si el backup no tenía txData/, necesitas rehacer setup — token nuevo, master admin, perfil del servidor.

Rollback si todo falla

Si la build nueva se rompe de forma irrecuperable, el rollback es directo: detén el servidor, renombra server/ a server-broken/, renombra server-old-YYYYMMDD/ de vuelta a server/, sube el servidor. Tiempo total: menos de 1 minuto. Por eso el backup atómico vía rename es tan importante.

Próximos pasos

  • Configura backup automático del MySQL vía cron diario con retención de 7 días
  • Documenta el procedimiento interno con la versión exacta que estás corriendo
  • Sigue el canal #server-development en el Discord de CitizenFX para anticipar cambios de schema
  • Considera un ambiente de staging en otro puerto para probar builds latest antes de promover a producción
  • Monitorea uso de CPU y memoria en las primeras 24h después de cada update — regresiones de performance entre builds existen y se hacen visibles temprano

Si estás corriendo FiveM en VPS compartida que sufre con tickrate bajo durante eventos grandes, un servidor dedicado de juegos Hostini ya viene con CPU de alta frecuencia, link DDoS-protected y SSD NVMe — perfil exacto para FiveM en producción. Detalles en /jogos.

Preguntas frecuentes

¿Necesito detener el servidor para cambiar los artifacts?

Sí. Los binarios quedan en uso mientras el proceso FXServer está corriendo, y tratar de sobreescribir va a fallar (Linux) o generar archivos corruptos (Windows). Detén el servidor desde txAdmin o desde la terminal antes de mover cualquier archivo. La ventana de downtime típica es de 2 a 5 minutos.

¿Puedo saltar varias versiones a la vez?

Puedes, pero lee el changelog de CitizenFX entre tu versión actual y la nueva. Cambios de schema en recursos nativos (sessionmanager, basic-gamemode) a veces exigen ajustes en server.cfg o en resources comunitarios. Saltar de una recommended antigua directo a latest sin revisar suele romper scripts viejos.

¿Mis recursos (resources/) desaparecen si cambio los artifacts?

No, siempre que cambies SOLAMENTE el contenido de la carpeta de los binarios y mantengas resources/, server.cfg, cache/ y la base MySQL intactos. Los artifacts son el runtime del FXServer — tu carpeta resources/ es independiente y nunca debe estar dentro de la carpeta de los binarios.

¿Cuál es la diferencia entre recommended y latest en FiveM?

Recommended es la build estable validada por CitizenFX para producción. Latest es la más nueva, con features y bugfixes recientes pero puede tener regresiones. Para servidor con jugadores, usa siempre recommended. Latest es para dev/staging.

¿txAdmin desaparece cuando cambio los artifacts?

No, txAdmin viene embebido en cada build de los artifacts y se restaura cuando subes la nueva versión. Tus configuraciones quedan en txData/ (fuera de la carpeta de los binarios) y se preservan. Solo necesitas hacer login de nuevo.

¿Necesito reconfigurar el server.cfg después de actualizar?

En la mayoría de las actualizaciones, no. Pero builds que introducen nuevos convars o marcan antiguos como deprecated generan warnings en la consola. Revisa el changelog y ajusta el server.cfg si es necesario — mantener convars deprecated no rompe nada de inmediato, pero va a dejar de funcionar en builds futuras.

Temas:
Próximos pasos VPS, dedicado o panel gestionado para FiveM, SAMP, MTA, Tibia y más.Aloja tu servidor de juegos con Hostini →
¿Te resultó útil este tutorial?
Hablar por WhatsApp