Cara Backup dan Restore Database Server FiveM (MariaDB/MySQL)

Database adalah isi kota kamu: karakter, uang, kendaraan, rumah, inventory, dan riwayat kerja pemain. Resource bisa di-download ulang, tapi kalau database hilang karena disk rusak, query salah, atau server diretas, berbulan-bulan roleplay ikut lenyap.

Panduan ini membahas cara membuat backup database server FiveM yang otomatis, aman, dan yang paling penting: benar-benar bisa di-restore. Contoh memakai Ubuntu dengan MariaDB atau MySQL, yang dipakai oleh framework seperti QBCore, QBox, dan ESX melalui oxmysql.

Apa saja yang harus di-backup

Backup server FiveM yang lengkap terdiri dari tiga bagian:

1. Database (MariaDB/MySQL). Paling penting dan paling sering berubah.
2. Folder server data: server.cfg, folder resources/, dan konfigurasi custom. Lewati folder cache/ karena bisa dibuat ulang.
3. Data txAdmin (folder txData), berisi konfigurasi txAdmin, akun admin, dan riwayat ban/warn.

Jangan pernah menyimpan backup hanya di server yang sama. Kalau disk atau server itu bermasalah, backup ikut hilang. Prinsip yang umum dipakai adalah aturan 3-2-1: tiga salinan data, di dua media berbeda, satu di lokasi lain.

Langkah 1: buat user khusus untuk backup

Jangan pakai user root database untuk script backup. Buat user dengan hak minimal:

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'ganti-dengan-password-kuat';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT, RELOAD, PROCESS ON *.* TO 'backup'@'localhost';
FLUSH PRIVILEGES;

Simpan kredensial di file opsi, bukan di command line (yang bisa terlihat lewat ps):

sudo tee /root/.my.cnf >/dev/null <<'EOF' [client] user=backup password=ganti-dengan-password-kuat EOF sudo chmod 600 /root/.my.cnf

Langkah 2: backup manual pertama

Untuk tabel InnoDB (default di MariaDB/MySQL modern), opsi --single-transaction membuat snapshot yang konsisten tanpa mengunci tabel, sehingga server FiveM tetap bisa berjalan saat backup.

# ganti "fivem" dengan nama database kamu
mysqldump --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 fivem | gzip > /root/fivem-$(date +%F).sql.gz

Di MariaDB versi baru, perintah mysqldump juga tersedia dengan nama mariadb-dump. Keduanya menerima opsi yang sama untuk contoh ini.

Cek hasilnya:

ls -lh /root/fivem-*.sql.gz
zcat /root/fivem-$(date +%F).sql.gz | tail -n 3
# baris terakhir dump yang selesai biasanya berisi "-- Dump completed on ..."

Kalau baris "Dump completed" tidak ada, kemungkinan proses terputus di tengah jalan.

Langkah 3: script backup otomatis

Script berikut membuat dump database, mengarsipkan folder server, lalu menghapus backup lokal yang lebih tua dari 14 hari. Sesuaikan path dengan instalasi kamu.

sudo tee /usr/local/bin/fivem-backup >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

DB=fivem
SERVER_DIR=/home/fivem/server-data
TXDATA_DIR=/home/fivem/txData
DEST=/var/backups/fivem
KEEP_DAYS=14
TS=$(date +%F_%H%M)

mkdir -p "$DEST"

# 1) database
mysqldump --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 "$DB" | gzip > "$DEST/db_$TS.sql.gz"

# 2) file server (tanpa cache)
tar --exclude='cache' -czf "$DEST/files_$TS.tar.gz" \
  -C "$(dirname "$SERVER_DIR")" "$(basename "$SERVER_DIR")" \
  -C "$(dirname "$TXDATA_DIR")" "$(basename "$TXDATA_DIR")"

# 3) cek dump selesai
zcat "$DEST/db_$TS.sql.gz" | tail -n 1 | grep -q "Dump completed" \
  || { echo "dump tidak lengkap: $DEST/db_$TS.sql.gz" >&2; exit 1; }

# 4) rotasi lokal
find "$DEST" -name '*.gz' -mtime +"$KEEP_DAYS" -delete
EOF
sudo chmod 700 /usr/local/bin/fivem-backup
sudo /usr/local/bin/fivem-backup && ls -lh /var/backups/fivem

set -o pipefail penting: tanpa itu, kegagalan mysqldump bisa tertutupi oleh gzip yang tetap sukses, dan kamu akan menyimpan file backup kosong tanpa sadar.

Langkah 4: jadwalkan dengan cron

Pilih jam sepi, misalnya pukul 05.00 WIB. Cek dulu zona waktu server dengan timedatectl.

sudo crontab -e
# tambahkan baris berikut (jalan setiap hari jam 05:00 waktu server)
0 5 * * * /usr/local/bin/fivem-backup >> /var/log/fivem-backup.log 2>&1

Untuk server ramai dengan ekonomi aktif, banyak admin menambah backup database setiap beberapa jam karena dump database biasanya kecil dan cepat. Backup file cukup harian atau setiap kali ada update resource.

Langkah 5: kirim backup ke luar server

Gunakan rclone untuk mengirim backup ke object storage (S3-compatible, Google Drive, Backblaze B2, dan lain-lain).

sudo apt install rclone
sudo rclone config        # buat remote, misalnya bernama "offsite"
sudo rclone copy /var/backups/fivem offsite:fivem-backup --max-age 25h

Tambahkan baris rclone copy di akhir script backup. Untuk keamanan ekstra, gunakan kredensial storage yang hanya punya izin menulis (tanpa izin menghapus), sehingga kalau server kamu diretas, penyerang tidak bisa sekaligus menghapus semua backup offsite.

Cara restore database

Restore sebaiknya dilakukan saat server FiveM dimatikan, supaya tidak ada data baru yang ditulis di tengah proses.

1. Hentikan server dari txAdmin (atau stop service FXServer).
2. Jalankan lagi server dan cek beberapa karakter, inventory, dan kendaraan secara acak.

Restore dari file backup:

zcat /var/backups/fivem/db_2026-10-18_0500.sql.gz | mysql fivem

Buat backup darurat kondisi saat ini, walaupun rusak, supaya kamu bisa mundur kalau restore salah:

mysqldump --single-transaction fivem | gzip > /root/sebelum-restore-$(date +%F_%H%M).sql.gz

Kalau kamu memindahkan server ke mesin baru, buat dulu database dan user aplikasi di mesin tujuan, lalu restore dengan cara yang sama dan sesuaikan set mysql_connection_string di server.cfg.

Restore hanya satu tabel

Kadang yang rusak hanya satu tabel, misalnya setelah script inventory bermasalah. Cara paling aman adalah restore ke database sementara, lalu salin tabel yang dibutuhkan:

mysql -e "CREATE DATABASE fivem_restore"
zcat /var/backups/fivem/db_2026-10-18_0500.sql.gz | mysql fivem_restore
# periksa datanya dulu, lalu salin tabel tertentu sesuai kebutuhan
mysqldump fivem_restore nama_tabel | mysql fivem
mysql -e "DROP DATABASE fivem_restore"

Hati-hati dengan relasi antar tabel. Mengembalikan satu tabel ke kondisi lama bisa membuat data tidak sinkron dengan tabel lain, misalnya item yang merujuk ke kendaraan yang sudah tidak ada.

Uji restore secara berkala

Backup yang tidak pernah diuji belum bisa dianggap backup. Jadwalkan uji restore, misalnya sebulan sekali:

• Restore backup terbaru ke server staging atau database sementara.
• Bandingkan jumlah baris tabel penting, misalnya SELECT COUNT(*) FROM players; (nama tabel tergantung framework).
• Jalankan server staging dan login dengan akun uji.
• Catat berapa lama proses restore. Angka ini membantu kamu memperkirakan downtime saat kejadian nyata.

Opsi lanjutan

• Binary log: dengan binlog aktif, kamu bisa melakukan point-in-time recovery ke menit tertentu sebelum kejadian. Lihat dokumentasi binary log MariaDB.
• Snapshot disk: berguna untuk pemulihan seluruh server, tapi tetap simpan dump logis karena lebih mudah dipindah dan diperiksa.
• Enkripsi backup: database berisi data pemain seperti identifier dan riwayat. Enkripsi backup offsite, misalnya dengan fitur crypt di rclone.
• Monitoring: pasang alert jika backup gagal atau ukuran file tiba-tiba jauh lebih kecil dari biasanya. Lihat monitoring FiveM dengan Prometheus dan Grafana.

Pertanyaan yang sering muncul

Apakah server harus dimatikan saat backup?

Tidak, selama tabel memakai InnoDB dan kamu memakai --single-transaction. Cek engine tabel dengan SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'fivem';. Kalau masih ada tabel MyISAM dari resource lama, pertimbangkan mengubahnya ke InnoDB, karena MyISAM tidak mendukung snapshot transaksional.

Berapa lama backup sebaiknya disimpan?

Tergantung kebutuhan, tapi kombinasi yang umum adalah backup harian selama dua minggu di server, ditambah salinan mingguan yang disimpan lebih lama di offsite. Masalah seperti duplikasi item atau eksploit ekonomi kadang baru ketahuan beberapa minggu kemudian, jadi backup lama bisa berguna untuk investigasi.

Apakah snapshot dari penyedia hosting sudah cukup?

Snapshot membantu, tapi biasanya tersimpan di infrastruktur yang sama dan tidak selalu konsisten untuk database yang sedang aktif. Anggap snapshot sebagai lapisan tambahan, bukan pengganti dump database yang kamu kontrol sendiri.

Checklist singkat

• User database khusus backup dengan hak minimal.
• Dump dengan --single-transaction dan pipefail.
• Backup file server dan txData, tanpa cache.
• Jadwal otomatis lewat cron.
• Salinan offsite dengan kredensial terbatas.
• Uji restore rutin.

Kalau kamu baru menyiapkan server, baca juga cara install FiveM server di Ubuntu dengan txAdmin dan cara install QBCore dengan txAdmin. Untuk gambaran besarnya, mulai dari panduan membuat server FiveM dari nol.

Butuh server dengan disk NVMe dan root penuh untuk menjalankan database dan FXServer? Lihat Hosting FiveM Noctis atau paket lengkap di Noctis Cloud.