Atualizar artifacts FiveM sem perder dados: guia seguro passo a passo

Aprenda a atualizar artifacts FiveM sem perder dados do servidor, banco MySQL ou configurações. Procedimento completo com backup, swap e rollback.

Manter os artifacts do FiveM atualizados é parte da operação básica de qualquer servidor sério — builds antigas acumulam vulnerabilidades, perdem compatibilidade com scripts modernos e degradam performance em sessões longas. O problema é que muito owner trata a atualização como “baixei o zip novo, sobrescrevi tudo, deu ruim” — e acorda com o banco MySQL corrompido, resources sumidos ou txAdmin pedindo setup do zero.

Este tutorial é pra owner de servidor FiveM (Windows ou Linux) que precisa subir a versão dos artifacts mantendo banco de dados, configurações, conexões com MySQL, txAdmin token e a pasta de resources intactos. O procedimento serve tanto pra migração entre recommended versions quanto pra ir de uma build legacy pra uma atual.

Tempo estimado: 15-20 minutos pra primeira execução cuidadosa, 5-7 minutos quando você já fez algumas vezes.

Pré-requisitos

Antes de começar, confirme que você tem acesso e informações suficientes pra fazer rollback se algo der errado.

Pré-requisitos

Acesso SSH (Linux) ou RDP (Windows) ao servidor com permissão de admin. Espaço em disco livre equivalente ao dobro do tamanho atual da pasta dos artifacts (pro backup). Conhecimento da versão atual instalada e da versão alvo. Janela de manutenção de pelo menos 10 minutos com jogadores avisados.

Identifique onde está sua instalação atual. Em Linux, o padrão é /home/fivem/server/ ou /opt/fivem/. Em Windows, costuma ficar em C:\FXServer\ ou dentro da pasta do usuário. A estrutura típica é:

Pasta dos artifacts server/ ou FXServer/
Pasta de resources resources/ (FORA dos artifacts)
Configuração server.cfg
Dados txAdmin txData/
Banco MySQL externo (porta 3306)

A regra-ouro: a pasta resources/ e o server.cfg ficam SEPARADOS dos binários dos artifacts. Se a sua instalação tem tudo misturado dentro da mesma pasta, este tutorial ainda funciona, mas o backup precisa ser mais cuidadoso — você vai sobrescrever só os binários, não a pasta inteira.

Identificar a versão atual e a versão alvo

Antes de baixar qualquer coisa, confirme o que você tem hoje. Isso facilita o rollback se algo quebrar.

01

Em Linux, entre na pasta dos artifacts e cheque o número da build:

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

A versão aparece como um número de 4 dígitos (ex: 12559). Se o arquivo release.txt não existir, busque o número no nome da pasta onde você descompactou originalmente.

02

Em Windows, abra PowerShell na pasta dos artifacts e rode:

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

Anote a build atual em algum lugar — você vai precisar pro rollback se necessário.

03

Acesse https://runtime.fivem.net/artifacts/fivem/ e identifique a build recommended atual. A página lista builds em ordem cronológica reversa; a recommended fica marcada explicitamente. Anote o número da build alvo.

Backup antes de qualquer mudança

O backup é não-negociável. Mesmo em atualização que parece trivial, é o seguro contra erro humano e regressão de build. Backup completo = artifacts + resources + server.cfg + txData + dump do MySQL.

01

Pare o servidor. No txAdmin, clique em “Stop Server” e aguarde o processo terminar. Pelo terminal, encontre e mate o processo:

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

Em Windows, feche a janela do FXServer.exe ou pare o serviço do txAdmin pelo Painel de Serviços.

02

Faça backup da pasta dos artifacts. Em Linux:

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

Em Windows, copie a pasta inteira pra um destino seguro (preferencialmente disco diferente ou storage externo). Nomeie com data clara: FXServer-backup-2026-05-29.zip.

03

Faça dump do banco MySQL. Esse passo é separado porque o banco é independente dos artifacts — mas se você está fazendo manutenção, é o momento ideal pra ter snapshot fresco:

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

Substitua fivem_user e fivem_db pelos nomes reais do seu setup. Confirme que o arquivo .sql.gz não está vazio antes de prosseguir.

Verifique o backup antes de continuar

Um backup que você não testou é só “esperança de backup”. Liste o conteúdo do arquivo tar com tar -tzf backup-artifacts-*.tar.gz | head e confirme que vê os binários esperados. Pro dump do MySQL, abra o .sql.gz e confirme que aparecem CREATE TABLE no início.

Baixar e instalar a nova versão

Com backup validado, agora você troca os binários. A técnica é “swap por pasta” — extrai a nova versão numa pasta paralela, valida que está completa, depois faz a troca atômica.

01

Baixe o artifact alvo. No site da runtime.fivem.net, copie o link do .tar.xz (Linux) ou .zip (Windows) da build recommended. Em 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

Substitua o número da build e o COMMIT_HASH pelos valores da build que você está instalando.

02

Verifique que a extração trouxe os binários esperados. Você deve ver FXServer, a pasta alpine/ (Linux) ou FXServer.exe + DLLs (Windows):

ls server-new/
file server-new/FXServer

Se o FXServer é executável ELF (Linux) ou PE32+ (Windows), está OK. Se a pasta veio vazia ou sem o binário, repita o download — provavelmente o link estava errado ou interrompido.

03

Faça a troca atômica. A ideia é renomear a pasta antiga pra ficar de fallback e mover a nova pro nome canônico:

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

Em Windows, faça o equivalente no Explorer: renomeie FXServer pra FXServer-old e a pasta nova pra FXServer. Demora um piscar — mas garante que se algo der errado nos próximos passos, você reverte com outro rename instantâneo.

Não apague a pasta antiga ainda

Mantenha server-old-YYYYMMDD/ no disco por pelo menos 48 horas após a atualização. É seu rollback rápido se o servidor crashar ou se um resource crítico parar de funcionar com a build nova. Só apague depois de validar que tudo está estável.

Reconectar resources, configuração e txAdmin

A nova pasta server/ tem só os binários — você precisa apontar pro server.cfg, pra pasta resources/ e pro diretório txData/ que ficaram preservados.

01

Confirme que as pastas externas estão no lugar correto. A estrutura esperada após a troca:

/home/fivem/
├── server/              (binários novos)
├── resources/           (preservada)
├── server.cfg           (preservada)
├── txData/              (preservada  tokens, perfis, ban list)
└── server-old-20260529/ (backup rápido)

Se você tinha tudo dentro da pasta dos binários antes, agora é hora de copiar resources/, server.cfg e txData/ do server-old-*/ pra fora. Use cp -r (Linux) ou copy/paste (Windows).

02

Edite o caminho de inicialização se necessário. Se você usa script de start em run.sh ou start.bat, confirme que ele aponta pra server/FXServer (não server-old) e referencia o server.cfg correto:

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

Em Windows, o .bat típico é:

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

Suba o servidor:

sudo systemctl start fivem
journalctl -u fivem -f

Ou rode direto o run.sh/start.bat num terminal interativo pra ver os logs em tempo real durante o boot.

Verificação

A verificação tem três níveis: o servidor sobe sem erro crítico, o txAdmin responde, e um cliente consegue conectar.

01

Verifique os logs de boot. Procure por mensagens [citizen-server-impl] Server started. ou equivalente. Erros típicos pós-update aparecem como Couldn't load resource X ou Error parsing server.cfg. Resolva qualquer erro vermelho antes de prosseguir.

02

Acesse o txAdmin na porta padrão:

URL txAdmin http://SEU_IP:40120
Porta servidor 30120 (UDP+TCP)
Login Cidadelo / token existente

Se o txAdmin pede setup completo do zero, a pasta txData/ não foi preservada — pare, restaure o backup, e refaça mantendo txData/ fora da troca de binários.

03

Conecte um cliente FiveM ao servidor e teste 2-3 resources críticos do seu gamemode (economia, garagem, banco). Se tudo responde normalmente, a atualização está concluída.

Resolução de problemas

O servidor sobe mas resources não carregam

A causa mais comum é incompatibilidade entre build dos artifacts e versão de algum resource. Builds modernas removem natives deprecated. Cheque o changelog do CitizenFX entre a versão antiga e a nova, e atualize os resources afetados (ESX, QBCore, ox_inventory costumam ter releases sincronizados).

Erro “could not load database connection”

O banco MySQL não foi tocado pelo update — então o problema é configuração. Confirme que server.cfg ainda tem o convar mysql_connection_string correto e que o serviço MySQL está rodando. Teste a conexão manualmente: mysql -u fivem_user -p -h localhost fivem_db.

txAdmin pede setup novo após o update

Significa que ele não encontrou txData/. Pare o servidor, mova txData/ da localização correta (geralmente um nível acima da pasta server/), e suba de novo. Se o backup não tinha txData/, você precisa refazer setup — token novo, master admin, perfil do servidor.

Rollback se tudo falhar

Se a build nova quebra de forma irrecuperável, o rollback é direto: pare o servidor, renomeie server/ pra server-broken/, renomeie server-old-YYYYMMDD/ de volta pra server/, suba o servidor. Tempo total: menos de 1 minuto. Por isso o backup atômico via rename é tão importante.

Próximos passos

  • Configure backup automático do MySQL via cron diário com retenção de 7 dias
  • Documente o procedimento interno com a versão exata que você está rodando
  • Acompanhe o canal #server-development no Discord do CitizenFX pra antecipar mudanças de schema
  • Considere ambiente de staging em outra porta pra testar builds latest antes de promover pra produção
  • Monitore uso de CPU e memória nas primeiras 24h após cada update — regressões de performance entre builds existem e ficam visíveis cedo

Se você está rodando FiveM em VPS compartilhada que sofre com tickrate baixo durante eventos grandes, um servidor dedicado de jogos Hostini já vem com CPU de alta frequência, link DDoS-protected e SSD NVMe — perfil exato pra FiveM em produção. Detalhes em /jogos.

Perguntas frequentes

Preciso parar o servidor pra trocar os artifacts?

Sim. Os binários ficam em uso enquanto o processo FXServer está rodando, e tentar sobrescrever vai falhar (Linux) ou gerar arquivos corrompidos (Windows). Pare o servidor pelo txAdmin ou pelo terminal antes de mover qualquer arquivo. A janela de downtime típica é de 2 a 5 minutos.

Posso pular várias versões de uma vez?

Pode, mas leia o changelog do CitizenFX entre a sua versão atual e a nova. Mudanças de schema em recursos nativos (sessionmanager, basic-gamemode) às vezes exigem ajustes no server.cfg ou em resources comunitários. Pular de uma recommended antiga direto pra latest sem revisar costuma quebrar scripts antigos.

Os meus recursos (resources/) somem se eu trocar os artifacts?

Não, desde que você troque APENAS o conteúdo da pasta dos binários e mantenha resources/, server.cfg, cache/ e o banco MySQL intactos. Os artifacts são o runtime do FXServer — sua pasta resources/ é independente e nunca deve ficar dentro da pasta dos binários.

Qual a diferença entre recommended e latest no FiveM?

Recommended é a build estável validada pelo CitizenFX pra produção. Latest é a mais nova, com features e bugfixes recentes mas pode ter regressões. Pra servidor com jogadores, use sempre recommended. Latest é pra dev/staging.

O txAdmin some quando eu troco os artifacts?

Não, o txAdmin vem embutido em cada build dos artifacts e é restaurado quando você sobe a nova versão. Suas configurações ficam em txData/ (fora da pasta dos binários) e são preservadas. Você só precisa fazer login novamente.

Preciso reconfigurar o server.cfg após atualizar?

Na maioria das atualizações, não. Mas builds que introduzem novos convars ou marcam antigos como deprecated geram warnings no console. Revise o changelog e ajuste o server.cfg se necessário — manter convars deprecated não quebra nada imediatamente, mas vai parar de funcionar em builds futuras.

Tópicos:
Próximos passos VPS, dedicado ou painel gerenciado para FiveM, SAMP, MTA, Tibia e mais.Hospede seu servidor de jogos com a Hostini →
Esse tutorial foi útil?
Falar no WhatsApp