Backup และ Restore MySQL บน Hosting ด้วย phpMyAdmin

Database คือหัวใจของเว็บไซต์ส่วนใหญ่ ไม่ว่าจะเป็น WordPress, WooCommerce, หรือระบบสมาชิกที่พัฒนาเอง ถ้าข้อมูลใน Database หายหรือเสียหายโดยไม่มี Backup ผลที่ตามมาอาจเป็นหายนะ บทความนี้สอนวิธี Backup และ Restore MySQL บน Web Hosting ผ่าน phpMyAdmin และ DirectAdmin Backup Tool ทำได้เองโดยไม่ต้องใช้ Command Line

1. ทำไมต้อง Backup Database?

ปัญหาที่พบบ่อยซึ่งทำให้ Database เสียหายหรือสูญหาย:

• อัพเดท WordPress Plugin แล้ว Database Structure เปลี่ยนไม่ตรงกัน
• รัน SQL Query ผิดพลาด เช่น DELETE FROM users โดยไม่มี WHERE
• เว็บถูก Hack และ Malware ลบหรือเข้ารหัสข้อมูล
• การ Migrate Hosting ที่ Export/Import ผิดพลาด
• Space เต็มทำให้ Database Corrupt

แม้ AsiaGB จะมีระบบ Backup อัตโนมัติ 2 ครั้งต่อเดือน (วันที่ 1 และ 15) แต่ ไม่สามารถแทนที่ Backup ที่คุณทำเองได้ เพราะ Backup ของ AsiaGB เก็บ 1 ปีแต่ถ่าย Snapshot เดือนละ 2 ครั้ง หากข้อมูลหายระหว่างนั้นจะ Restore ได้เฉพาะ ณ วันที่ Backup ล่าสุดเท่านั้น

2. วิธี Export Database ด้วย phpMyAdmin

phpMyAdmin เป็นวิธีที่สะดวกสุดสำหรับ Backup Database ขนาดเล็กถึงกลาง (แนะนำไม่เกิน 50MB)

ขั้นตอนการ Export

1. Login เข้า DirectAdmin → ไปที่ MySQL Management → คลิก phpMyAdmin
2. เลือก Database ที่ต้องการ Backup จากแถบซ้าย
3. คลิกแท็บ Export ด้านบน
4. เลือก Method: Custom (แนะนำ) เพื่อควบคุมได้มากขึ้น
5. ตรวจว่าเลือก Tables ทั้งหมดแล้ว
6. Format: SQL
7. ที่ Object creation options ติ๊ก Add DROP TABLE (ป้องกัน Error เวลา Restore)
8. คลิก Export — ไฟล์ .sql จะถูก Download ลงเครื่อง

ตัวเลือก Format และ Options ที่ควรรู้

ตอนเลือก Method เป็น Custom ใน phpMyAdmin จะมีตัวเลือกเพิ่มที่ส่งผลต่อความสมบูรณ์ของไฟล์ Backup โดยตรง การเข้าใจตัวเลือกเหล่านี้ช่วยให้ Restore ได้สำเร็จในครั้งเดียวโดยไม่เจอ Error กลางทาง:

• Format = SQL — เป็น Format มาตรฐานที่ Restore กลับเข้า MySQL ได้ตรงตัว ส่วน CSV หรือ JSON เหมาะกับการนำข้อมูลไปใช้ที่อื่น ไม่ใช่การ Backup เพื่อกู้คืนทั้ง Database
• Add DROP TABLE / VIEW / PROCEDURE / EVENT — สั่งให้ลบ Table เดิมก่อนสร้างใหม่ ป้องกัน Error Table already exists เวลา Import ทับ Database ที่มีข้อมูลอยู่แล้ว
• Add CREATE DATABASE / USE statement — ถ้าติ๊กไว้ ไฟล์จะสร้าง Database ใหม่ให้เอง แต่บน Shared Hosting แนะนำให้ ปิด เพราะชื่อ Database บน DirectAdmin มักมี Prefix ของ Username นำหน้า (เช่น user_dbname) ทำให้ชื่อไม่ตรงกับที่สร้างไว้
• Add IF NOT EXISTS — ช่วยให้ Statement ไม่ Error ถ้า Object นั้นมีอยู่แล้ว เหมาะกับการ Merge ข้อมูล
• Character set of the file = utf8mb4 — สำคัญมากสำหรับเว็บภาษาไทยและเว็บที่มี Emoji เลือก utf8mb4 เสมอเพื่อไม่ให้ภาษาไทยกลายเป็นเครื่องหมาย ? ตอน Restore
• Maximal length of created query — ค่า Default ปกติใช้ได้ดี ปล่อยไว้ตามเดิม

3. วิธี Backup ด้วย DirectAdmin Backup Tool

DirectAdmin มี Backup Tool ในตัวที่รองรับ Database ขนาดใหญ่และทำ Full Backup ได้พร้อมกัน (ทั้ง Files + Database)

ขั้นตอน

1. Login เข้า DirectAdmin
2. ไปที่ Advanced Features → Create/Restore Backups
3. เลือก MySQL Databases (และ Home Directory ถ้าต้องการ Full Backup)
4. คลิก Create Backup
5. รอสักครู่ — ไฟล์ Backup จะถูกสร้างใน Home Directory ของคุณ
6. ดาวน์โหลดผ่าน File Manager หรือ FTP

4. วิธี Restore — Import ใน phpMyAdmin

เมื่อต้องการ Restore Database จากไฟล์ .sql ที่เคย Export ไว้:

สร้าง Database ใหม่ก่อน (ถ้าจำเป็น)

ถ้า Database เดิมถูกลบไปแล้ว ให้สร้างใหม่ใน DirectAdmin → MySQL Management → Create Database ก่อน แล้วจำ Username/Password ที่ตั้งไว้

Import ผ่าน phpMyAdmin

1. เปิด phpMyAdmin → เลือก Database ที่ต้องการ Restore
2. คลิกแท็บ Import
3. คลิก Choose File → เลือกไฟล์ .sql ที่มีขนาดไม่เกิน 50MB
4. Format: SQL (ตั้งค่า Default อยู่แล้ว)
5. คลิก Import — รอจนเสร็จ

5. Backup ขนาดใหญ่ทำอย่างไรเมื่อไฟล์เกิน Limit

เว็บที่มีข้อมูลเยอะ เช่น WooCommerce ที่มี Order หลายพันรายการ หรือ Forum ที่สะสมโพสต์มานาน Database อาจโตเกิน 50MB จน phpMyAdmin Import ไม่ผ่าน นี่คือวิธีรับมือแบบเรียงจากง่ายไปยาก:

วิธีที่ 1 — Export/Import แบบ gzip

การบีบอัดเป็น .sql.gz ลดขนาดไฟล์ลง 70–80% ทำให้ไฟล์ที่เคยเกิน Limit กลับมาอยู่ในวงที่ Upload ได้ phpMyAdmin รองรับการ Import ไฟล์ .gz โดยตรง ไม่ต้องแตกไฟล์ก่อน:

1. ตอน Export เลือก Compression: gzipped จะได้ไฟล์ database.sql.gz
2. ตอน Restore เปิดแท็บ Import แล้วเลือกไฟล์ .sql.gz ได้เลย phpMyAdmin จะคลายบีบอัดให้อัตโนมัติ

วิธีที่ 2 — แตกไฟล์ด้วย BigDump

ถ้าไฟล์ใหญ่จน Upload เข้า phpMyAdmin ยังไม่ได้แม้บีบอัดแล้ว ให้ใช้สคริปต์ BigDump ซึ่งจะอ่านไฟล์ .sql ทีละส่วนแล้วรันเป็นชุดเล็ก ๆ หลีกเลี่ยง Timeout:

1. อัพโหลดไฟล์ .sql และไฟล์ bigdump.php เข้า Folder เดียวกันผ่าน File Manager หรือ FTP
2. แก้ค่า $db_server, $db_name, $db_username, $db_password ในไฟล์ bigdump.php ให้ตรงกับ Database
3. เปิด URL ของ bigdump.php ผ่าน Browser แล้วกด Start Import — สคริปต์จะรันต่อเนื่องเป็นรอบ ๆ
4. เมื่อเสร็จ ลบไฟล์ bigdump.php และไฟล์ .sql ออกทันที เพื่อความปลอดภัย ไม่ทิ้งไว้บน Public Directory

วิธีที่ 3 — Command Line mysqldump (ถ้า Hosting อนุญาต)

หาก Hosting Plan ของคุณมี SSH Access การใช้ mysqldump ผ่าน Command Line เป็นวิธีที่เร็วและเสถียรที่สุดสำหรับ Database ขนาดใหญ่ เพราะไม่ติด Limit ของ Web Server:

# Backup — Export ทั้ง Database พร้อมบีบอัด gzip ในคำสั่งเดียว
mysqldump -u USERNAME -p --default-character-set=utf8mb4 DBNAME | gzip > backup_20260607.sql.gz

# Restore — คลายบีบอัดแล้ว Import กลับ
gunzip < backup_20260607.sql.gz | mysql -u USERNAME -p DBNAME

# Backup เฉพาะบาง Table
mysqldump -u USERNAME -p DBNAME wp_posts wp_options > partial.sql

6. ตั้ง Backup อัตโนมัติ และข้อควรระวังสำคัญ

การจำไป Backup เองทุกสัปดาห์เป็นเรื่องที่หลงลืมง่าย วิธีที่ยั่งยืนกว่าคือตั้งให้ระบบทำ Backup ให้อัตโนมัติ และรู้จักจุดพลาดที่ทำให้ Backup ใช้กู้คืนไม่ได้:

ตั้ง Backup อัตโนมัติด้วย Cron Job

ถ้า Hosting มีเมนู Cron Jobs ใน DirectAdmin คุณสามารถตั้งให้รัน mysqldump อัตโนมัติตามรอบเวลาได้ ตัวอย่าง Cron ที่ Backup ทุกวันตอนตี 2 และเก็บไฟล์ตามวันที่:

# รันทุกวันเวลา 02:00 — ตั้งใน DirectAdmin → Cron Jobs
0 2 * * * mysqldump -u USERNAME -pPASSWORD --default-character-set=utf8mb4 DBNAME | gzip > ~/backups/db_$(date +\%Y\%m\%d).sql.gz

สำหรับ WordPress มีอีกทางที่ง่ายกว่าคือใช้ Plugin อย่าง UpdraftPlus หรือ WP-DBManager ที่ตั้ง Schedule Backup แล้วส่งไฟล์ไปเก็บที่ Google Drive / Dropbox ได้อัตโนมัติ ลดความเสี่ยงเก็บ Backup ไว้บน Server เดียวกัน

ข้อควรระวัง: Charset utf8mb4

นี่คือสาเหตุอันดับหนึ่งที่ทำให้ Restore แล้วภาษาไทยเพี้ยนเป็น ??? หรือ ภา ต้องมั่นใจว่า Charset ตอน Export, ไฟล์ .sql และ Database ปลายทางเป็น utf8mb4 ทั้งหมด ถ้า Export มาเป็น latin1 แล้ว Import เข้า utf8mb4 ตัวอักษรไทยจะเสียถาวร แก้คืนยากมาก จึงต้องเลือก utf8mb4 ตั้งแต่ขั้นตอน Export

ข้อควรระวัง: Foreign Keys และลำดับ Table

Database ที่มี Foreign Key Constraints (เช่น ตาราง orders ที่อ้างถึง customers) อาจ Restore ไม่ผ่านเพราะ Import ตาราง orders ก่อนที่ตาราง customers จะถูกสร้าง MySQL จึงฟ้อง Error Cannot add or update a child row วิธีแก้:

• ใช้ไฟล์ Backup จาก phpMyAdmin/mysqldump ที่จัดลำดับ Table และใส่ SET FOREIGN_KEY_CHECKS=0; ไว้หัวไฟล์อยู่แล้ว — ปกติเครื่องมือมาตรฐานจัดการให้
• ถ้ายัง Error ให้เพิ่มบรรทัด SET FOREIGN_KEY_CHECKS=0; ที่ต้นไฟล์ .sql และ SET FOREIGN_KEY_CHECKS=1; ที่ท้ายไฟล์ด้วยตัวเอง
• เลือก Engine ให้ตรงกัน (InnoDB vs MyISAM) — Foreign Key ทำงานเฉพาะบน InnoDB เท่านั้น

7. นโยบาย Backup อัตโนมัติของ AsiaGB

AsiaGB ทำ Backup อัตโนมัติให้ทุก Account ดังนี้:

8. Best Practices การ Backup Database

• ทำ Backup ก่อนทุกการเปลี่ยนแปลงสำคัญ — อัพเดท Plugin, แก้ Schema, Migrate
• เก็บ Backup หลายที่ — เครื่องคอม + Google Drive/Dropbox
• ตั้งชื่อไฟล์ให้บอกวันที่ — เช่น mysite_db_20260512.sql
• ทดสอบ Restore — Backup ที่ไม่เคยทดสอบ Restore คือ Backup ที่ไม่น่าเชื่อถือ
• Compress ไฟล์ — ไฟล์ .sql.gz ใช้พื้นที่น้อยกว่า 70–80%
• ตั้งเตือนในปฏิทิน — ทำ Backup อย่างน้อยเดือนละ 1 ครั้งถ้าเว็บไม่ค่อยอัพเดท หรือ สัปดาห์ละ 1 ครั้งถ้าอัพเดทบ่อย

คำถามที่พบบ่อย (FAQ)

Backup Database บ่อยแค่ไหนถึงจะพอ?

ขึ้นกับว่าข้อมูลเปลี่ยนบ่อยแค่ไหน เว็บข่าวหรือร้านค้าออนไลน์ที่มี Order เข้าทุกวันควร Backup ทุกวันหรืออย่างน้อยสัปดาห์ละครั้ง ส่วนเว็บบริษัทที่อัพเดทนาน ๆ ครั้ง เดือนละครั้งก็เพียงพอ หลักการคือ ถามตัวเองว่า "ถ้าข้อมูลย้อนกลับไปจุด Backup ล่าสุด คุณรับการสูญเสียข้อมูลช่วงนั้นได้ไหม" ถ้ารับไม่ได้ ให้ Backup ถี่ขึ้น

ทำไม Restore แล้วภาษาไทยกลายเป็นเครื่องหมาย ?

เกิดจาก Charset ไม่ตรงกันระหว่างไฟล์ Backup กับ Database ปลายทาง วิธีป้องกันคือเลือก Character set เป็น utf8mb4 ตั้งแต่ตอน Export และสร้าง Database ปลายทางเป็น utf8mb4 ด้วย ถ้าข้อมูลเสียไปแล้วมักกู้คืนได้ยาก จึงควร Backup ใหม่ด้วย Charset ที่ถูกต้องก่อนเกิดปัญหา

AsiaGB Backup ให้แล้ว ยังต้อง Backup เองอีกไหม?

ควร เพราะ Backup อัตโนมัติของ AsiaGB ถ่าย Snapshot เดือนละ 2 ครั้ง (วันที่ 1 และ 15) หากข้อมูลเสียหายระหว่างนั้น จะ Restore ได้เฉพาะ ณ วันที่ Backup ล่าสุด ข้อมูลที่เกิดหลังจากนั้นจะหายไป การ Backup เองก่อนแก้ไขสำคัญ ๆ จะอุดช่องว่างตรงนี้ได้

Restore Database ทับของเดิมจะเป็นอันตรายไหม?

การ Import ไฟล์ที่มี DROP TABLE จะลบข้อมูลปัจจุบันทิ้งแล้วแทนที่ด้วยข้อมูลจากไฟล์ Backup ทันที จึงควร Backup ข้อมูลปัจจุบันไว้ก่อนทุกครั้งก่อน Restore ทับ เผื่อไฟล์ Backup ที่จะกู้คืนมีปัญหา จะได้ย้อนกลับมาที่จุดเดิมได้