Backup de servidor FiveM e banco de dados, com teste de restore

Para fazer backup de um servidor FiveM, gere um dump do banco MySQL ou MariaDB a que o oxmysql se conecta com mysqldump --single-transaction, compacte server.cfg, seus resources e txData, criptografe os dois e copie para fora da máquina. Um backup só vale depois de restaurado, então carregue um por semana num banco descartável. Para devolver o inventário de um jogador, restaure nesse banco descartável e copie só as linhas dele.

Este guia faz tudo isso na mão, com ferramentas gratuitas, no Linux ou no Windows com Git Bash. Nada aqui exige o FiveDock. No fim, o mesmo processo feito por nós, incluindo o Deploy Guard, que faz um backup antes de cada restart.

O que um backup de FiveM precisa incluir

• O banco de dados. Personagens, dinheiro, inventários, veículos, casas, mensagens do celular: tudo o que ESX, QBCore, Qbox e ox_inventory guardam está aqui. Ele muda a cada minuto, então é o que mais precisa de backup frequente.
• server.cfg. A ordem dos seus resources, convars, permissões, a senha do banco e o seu sv_licenseKey.
• resources. Seus scripts, mapas e veículos, com todas as alterações que você fez em scripts comprados.
• txData. As configurações do txAdmin, os admins e o histórico de jogadores.

Deixe cache de fora: o FXServer recria a pasta na próxima inicialização, e ela costuma ser a maior do disco. Os logs também podem ficar de fora.

Descubra qual banco o oxmysql usa

O oxmysql lê a conexão do server.cfg:

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

Ou seja, usuário fivem, senha secret, host 127.0.0.1 e banco fivem. Alguns servidores usam a forma antiga server=127.0.0.1;database=fivem;userid=fivem;password=secret, que traz os mesmos quatro valores.

Faça o dump do banco com mysqldump

Coloque as credenciais num arquivo que só você consiga ler, para a senha não aparecer na lista de processos nem no histórico do shell:

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

Depois faça o dump com o servidor continuando no ar:

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 lê todas as tabelas InnoDB num snapshot consistente, sem travá-las: os jogadores continuam jogando e o dinheiro em users bate com os itens do ox_inventory.
• --quick envia as linhas em stream em vez de carregar tabelas inteiras na memória, o que faz diferença quando logs e tabelas do celular chegam a milhões de linhas.
• --no-tablespaces evita um erro de privilégio no MySQL 8 (veja os erros).
• --default-character-set=utf8mb4 e --hex-blob preservam os emojis nos nomes de personagem e as colunas binárias.

No MariaDB o mesmo comando também se chama mariadb-dump, com as mesmas opções. Se os seus scripts usam stored procedures, adicione --routines.

Faça backup dos arquivos do servidor

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

Aponte o -C para a pasta que contém server-data e txData. No Windows, o tar já vem com o Windows 10 e o 11 e aceita as mesmas opções.

Criptografe antes de sair da máquina

Um dump do banco tem os identifiers de todos os jogadores, e o server.cfg tem a senha do banco e a sua chave de licença. Quem pegar uma cópia consegue ler tudo ou subir um servidor com a sua chave. Criptografe com o age e uma chave pública: o servidor consegue criptografar os backups, mas não abri-los, então um servidor roubado não entrega os próprios backups.

Gere o par de chaves no seu computador, não no servidor:

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

Guarde o fivem-backup.key no seu gerenciador de senhas e passe ao servidor só a chave pública, a que começa com age1:

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

Mantenha cópias fora do servidor

Um backup no mesmo disco some quando o disco falha, quando a hospedagem encerra seu contrato ou quando alguém apaga a máquina. Copie cada backup para um object storage, como Backblaze B2, Cloudflare R2 ou S3, com o rclone. Dê ao servidor uma chave de storage que possa enviar arquivos mas não apagá-los, para que quem invadir o servidor também não consiga apagar seus backups.

Rode toda noite

Tudo o que vimos num só script:

#!/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 mais do que parece. Sem ele, mysqldump | gzip dá sucesso sempre que o gzip dá, então com a senha errada você ganha toda noite um arquivo de 20 bytes e um log dizendo que deu tudo certo. Com ele, o script para na primeira falha.

Rode todo dia às 04:00 com o cron:

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

No Windows, execute o backup.sh com o Git Bash pelo Agendador de Tarefas. Faça um backup extra na mão antes de toda atualização de framework ou de script de inventário.

Teste o restore, ou você não tem backup

A maioria dos rollbacks falha justo na noite em que são necessários: o dump parou no meio, a senha mudou há três meses, ninguém guardou a chave privada. Um teste semanal pega os três casos. Faça numa máquina que tenha a chave privada e MySQL ou MariaDB, como o seu computador ou um servidor de teste:

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

Um dump completo termina com a linha -- Dump completed. Se ela não estiver lá, o dump foi cortado. Depois de importar, compare o backup com o servidor em produção. No QBCore e no Qbox, use players no lugar de users:

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;

O mesmo número de tabelas e uma contagem de jogadores próxima da de hoje indicam que o backup está inteiro. Para testar os arquivos também, descompacte o pacote ao lado de uma cópia do FXServer, aponte-o para restore_test e inicie.

Dê rollback no servidor inteiro

Use depois de um exploit de duplicação, de uma economia quebrada ou de uma atualização que danificou o banco. Todo jogador perde o que aconteceu desde o backup, então avise antes.

1. Pare o servidor no txAdmin. Não reinicie: o framework salva cada jogador online a partir da memória no seu timer e ao fechar, e isso sobrescreveria o restore.
2. Faça um backup do estado quebrado, caso o restore piore as coisas.
3. Importe o backup de antes de o problema começar.
4. Inicie o servidor.

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

O dump apaga e recria cada tabela que contém. Uma tabela criada depois do backup fica como está.

Restaure o inventário de um jogador sem dar rollback em todos

Um jogador perdeu o inventário por causa de um bug, ou um cheater esvaziou a conta dele. Dar rollback na cidade custaria um dia de jogo para todo mundo. Em vez disso, importe o backup em restore_test no mesmo servidor de banco, como no teste de restore, e copie de volta só as linhas desse jogador.

Primeiro ache o identifier dele. No ESX é a coluna identifier de users, e com o ox_inventory o inventário fica na mesma linha. No QBCore e no Qbox é o citizenid em players. Depois kicke o jogador e mantenha-o fora do servidor até terminar, ou o framework grava o estado atual por cima do restore no próximo save.

ESX

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 e Qbox

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 sobrescreve a linha do jogador com a do backup: dinheiro, inventário e posição. Os veículos são apagados e inseridos de novo, então um carro comprado depois do backup também some. Se um carro mudou de dono desde o backup, o INSERT para por chave duplicada e a transação deixa tudo como estava. Decida quem fica com ele e rode de novo.

Erros que você provavelmente vai encontrar

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 no MySQL 8.0.21 e posteriores. Adicione --no-tablespaces. Um banco de FiveM não tem tablespaces que valham o dump.

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 o dump rodou sem --single-transaction e tentou travar todas as tabelas. Adicione a opção. É também o motivo de o dump não congelar mais o servidor.

Unknown collation utf8mb4_0900_ai_ci

ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci' significa que um dump do MySQL 8 está sendo importado no MariaDB, que não conhece essa collation. Troque-a antes de importar:

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

O mesmo, feito pelo FiveDock

Tudo isso é o que o Time Machine do FiveDock faz de dentro do seu servidor, pelo mesmo agente que roda o resto do FiveDock. Não há script para manter nem cron para esquecer.

• Criptografado com a sua chave. O agente criptografa cada backup na sua máquina com uma chave criada para aquele servidor e mostrada a você uma única vez. Nós não conseguimos ler seus backups, nem os nomes dos arquivos, e um server.cfg vazado abre só os backups daquele servidor.
• Consistente e incremental. Cada tabela é lida num snapshot consistente, e o backup avisa quais tabelas são MyISAM. Só o que mudou é enviado, e um backup apagado fica travado por 30 dias para que ninguém consiga apagar seu histórico.
• Testado toda semana. O FiveDock restaura um backup num banco descartável no seu próprio servidor e o marca como restore testado, então você descobre um backup quebrado semanas antes de precisar dele.
• Volte exatamente o que quebrou. O servidor inteiro, o banco, uma tabela, um resource, um arquivo ou um jogador, com a contagem do que vai mudar antes de você confirmar e um backup de segurança primeiro. Ele se recusa a restaurar um jogador que ainda está conectado e a restaurar o banco enquanto ESX, QBCore ou Qbox estiver rodando.
• Deploy Guard. Um backup antes de cada restart, um veredito dez minutos depois que aponta o resource que deu problema e um clique para voltar ao estado anterior ao restart.
• Um backup quando a economia quebra. Quando um alerta de economia dispara, o backup é feito naquele segundo, antes de o estrago se espalhar.

Todos os planos fazem um backup diário. Restaurar uma tabela ou um jogador, testes de restore semanais, backups de hora em hora e Deploy Guard vêm com o Metro. A lista completa está em Preços, e Recursos mostra o resto do Time Machine.

FAQ

Com que frequência devo fazer backup de um servidor FiveM?

Faça backup do banco pelo menos uma vez por dia, e mais um na mão antes de cada atualização de framework ou de inventário. Se a economia é movimentada, faça de hora em hora: um exploit de duplicação descoberto às 22:00 com um backup das 04:00 custa 18 horas a cada jogador.

Posso fazer backup do banco com o servidor rodando?

Pode. O mysqldump --single-transaction lê as tabelas InnoDB num snapshot consistente sem travá-las, e os jogadores nem percebem. Só as tabelas MyISAM ficam fora do snapshot.

O txAdmin faz backup do meu banco de dados?

Não. O txAdmin inicia, reinicia e monitora o servidor, mas não faz dump do seu banco MySQL ou MariaDB. Use o mysqldump agendado, ou uma ferramenta que faça isso por você.

Como dou rollback num servidor FiveM depois de um exploit de dupe?

Pare o servidor no txAdmin, faça um backup do estado atual, importe o último backup anterior ao exploit e inicie o servidor de novo. Se só alguns jogadores lucraram, restaure ou limpe as linhas deles em vez de dar rollback em todo mundo.

Como restauro o inventário de um jogador só?

Importe o backup num banco separado no mesmo servidor, mantenha o jogador offline e copie as linhas dele de users (ESX) ou players (QBCore e Qbox), mais os veículos, para o banco em produção numa única transação.

Onde fica o banco que o oxmysql usa?

No server.cfg, na linha set mysql_connection_string. Ela traz o usuário, a senha, o host e o nome do banco de que o mysqldump precisa.