FiveM Database Backup และ Restore คืออะไร? วิธีสำรอง MySQL/MariaDB ก่อนอัปเดต Script และกู้ข้อมูลเมื่อ Migration พลาด

August 13, 2026

FiveM Database Backup คือการสร้างสำเนาฐานข้อมูลที่ Resources และ Framework ใช้เก็บข้อมูลถาวร เช่น Characters, Vehicles, Player Settings และข้อมูลระบบ เพื่อให้สามารถ Restore หรือกู้ข้อมูลกลับมาได้ หากเกิดปัญหาจาก Database Migration, Script Update, Schema Error, Server Failure หรือการแก้ข้อมูลผิดพลาด

MariaDB มีระบบ Backup หลายแบบ โดยเอกสารปัจจุบันแยกทั้ง Logical Backup ผ่าน mariadb-dump และ Physical Backup ผ่าน mariadb-backup พร้อมกระบวนการ Restore ที่แตกต่างกัน.

สำหรับ FiveM Server ทั่วไป โดยเฉพาะก่อน Import SQL หรืออัปเดต Resource การทำ Logical Backup เป็นไฟล์ .sql ด้วย mariadb-dump เป็นวิธีที่เข้าใจง่ายและสามารถนำกลับมา Execute ผ่าน mariadb Client เพื่อ Restore ได้.

① ทำไม FiveM ต้อง Backup Database

ลองสมมติ Server มีข้อมูล:

characters
vehicles
player_settings
resource_data
statistics

จากนั้นอัปเดต Script แล้ว Migration ผิด:

ALTER TABLE
↓
Column ถูกเปลี่ยนผิด
↓
Resource อ่านข้อมูลไม่ได้

ถ้ามี Backup:

Migration พัง
↓
หยุดแก้เพิ่ม
↓
Restore Backup
↓
กลับสู่สถานะก่อน Migration

แต่ถ้าไม่มี Backup ข้อมูลเดิมอาจกู้กลับได้ยากหรือไม่สามารถกู้คืนจาก SQL ที่ถูกแก้ไขไปแล้วได้

② Backup กับ Export เหมือนกันไหม

Logical Backup สามารถมองเป็นการ Export Database ออกมาในรูป SQL Statements ที่สามารถนำกลับไปสร้าง Schema และข้อมูลได้

MariaDB ระบุว่า mariadb-dump เป็นโปรแกรมสำหรับสำรองข้อมูล และ Dump Files สามารถ Restore โดยให้ mariadb Client Execute SQL Statements ภายในไฟล์.

ตัวอย่างแนวคิด:

MariaDB Database
↓
mariadb-dump
↓
backup.sql

ตอน Restore:

backup.sql
↓
mariadb client
↓
MariaDB Database

③ Logical Backup คืออะไร

Logical Backup เก็บโครงสร้างและข้อมูลในรูป SQL/Logical Representation

เช่น:

CREATE TABLE ...
INSERT INTO ...
ALTER TABLE ...

MariaDB ระบุว่า mariadb-dump ใช้สร้าง Dump ของ Database และสามารถเลือกสำรองทั้ง Database, หลาย Databases หรือ Tables ตามตัวเลือกที่ใช้.

④ Physical Backup คืออะไร

Physical Backup เก็บ Database Files ในระดับ Storage มากกว่า SQL Statements

MariaDB มีเครื่องมือ:

mariadb-backup

ซึ่งเป็น Open-source Physical Backup Tool สำหรับ MariaDB และรองรับ Online Backup ของ InnoDB รวมถึง Storage Engines อื่นที่เอกสารระบุ.

สำหรับ FiveM Server เล็กถึงกลางที่ต้องการ Backup ก่อน Script Migration การใช้ mariadb-dump มักเข้าใจและ Restore ได้ง่ายกว่า ส่วนระบบขนาดใหญ่สามารถพิจารณา Physical Backup ตาม Infrastructure จริง

⑤ mariadb-dump คืออะไร

mariadb-dump คือ Command-line Backup Client ของ MariaDB สำหรับสร้าง Logical Dump.

ตัวอย่างพื้นฐาน:

mariadb-dump -u USER -p DATABASE > backup.sql

จากนั้นระบบจะถาม Password

อย่าใส่ Password จริงลง Script หรือบทความ Public หากไม่จำเป็น

⑥ ตัวอย่าง Backup Database FiveM

สมมติ Database ชื่อ:

fivem

และ User:

fivem_user

คำสั่ง:

mariadb-dump -u fivem_user -p fivem > fivem-backup.sql

ผลคือ:

fivem-backup.sql

ซึ่งควรเก็บไว้ในพื้นที่ Backup ที่แยกจาก Database Production

⑦ Backup ด้วย --single-transaction คืออะไร

MariaDB แนะนำ --single-transaction สำหรับ Transactional Tables เช่น InnoDB เพื่อสร้าง Consistent Snapshot โดยไม่ต้องใช้ Table Locks เป็นเวลานานเหมือนบาง Backup Modes.

ตัวอย่าง:

mariadb-dump \
  -u fivem_user \
  -p \
  --single-transaction \
  fivem \
  > fivem-backup.sql

สำหรับ FiveM Database ที่ใช้ InnoDB เป็นหลัก ตัวเลือกนี้เป็นสิ่งที่ควรพิจารณา

⑧ --single-transaction ทำให้ Backup ไม่มีผลต่อ Server เลยไหม

ไม่ควรตีความแบบนั้น

แม้ MariaDB ระบุว่า --single-transaction เหมาะกับ InnoDB และช่วยสร้าง Consistent Snapshot โดยไม่ใช้ Locks แบบยาว แต่ Backup ยังใช้:

CPU
Disk I/O
Database Reads
Storage Bandwidth

ดังนั้น Database ใหญ่ควรทำ Backup ในช่วงที่ Load เหมาะสมและ Monitor Server ระหว่าง Backup.

⑨ Backup ก่อน Migration ควรทำเมื่อไร

ควรทำ ก่อน การเปลี่ยน Schema เช่น:

ALTER TABLE
CREATE INDEX
DROP COLUMN
RENAME COLUMN
Import migration.sql
Framework upgrade
Resource SQL update

เพราะเมื่อ Migration เปลี่ยนข้อมูลไปแล้ว การ Backup หลังเกิดปัญหาไม่ใช่ Backup ของสถานะเดิมอีกต่อไป

⑩ Backup ก่อน Update Script จำเป็นทุกครั้งไหม

ถ้า Update ไม่มี Database Change ความเสี่ยงอาจต่ำกว่า

แต่หาก Release มี:

migration.sql
update.sql
ALTER TABLE
CREATE TABLE
DROP
RENAME

ควรถือว่า Backup เป็นขั้นตอนมาตรฐานก่อน Update

โดยเฉพาะ Server ที่มีข้อมูลผู้เล่นจริง

⑪ Backup Resource Files ด้วยไหม

ควรแยก Backup เป็นอย่างน้อย 2 ส่วน:

Database Backup
+
Resource/Config Backup

เพราะ Database Backup อย่างเดียวไม่สามารถคืน:

server.cfg
Resource Version เดิม
Config Files
Custom Code

ได้

ในทางกลับกัน Backup Resource อย่างเดียวก็คืน Characters หรือ Vehicles ใน Database ไม่ได้

⑫ txAdmin Backup Database แทน FiveM Gameplay Database ได้ไหม

ต้องแยกให้ชัด

Cfx.re ระบุว่า txAdmin มี Self-contained Player Database พร้อม Backup Tool และฐานข้อมูลนี้ไม่จำเป็นต้องใช้ MySQL.

ดังนั้น Backup Database ภายใน txAdmin:

≠
Backup Gameplay MySQL/MariaDB Database

ถ้า Framework เก็บ Characters และ Vehicles ใน MariaDB คุณยังต้อง Backup MariaDB แยก

⑬ FiveM Gameplay Database กับ txAdmin Database ต่างกัน

ตัวอย่าง:

txAdmin
↓
Player Manager Data
Bans
Warnings
Whitelist
Notes

ขณะที่ Gameplay Database อาจมี:

Characters
Vehicles
Settings
Framework Data

Cfx.re ระบุ txAdmin มี Player Database ของตัวเอง ดังนั้นอย่าคิดว่า Backup txAdmin แล้วจะได้ Gameplay Tables จาก MariaDB มาด้วย.

⑭ Backup Database เดียวอย่างไร

ตัวอย่าง:

mariadb-dump \
  -u fivem_user \
  -p \
  --single-transaction \
  fivem \
  > fivem-2026-08-13.sql

การใส่วันที่ในชื่อไฟล์ช่วยแยก Versions ของ Backup

ตัวอย่าง Naming:

fivem-2026-08-13.sql
fivem-before-garage-update.sql
fivem-before-framework-v2.sql

⑮ Backup Table เดียวได้ไหม

ได้ mariadb-dump สามารถสำรองเฉพาะ Table ได้ตามรูปแบบของ Utility.

ตัวอย่าง:

mariadb-dump \
  -u fivem_user \
  -p \
  fivem \
  characters \
  > characters-backup.sql

เหมาะเมื่อกำลังแก้เพียง Table เดียวและต้องการ Backup เพิ่มอีกชั้น

⑯ ควร Backup ทั้ง Database หรือ Table เดียว

ก่อน Migration สำคัญควรมี:

Full Database Backup

ก่อน

จากนั้นอาจ Backup Table ที่กำลังแก้เพิ่มเพื่อ Restore แบบเจาะจงได้ง่าย

อย่าใช้ Table-only Backup เป็น Backup เพียงชุดเดียวหาก Migration อาจแตะ Relations หรือ Tables อื่นด้วย

⑰ Backup ทุก Database ใน MariaDB ได้ไหม

mariadb-dump รองรับการ Dump หลาย Databases และ All Databases ผ่าน Options ของ Utility.

อย่างไรก็ตาม FiveM Server ทั่วไปควรรู้ก่อนว่า Gameplay Database ใดเป็นของ Server เพื่อไม่สร้าง Backup ขนาดใหญ่เกินจำเป็น

⑱ Backup File ควรเก็บที่ไหน

อย่าเก็บ Backup เพียง:

Database Server Disk เดียว

เพราะถ้า Disk เสีย:

Production Database
+
Backup

อาจหายพร้อมกัน

แนวทางที่แข็งแรงกว่าคือมี Copy แยก เช่น:

Local Backup
+
อีก Storage/Server

โดยต้องดูแล Security เพราะ SQL Dump อาจมีข้อมูลภายในของ Server

⑲ Backup File มีข้อมูลสำคัญไหม

มี

SQL Dump อาจประกอบด้วย:

Identifiers
Character Data
Vehicle Data
Configuration
Internal IDs
Resource Data

ดังนั้น Backup File ควรได้รับสิทธิ์เข้าถึงเฉพาะผู้ดูแลที่จำเป็น

อย่า Upload Database Dump แบบ Public เพื่อขอความช่วยเหลือ

⑳ Backup File ควรใส่ใน GitHub ไหม

โดยทั่วไปไม่ควรใส่ Production Database Dump ลง Public Repository

Resource Source Code กับ Production Data เป็นคนละประเภท

ถ้าต้องแชร์ Schema ให้ Export เฉพาะ Structure หรือทำ Test Dataset ที่ไม่มีข้อมูลจริงแทน

㉑ Restore คืออะไร

Restore คือการนำข้อมูลจาก Backup กลับเข้าสู่ Database

สำหรับ Dump Files ที่สร้างด้วย mariadb-dump MariaDB ระบุว่าสามารถให้ mariadb Client Execute SQL Statements ภายใน Dump File เพื่อกู้ข้อมูลกลับ.

㉒ ตัวอย่าง Restore Database

สมมติมี:

fivem-backup.sql

และ Database fivem มีอยู่แล้ว

สามารถใช้แนวคิด:

mariadb \
  -u fivem_user \
  -p \
  fivem \
  < fivem-backup.sql

MariaDB Restore Guide ระบุหลักการนี้ว่าเป็นการส่ง Dump File ให้ mariadb Client Execute.

㉓ Restore ทับ Production ทันทีดีไหม

ไม่ควรเป็นขั้นตอนแรก

ก่อน Restore Production ให้:

① หยุดการเขียนข้อมูลใหม่
② Backup Database ปัจจุบันอีกชุด
③ Restore ลง Test Database
④ ตรวจข้อมูล
⑤ วาง Recovery Plan
⑥ จึง Restore Production

เพราะ Restore ผิด File สามารถทำให้สถานการณ์แย่กว่าเดิม

㉔ ทำไมต้อง Backup Database ที่พังก่อน Restore

แม้ Database ปัจจุบันจะมีปัญหา ก็ควรเก็บ Snapshot/Backup ไว้ก่อน

เพราะอาจมีข้อมูลใหม่หลัง Backup เก่าที่ต้องนำกลับบางส่วนภายหลัง

ตัวอย่าง:

Backup เก่า
= 12:00

Database พัง
= 17:00

ถ้าลบทิ้งทันที คุณอาจเสียข้อมูลช่วง:

12:00–17:00

โดยไม่มีโอกาสตรวจหรือกู้บางส่วน

㉕ Restore ลง Test Database ทำอย่างไร

แนวคิด:

Production
= fivem

Test Restore
= fivem_restore_test

สร้าง Database ทดสอบ จากนั้น Restore Backup เข้า Database นั้นก่อน

แล้วตรวจ:

Tables ครบ?
Rows ครบ?
Characters เปิดได้?
Vehicles อยู่?
Indexes อยู่?
Resource Queries ทำงาน?

ก่อนแตะ Production

㉖ Restore สำเร็จไม่ได้หมายความว่า Resource ใช้งานได้แน่นอน

Dump สามารถ Restore SQL สำเร็จ แต่ Resource Version อาจไม่ตรงกับ Schema

ดังนั้นต้องตรวจ:

Database Version
+
Resource Version
+
Migration Version

ให้ตรงกัน

ถ้า Restore Database เก่ากลับมา แต่ยังใช้ Script Version ใหม่ที่ต้องการ Column ใหม่ Resource อาจกลับมา Unknown column อีกครั้ง

㉗ Rollback Script และ Database ต้องไปด้วยกัน

ตัวอย่าง:

Resource v5
+
Database Schema v5

Migration พังแล้ว Restore:

Database Schema v4

แต่ยังใช้:

Resource v5

อาจ Error

Recovery ที่ถูกต้องอาจต้อง:

Resource v4
+
Database v4

พร้อมกัน

㉘ Restore Table เดียวได้ไหม

MariaDB Restore Documentation มีแนวทางสำหรับ Selective Restore ของ Table จาก Dump Files และการ Restore แบบเจาะจง.

เหมาะเมื่อ:

characters ปกติ
vehicles ปกติ
player_settings พัง

และคุณต้องการแก้เฉพาะ player_settings

แต่ต้องตรวจ Foreign Keys และ Relations ก่อน Restore แยก

㉙ Restore Table เดียวต้องระวังอะไร

ถ้า Tables เชื่อมกัน:

characters.id
↓
vehicles.character_id

การ Restore Table หนึ่งจากคนละเวลาอาจทำให้ข้อมูลสอง Tables ไม่สอดคล้องกัน

ดังนั้นต้องตรวจ Referential/Application Consistency ก่อน Partial Restore

㉚ Physical Backup ด้วย mariadb-backup คืออะไร

MariaDB ระบุว่า mariadb-backup เป็นเครื่องมือ Physical Online Backup สำหรับ MariaDB โดยรองรับ InnoDB และ Storage Engines อื่นตาม Documentation.

แนวคิด:

Database Files
↓
mariadb-backup
↓
Physical Backup Directory

เหมาะกับ Backup ขนาดใหญ่หรือ Recovery Workflow ที่ต้องการ Physical Backup

㉛ mariadb-backup Restore ต่างจาก SQL Dump

Logical Dump:

backup.sql
↓
mariadb client

Physical Backup:

backup directory
↓
prepare
↓
copy-back / move-back

MariaDB ระบุว่า Physical Backup ต้องผ่าน --prepare ก่อน Restore และสามารถใช้ --copy-back หรือ --move-back เพื่อคืนไฟล์ไปยัง Data Directory.

㉜ ทำไม mariadb-backup ต้อง --prepare

MariaDB ระบุว่าก่อน Restore Physical Backup ต้องใช้:

--prepare

เพื่อทำให้ Full Backup มีความสอดคล้อง ณ จุดเวลาและเตรียมข้อมูลก่อน Copy Back.

ดังนั้นอย่า Copy Physical Backup กลับ Database Directory ตรงๆ โดยข้ามขั้นตอนนี้

㉝ ตัวอย่าง Workflow Physical Backup

แนวคิด:

① mariadb-backup --backup
② ตรวจ Backup
③ mariadb-backup --prepare
④ หยุด MariaDB ตาม Recovery Procedure
⑤ --copy-back
⑥ ตรวจ Ownership/Permissions
⑦ Start MariaDB
⑧ Verify

รายละเอียดต้องอิง MariaDB Version และ Official Full Backup/Restore Procedure ที่ใช้งานจริง.

㉞ FiveM Server เล็กควรใช้แบบไหน

หาก Database ยังไม่ใหญ่มากและต้องการ:

Backup ก่อน Script Update
Backup ก่อน Migration
Restore Table/Database ได้ง่าย

Logical Dump ด้วย mariadb-dump เป็นจุดเริ่มต้นที่เข้าใจง่าย

ถ้า Database ใหญ่ขึ้นและ Recovery Time สำคัญมาก ค่อยพิจารณา mariadb-backup และ Backup Architecture ที่เหมาะกับ Production

㉟ Backup ระหว่าง Server เปิดได้ไหม

MariaDB ระบุว่า mariadb-dump --single-transaction เหมาะสำหรับ Transactional Tables อย่าง InnoDB และช่วยสร้าง Consistent Snapshot โดยไม่ล็อก Tables เป็นเวลานาน.

แต่หากกำลังทำ Backup ก่อน Migration วิธีที่ปลอดภัยกว่าในเชิง Operational คือ:

หยุด Migration
↓
ลด/หยุด Writes ตาม Maintenance Plan
↓
Backup
↓
Verify
↓
ค่อย Migration

เพื่อให้ Recovery Point ชัดเจน

㊱ ควรปิด FiveM ก่อน Backup ไหม

ขึ้นกับ Backup Method และระดับ Consistency ที่ต้องการ

สำหรับ Routine Online Backup ของ InnoDB สามารถใช้ --single-transaction ตาม MariaDB Guidance ได้.

แต่ก่อน Major Migration การทำ Maintenance Window ช่วยให้ไม่มี Gameplay Data ใหม่ถูกเขียนระหว่างจุด Backup กับจุดเริ่ม Migration

㊲ txAdmin ช่วย Maintenance ได้ไหม

Cfx.re ระบุว่า txAdmin สามารถ Start/Stop/Restart Server Instance และ Resources รวมถึงมี Scheduled Restart Features.

ดังนั้น Server Owner สามารถใช้ txAdmin จัดช่วง Maintenance ได้ แต่ Backup Gameplay MariaDB ยังต้องทำด้วย Database Backup Tool แยก

㊳ Restart Resource หลัง Restore ต้องทำไหม

ถ้า Resource โหลด Database Data เข้า Memory ตอน Start อยู่แล้ว การ Restore Database ระหว่าง Resource ยังทำงานอาจทำให้ Runtime Cache ไม่ตรงกับ Database

FiveM มี Server Command:

restart [resourceName]

และ:

ensure [resourceName]

สำหรับ Restart/Start Resource.

แต่ Resource หลักควร Restart ใน Maintenance Context เพราะอาจมี Dependencies และ Runtime State

㊴ อย่า Restore Database ขณะ Resources ยังเขียนข้อมูล

ตัวอย่างปัญหา:

Restore เริ่ม
↓
Resource ยัง Autosave
↓
ข้อมูลใหม่ถูกเขียน
↓
Restore เขียนข้อมูลเก่า
↓
State ปะปน

จึงควรควบคุม Writes ระหว่าง Critical Restore

สำหรับ Production Recovery ที่จริงจัง ควรมี Maintenance Procedure ชัดเจน

㊵ Backup ก่อน Resource Restart จำเป็นไหม

ไม่จำเป็นสำหรับ Restart ทั่วไป

แต่ถ้า Restart เป็นส่วนหนึ่งของ:

Resource Update
Database Migration
Framework Upgrade

ควร Backup ก่อน Changes เหล่านั้น

ไม่ใช่เพราะคำสั่ง restart เองทำ Database หาย แต่เพราะ Code/Schema ใหม่อาจเปลี่ยน Persistent Data

㊶ Backup Schedule ควรมีไหม

ควร

Backup ก่อน Migration ช่วยเรื่อง Planned Change แต่ไม่ได้ช่วยกรณี:

Database Failure
Resource Bug
Admin ลบข้อมูลผิด
Disk Problem
Script เขียนข้อมูลผิด

ถ้าเหตุการณ์เกิดก่อน Manual Backup

จึงควรมี Routine Automated Backup แยกจาก Pre-update Backup

㊷ ควร Backup วันละครั้งพอไหม

ไม่มีค่าตายตัวสำหรับทุก FiveM Server

ถามว่า:

ถ้า Database หายตอนนี้
ยอมเสียข้อมูลย้อนหลังได้กี่ชั่วโมง?

ถ้ายอมเสียได้ไม่เกิน 1 ชั่วโมง Backup วันละครั้งย่อมไม่ตอบ Requirement นั้น

นี่คือแนวคิด Recovery Point ที่ Server Owner ควรกำหนดตามความสำคัญของข้อมูล

㊸ Backup Retention คืออะไร

คือการกำหนดว่าจะเก็บ Backup ย้อนหลังกี่ชุด

ตัวอย่าง:

Daily Backup
→ 7 วัน

Weekly Backup
→ 4 สัปดาห์

Pre-migration Backup
→ เก็บจนยืนยัน Update เสถียร

อย่าเก็บเพียง:

latest.sql

แล้วเขียนทับทุกครั้ง เพราะหาก Backup ล่าสุดเกิดหลังข้อมูลเสีย คุณอาจไม่มี Backup ก่อนปัญหาเหลืออยู่

㊹ ตั้งชื่อ Backup อย่างไรดี

ตัวอย่าง:

fivem-2026-08-13-1700.sql
fivem-before-framework-update.sql
fivem-before-vehicle-migration.sql

หลักคือให้รู้:

Database ไหน
วันที่/เวลา
ก่อนหรือหลัง Change อะไร

ทันที

㊺ Backup Compression ทำได้ไหม

Logical Dumps เป็น Text และสามารถนำไปจัดเก็บแบบ Compress ด้วยระบบปฏิบัติการหรือ Backup Infrastructure ได้

แต่ Recovery Procedure ต้องรู้ว่าต้อง Extract/Stream อย่างไรก่อน Restore

อย่ามี Backup ที่ Compress ได้แต่ไม่มีใครรู้วิธี Restore

㊻ Backup Encryption สำคัญไหม

ถ้า Backup ถูกเก็บนอก Server หรือใน Storage ที่หลายคนเข้าถึง การเข้ารหัสและ Access Control ควรถูกพิจารณา

SQL Dump อาจมีข้อมูลภายใน Server จึงไม่ควรถูกปฏิบัติเป็นไฟล์ธรรมดาที่แชร์ได้ทั่วไป

㊼ Backup สำเร็จดูจาก File มีขนาดไม่เป็นศูนย์พอไหม

ไม่พอ

อย่างน้อยควรตรวจ:

Command Exit สำเร็จ?
File ถูกสร้าง?
ขนาดสมเหตุสมผล?
SQL Structure มี?
Restore Test ผ่าน?

สิ่งที่พิสูจน์ Backup ได้ดีที่สุดคือ:

Restore แล้วใช้งานได้จริง

ไม่ใช่เพียงมีไฟล์ .sql

㊽ วิธีทดสอบ Backup ที่ดีที่สุด

สร้าง Test Database แล้ว:

Backup Production Copy
↓
Restore Test
↓
ตรวจ Row Counts
↓
ตรวจ Tables
↓
Start Resource กับ Test Environment
↓
ตรวจ Queries

ถ้าผ่าน แปลว่า Backup มีคุณค่าด้าน Recovery มากขึ้นกว่าการมีไฟล์อย่างเดียว

㊾ Backup File เสียดูอย่างไร

สัญญาณเช่น:

ไฟล์ขนาดผิดปกติ
Dump Command ถูก Interrupt
Disk เต็ม
Restore แล้ว SQL Error
Table/Rows หาย

จึงควร Monitor Exit Status และ Storage Capacity ของระบบ Backup

㊿ Disk เต็มระหว่าง Backup อันตรายไหม

Backup อาจสร้างไฟล์ไม่ครบ

ดังนั้นก่อน Dump Database ใหญ่ควรตรวจพื้นที่ Storage

อย่าปล่อย Backup Files เติบโตไปเรื่อยๆ โดยไม่มี Retention Policy เพราะท้ายที่สุดอาจทำ Disk เต็มและกระทบ Production Server

51. Backup ไป Disk เดียวกับ MariaDB มีข้อเสียอะไร

ถ้า Storage Failure เกิดที่ Disk นั้น:

Database Files
+
Backup Files

อาจหายพร้อมกัน

ควรมี Second Copy อยู่คนละ Failure Domain เมื่อข้อมูลมีความสำคัญ

52. Database Backup กับ VPS Snapshot ต่างกันอย่างไร

Database Dump:

Database-aware Logical Backup

VPS/Volume Snapshot:

Infrastructure-level Snapshot

แต่ละแบบมี Use Case ต่างกัน

สำหรับ Database Recovery อย่างละเอียด Logical/Physical Database Backup ที่ MariaDB รองรับโดยตรงช่วยให้จัดการข้อมูลได้เจาะจงกว่า Snapshot เพียงอย่างเดียว.

53. Backup เฉพาะก่อน Update พอไหม

ไม่

Pre-update Backup ป้องกัน:

Migration พลาด

แต่ Routine Backup ป้องกันเหตุการณ์ที่เกิดระหว่างวัน

Server ที่มีข้อมูลผู้เล่นจริงควรมีทั้ง:

Scheduled Backup
+
Pre-change Backup

54. Point-in-Time Recovery คืออะไร

MariaDB รองรับแนวคิด Point-in-Time Recovery โดยใช้ Backup ร่วมกับ Binary Logs เพื่อกู้ Database ไปยังช่วงเวลาที่ต้องการ แทน Restore ได้เฉพาะเวลาที่ Backup ถูกสร้าง.

ตัวอย่าง:

Full Backup = 12:00
Problem = 15:37

ด้วย Binary Logs ที่เหมาะสม สามารถออกแบบ Recovery ให้เข้าใกล้ช่วงก่อนเกิดปัญหาได้มากกว่า Restore Backup 12:00 อย่างเดียว

55. FiveM Server ทุกเครื่องต้องทำ Point-in-Time Recovery ไหม

ไม่จำเป็นสำหรับทุก Server

ระบบนี้เพิ่ม:

Configuration
Storage
Monitoring
Recovery Complexity

แต่ Server ที่มีข้อมูลจำนวนมากและต้องลด Data Loss อาจพิจารณา Binary Log/PITR Architecture

MariaDB มี Documentation และแนวทาง Point-in-Time Recovery แยกโดยเฉพาะ.

56. Backup ก่อน DELETE ข้อมูลสำคัญไหม

ควร

โดยเฉพาะ Query เช่น:

DELETE FROM `characters`
WHERE ...

หรือ:

TRUNCATE TABLE ...

ถ้า WHERE ผิด Data อาจหายจำนวนมาก

ก่อน Maintenance แบบ Destructive ควรสร้าง Backup ที่ระบุชัดว่าเป็น:

before-delete

57. Backup ก่อน DROP COLUMN สำคัญไหม

สำคัญมาก เพราะ:

DROP COLUMN

ลบ Column ออกจาก Schema

หากข้อมูลใน Column ถูกลบแล้ว การ Add Column กลับไม่ได้ทำให้ข้อมูลเก่ากลับมาเอง

Recovery ต้องอาศัย Backup ก่อน Drop

58. Backup ก่อน CREATE INDEX จำเป็นไหม

CREATE INDEX ไม่ได้มีจุดประสงค์ลบ Player Data แต่เป็น Schema Operation และ Production Change ยังควรมี Backup ตามระดับความสำคัญของระบบ

โดยเฉพาะหากกำลังทำ Changes หลายอย่างพร้อมกัน เช่น:

ALTER TABLE
+
CREATE INDEX
+
Data Migration

59. Backup ก่อนเปลี่ยน Database Engine สำคัญไหม

สำคัญมาก

การย้าย:

MySQL
→ MariaDB

หรือ Version Upgrade เป็น Infrastructure Change ที่ใหญ่กว่า Resource Migration

ควรมี:

Backup
Restore Test
Compatibility Test
Rollback Plan

ก่อน

oxmysql เป็น MySQL Resource สำหรับ FXServer แต่ Compatibility ของ Gameplay Resources และ Database Schema ยังต้องตรวจแยก.

60. Backup ก่อน Update oxmysql จำเป็นไหม

การ Update oxmysql ไม่ได้หมายความว่าจะเปลี่ยน Gameplay Schema โดยอัตโนมัติ แต่ Production Database ที่สำคัญควรมี Routine Backup อยู่แล้ว

หาก Update Database Layer พร้อม Framework/Resources อื่นใน Maintenance เดียวกัน การเก็บ Pre-maintenance Backup เป็นแนวทางที่เหมาะสม

61. Restore แล้ว oxmysql ต่อไม่ได้เกี่ยวไหม

Restore Data กับ Database Connection เป็นคนละ Layer

ตรวจ:

MariaDB Running?
Connection String ถูก?
User มี Permission?
Database Name ถูก?

ก่อน

oxmysql ทำหน้าที่เป็น Database Resource สำหรับ FXServer ที่สื่อสารกับ MySQL/MariaDB; Restore ไม่ได้แก้ Connection Configuration ให้เอง.

62. Restore แล้ว Unknown Column เกิดได้ไหม

ได้ ถ้า:

Backup Schema = v4
Resource Code = v5

Resource v5 อาจต้องการ Column ที่ Backup v4 ยังไม่มี

นี่คือเหตุผลที่ต้อง Backup:

Database
+
Resource Version

คู่กันก่อน Major Update

63. Restore แล้ว Duplicate Data เกิดได้ไหม

เป็นไปได้ถ้า Restore เข้า Database ที่ยังมีข้อมูลเดิม แล้ว Dump File ทำ Inserts เพิ่มโดยไม่ Reset/Plan ก่อน

ดังนั้นต้องรู้ว่า Restore Strategy คือ:

Replace Database

หรือ:

Merge/Partial Restore

ก่อน Execute Dump

อย่า Restore Blindly เข้า Production Database ที่ยังรับ Writes อยู่

64. Restore ควรตรวจอะไรหลังเสร็จ

ตรวจอย่างน้อย:

Database เปิดได้
Tables ครบ
Row Counts สมเหตุสมผล
Character Data อยู่
Vehicle Data อยู่
Indexes/Constraints ตาม Backup
Resource Queries ไม่มี Error
Player Join ได้
Character Load ได้
Save Data ได้
Resource Restart แล้วข้อมูลยังอยู่
Server Console ไม่มี SQL Error

65. ตรวจ Row Count หลัง Restore อย่างไร

ตัวอย่าง:

SELECT COUNT(*)
FROM `characters`;

และ:

SELECT COUNT(*)
FROM `vehicles`;

เปรียบเทียบกับค่าที่บันทึกไว้ก่อน Backup/Restore

ไม่ใช่หลักฐานสมบูรณ์ แต่ช่วยตรวจความผิดปกติขั้นต้น

66. ควรเก็บ Backup Metadata ไหม

มีประโยชน์ เช่น:

Backup Date
Database Name
Resource Version
Framework Version
Reason
File Size
Restore Tested?

ตัวอย่าง:

2026-08-13 17:00
Database: fivem
Before: framework v5 migration
File: fivem-before-v5.sql
Restore test: PASS

เวลามีปัญหาจะเลือก Backup ได้แม่นกว่า

67. Backup Automation ดีไหม

ดีสำหรับ Routine Backup เพราะลดความเสี่ยงจากการลืมทำด้วยมือ

แต่ระบบ Automation ควรมี:

Scheduling
Retention
Failure Alert
Storage Monitoring
Restore Test

ไม่ใช่เพียงตั้ง Script ให้สร้างไฟล์ทุกคืนโดยไม่มีใครตรวจว่า Backup สำเร็จจริง

68. Backup ก่อน Update Checklist

ก่อนอัปเดต Resource:

อ่าน Release Notes
ตรวจว่ามี Migration หรือไม่
ระบุ Database ที่ Resource ใช้
Backup Resource Files
Backup server.cfg/Config ที่เกี่ยวข้อง
Dump Database
ตรวจ Backup File
Copy Backup ไปอีก Storage
Restore Test หาก Change สำคัญ
จด Resource Version เดิม
จด Database/Schema Version
เข้า Maintenance
ค่อย Update Resource
Run Migration
Verify
Test Read/Write
Monitor Errors
เก็บ Backup เดิมไว้จนยืนยันระบบเสถียร

69. Restore Checklist

เมื่อ Migration พัง:

หยุดเปลี่ยน Schema เพิ่ม
เก็บ Error Logs
หยุด Writes เมื่อจำเป็น
Backup Database ปัจจุบันอีกครั้ง
หา Backup ก่อน Migration
ตรวจวันที่/เวลา Backup
ตรวจ Resource Version ที่ตรงกับ Backup
Restore ลง Test Database
Verify Tables
Verify Rows
Verify Character Data
Verify Vehicle Data
Test Resource
เตรียม Rollback Resource Files
Maintenance Production
Restore
Start Database
Start/Restart Resources ตาม Dependency
ตรวจ Console
Test Player Join
Test Save
Monitor หลังเปิด Server

70. ตาราง Backup FiveM ที่ควรรู้

วิธี	เหมาะกับ
`mariadb-dump`	Logical Backup / Pre-migration
`mariadb-dump --single-transaction`	Consistent Logical Dump สำหรับ InnoDB
Table-only dump	Backup Table ก่อนแก้เฉพาะจุด
`mariadb-backup`	Physical Backup / Database ใหญ่
Binary Logs	Point-in-Time Recovery
txAdmin Backup	txAdmin Player Database ไม่ใช่ Gameplay MariaDB

MariaDB รองรับทั้ง Logical Backup, Physical Backup และ Recovery Methods หลายระดับ ขณะที่ Cfx.re ระบุว่า txAdmin มี Player Database/Backup ของตัวเองแยกจาก MySQL Gameplay Database.

FiveM Database Backup ทำยังไง

สำหรับ MariaDB Logical Backup ตัวอย่างพื้นฐาน:

mariadb-dump \
  -u fivem_user \
  -p \
  --single-transaction \
  fivem \
  > fivem-backup.sql

MariaDB ระบุว่า mariadb-dump เป็น Backup Utility และ --single-transaction เหมาะสำหรับ Consistent Backup ของ Transactional Tables เช่น InnoDB.

FiveM Database Restore ทำยังไง

สำหรับ Dump File:

mariadb \
  -u fivem_user \
  -p \
  fivem \
  < fivem-backup.sql

MariaDB Restore Guide ระบุว่าการ Restore Dump ทำโดยให้ mariadb Client Execute SQL Statements จาก Dump File.

FiveM Backup ก่อนอัปเดต Script จำเป็นไหม

หาก Resource Update มี Database Migration ควรทำอย่างยิ่ง

เพราะ Migration อาจเปลี่ยน:

Tables
Columns
Indexes
Constraints
Existing Data

และ Backup เป็น Recovery Point ที่ใช้ย้อนกลับเมื่อ Schema ใหม่มีปัญหา

FiveM Backup ก่อน ALTER TABLE จำเป็นไหม

ควร โดยเฉพาะ Production Database

ALTER TABLE สามารถเปลี่ยน Schema ของ Tables และ Migration บางชนิดอาจเป็น Destructive Change

Backup ก่อนแก้ช่วยให้ยังมี Copy ของข้อมูลก่อน Schema ถูกเปลี่ยน

FiveM mariadb-dump กับ mariadb-backup ต่างกันอย่างไร

mariadb-dump:

Logical Backup
→ SQL

mariadb-backup:

Physical Backup
→ Database Files

MariaDB มี Documentation แยกสำหรับทั้งสอง Backup Strategies.

FiveM Backup ขณะ Server เปิดได้ไหม

สำหรับ InnoDB MariaDB แนะนำ --single-transaction สำหรับ Consistent Logical Backup โดยไม่ต้องใช้ Lock Tables แบบยาว.

แต่ก่อน Major Migration การเข้า Maintenance จะทำให้ Recovery Point ชัดและลด Writes ระหว่าง Change

FiveM Backup ต้องปิด MariaDB ไหม

ไม่จำเป็นสำหรับ Logical Dump ปกติด้วย mariadb-dump และ MariaDB ยังมี Online Physical Backup ผ่าน mariadb-backup สำหรับ InnoDB ตาม Documentation.

อย่างไรก็ตาม Restore Physical Backup มีขั้นตอนเฉพาะของมันและไม่ควรทำแบบ Copy Files ทับขณะ Database ทำงานโดยไม่มี Procedure ที่ถูกต้อง

FiveM Backup ต้องปิด FXServer ไหม

Routine Backup ไม่จำเป็นเสมอไป แต่ก่อน Migration สำคัญการเข้าสู่ Maintenance เพื่อลด Writes เป็นแนวทางที่จัดการง่ายกว่า

txAdmin สามารถ Start/Stop/Restart Server Instance และ Resources ได้ตาม Cfx.re Documentation.

FiveM Backup SQL File เปิดดูได้ไหม

ได้ Logical Dump เป็น SQL Representation ของ Database

แต่ไฟล์อาจมีข้อมูลจำนวนมากและข้อมูลภายใน Server จึงควรเปิด/แชร์อย่างระมัดระวัง

FiveM Restore Backup แล้วข้อมูลใหม่หายไหม

ถ้า Restore Backup เก่ากลับมาแทน Production State ข้อมูลที่เกิดหลังเวลาของ Backup อาจไม่อยู่ใน Backup นั้น

ตัวอย่าง:

Backup = 13:00
Restore = 18:00

ข้อมูลช่วงหลัง 13:00 อาจต้องกู้จากแหล่งอื่นหรือ Point-in-Time Recovery หากมีระบบ Binary Logs ที่พร้อมใช้งาน.

FiveM Restore เฉพาะ Table ได้ไหม

ทำได้ตาม Backup/Restore Strategy และ MariaDB มีแนวทาง Selective Restore จาก Dump Files.

แต่ต้องตรวจ Relations กับ Tables อื่นก่อน เพราะ Restore คนละเวลาสามารถสร้าง Data Inconsistency ได้

FiveM txAdmin Backup รวม MySQL ไหม

ไม่ควรถือว่าใช่

Cfx.re ระบุว่า txAdmin มี Self-contained Player Database พร้อม Backup Tool และไม่ต้องใช้ MySQL ดังนั้น Database นั้นเป็นคนละระบบกับ Gameplay MariaDB ที่ Framework/Resources อาจใช้งาน.

FiveM Backup กี่ชุดถึงพอ

ไม่มีตัวเลขเดียวสำหรับทุก Server

อย่างน้อยควรหลีกเลี่ยงการมี Backup เพียงไฟล์ล่าสุดไฟล์เดียว

ออกแบบ Retention ให้มีหลาย Recovery Points และเก็บ Pre-migration Backup จนยืนยันว่า Version ใหม่ใช้งานได้จริง

FAQ FiveM Database Backup และ Restore

FiveM Database Backup คืออะไร

คือสำเนาของ Persistent Database ที่สามารถใช้ Restore เมื่อเกิด Migration Error, Data Loss หรือ Database Failure

FiveM ใช้ mariadb-dump Backup ได้ไหม

ได้ MariaDB มี mariadb-dump สำหรับสร้าง Logical Backup ของ Database และ Tables.

`--single-transaction` คืออะไร

เป็น Option ที่ MariaDB แนะนำสำหรับ Transactional Tables เช่น InnoDB เพื่อสร้าง Consistent Snapshot โดยไม่ใช้ Table Locks เป็นเวลานาน.

Restore `.sql` ยังไง

ใช้ MariaDB Client Execute SQL Statements ภายใน Dump File เช่น Redirect File เข้า mariadb.

Backup ต้องทำก่อน Migration ไหม

ควรทำก่อนทุก Migration สำคัญ เพราะเป็น Recovery Point ก่อน Schema/Data ถูกเปลี่ยน

Backup แล้วต้องทดสอบ Restore ไหม

ควร เพราะการมี Backup File ไม่ได้ยืนยันว่า Restore สำเร็จ การ Restore ลง Test Database เป็นวิธีตรวจที่มีประโยชน์มากกว่า

txAdmin Backup คือ Backup MySQL ของ FiveM หรือไม่

ไม่ควรเหมารวม Cfx.re ระบุว่า txAdmin มี Self-contained Player Database พร้อม Backup Tool ของตัวเองและไม่ต้องใช้ MySQL.

mariadb-backup คืออะไร

เป็น Physical Backup Tool ของ MariaDB สำหรับ Online Backup ของ InnoDB และ Storage Engines อื่นตามที่ MariaDB รองรับ.

Physical Backup Restore ต้องทำอะไร

MariaDB ระบุว่าต้อง --prepare Backup ก่อน แล้วจึงใช้ขั้นตอนเช่น --copy-back หรือ --move-back ตาม Recovery Procedure.

Restore Backup เก่าแล้วข้อมูลใหม่จะอยู่ไหม

ข้อมูลที่เกิดหลัง Backup ไม่ได้อยู่ใน Backup นั้น เว้นแต่มี Recovery Mechanism เพิ่ม เช่น Binary Logs/PITR.

Backup Database อย่างเดียวพอไหม

สำหรับ Major Update ควรเก็บทั้ง Database Backup และ Resource/Config Version เดิม เพราะ Code Version กับ Schema Version ต้องสามารถย้อนกลับให้ตรงกัน

Backup เก็บไว้ในเครื่องเดียวกับ Database ดีไหม

ดีกว่าไม่มี Backup แต่ควรมี Copy แยก Storage/Failure Domain เพราะ Disk Failure สามารถกระทบทั้ง Production และ Backup ที่อยู่ Disk เดียวกันได้

ประเด็นสำคัญ

FiveM Database Backup ควรเป็นขั้นตอนมาตรฐานก่อน:

Script Update
Database Migration
ALTER TABLE
DROP/RENAME
Framework Upgrade
Database Upgrade

สำหรับ MariaDB สามารถเริ่มด้วย Logical Backup เช่น:

mariadb-dump \
  -u fivem_user \
  -p \
  --single-transaction \
  fivem \
  > fivem-backup.sql

แล้ว Restore ผ่าน:

mariadb \
  -u fivem_user \
  -p \
  fivem \
  < fivem-backup.sql

MariaDB มี Documentation รองรับทั้ง mariadb-dump, Restore จาก Dump Files และ Physical Backup ด้วย mariadb-backup.

สิ่งที่สำคัญที่สุดไม่ใช่แค่ “มี Backup” แต่ต้องมี Backup ที่:

สร้างสำเร็จ
เก็บหลายชุด
อยู่ในที่ปลอดภัย
รู้ว่าเป็น Backup เวลาไหน
และ Restore ทดสอบได้จริง

ก่อน Restore Production ให้ Restore ลง Test Database ก่อนเมื่อเป็นไปได้ และหาก Rollback Database Schema ไป Version เก่า ต้องตรวจ Resource Version ให้ตรงกันด้วย ไม่เช่นนั้น Script ใหม่อาจเรียก Table หรือ Column ที่ Backup เก่ายังไม่มี

สำหรับผู้อ่าน comsiam ให้จำสูตร “Backup → Verify → Migration → Test → Restore เมื่อจำเป็น” และ comsiam แนะนำว่าอย่ารอให้ Database พังก่อนจึงเริ่มคิดเรื่อง Backup เพราะ Backup ที่มีค่าที่สุดคือ Backup ที่ถูกสร้างก่อนความผิดพลาด และถูกทดสอบแล้วว่าสามารถกู้ FiveM Server กลับมาใช้งานได้จริง