กลยุทธ์สำรองข้อมูลเว็บไซต์อิสระ: แบบเต็มและแบบเพิ่มพูน ความถี่ ตำแหน่งจัดเก็บ และการซ้อมกู้คืน
หนึ่ง สำรองข้อมูลอะไร: ฐานข้อมูลและไฟล์ต้องแยกกันสำรอง
การสำรองข้อมูลเว็บไซต์อิสระต้องสำรองสองประเภท: ฐานข้อมูลและไฟล์ ฐานข้อมูลคือเนื้อหาใน wp_posts, wp_options, wp_users ของ WordPress ส่วนไฟล์คือรูปภาพ ธีม และโค้ดปลั๊กอินใน wp-content/uploads สองประเภทนี้มีความถี่ในการเปลี่ยนแปลงและวิธีสำรองข้อมูลต่างกันโดยสิ้นเชิง ถ้าสำรองรวมกันจะเกิดปัญหา
ฐานข้อมูลใช้ mysqldump หรือ wp-cli ส่งออก ทุกครั้งที่ส่งออกต้องใส่พารามิเตอร์ –single-transaction เพื่อไม่ให้ล็อกตารางกระทบระบบออนไลน์ ส่วนไฟล์ใช้ rsync ซิงก์แบบเพิ่มพูน ซิงก์เฉพาะส่วนที่เปลี่ยน ไม่ต้องคัดลอกแบบเต็มทุกครั้ง เพราะไดเรกทอรี wp-content ขนาด 10GB คัดลอกเต็มหนึ่งครั้งใช้เวลาสิบกว่านาที แต่ซิงก์แบบเพิ่มพูนใช้เวลาแค่ไม่กี่วินาที
| สิ่งที่ต้องสำรอง | ความถี่ในการเปลี่ยนแปลง | เครื่องมือที่แนะนำ | วิธี backup |
|---|---|---|---|
| ฐานข้อมูล MySQL | อาจเปลี่ยนแปลงทุกชั่วโมง | mysqldump หรือ xtrabackup | binlog แบบเพิ่มพูนทุก 4 ชั่วโมง dump แบบเต็มวันละครั้ง |
| wp-content/uploads | มีรูปภาพใหม่ทุกสัปดาห์ | rsync | ซิงก์แบบเพิ่มพูนทุกวัน |
| โค้ดธีมและปลั๊กอิน | แก้ไขไม่กี่ครั้งต่อเดือน | git หรือ rsync | ควบคุมเวอร์ชัน สำรองเต็มเดือนละครั้ง |
| wp-config.php | แทบไม่เปลี่ยนแปลง | เก็บแยกในโปรแกรมจัดการรหัสผ่าน | สำรองทันทีเมื่อมีการเปลี่ยนแปลง |
| การตั้งค่า nginx/เว็บไซต์ | แก้ไขไม่กี่ครั้งต่อเดือน | จัดการด้วย git | สำรองทันทีเมื่อมีการเปลี่ยนแปลง |
ตัวอย่างสถานการณ์: เว็บไซต์อุตสาหกรรมอุปกรณ์ที่ใช้ WordPress สำหรับตลาดต่างประเทศ มีผู้สนใจสอบถามเพิ่มวันละ 3 ถึง 5 ราย และมีรูปสินค้าใหม่ 2 ถึง 3 รูปต่อวัน ฐานข้อมูลใช้สคริปต์ส่งออกทุก 4 ชั่วโมง ส่วนไฟล์ใช้ rsync ซิงก์แบบเพิ่มพูนตอนตี 3 ทุกวันไปยังออบเจ็กต์สตอเรจต่างถิ่น ผ่านไปหนึ่งสัปดาห์ แบ็กอัปฐานข้อมูลกินพื้นที่ราว 500MB แบ็กอัปไฟล์แบบเพิ่มพูนกินพื้นที่ราว 200MB ค่าใช้จ่ายพื้นที่จัดเก็บรวมต่อเดือนไม่ถึง 20 หยวน การตั้งค่านี้เชื่อถือได้กว่าการติดตั้งปลั๊กอินสำรองข้อมูลแบบเสียเงินตัวไหนก็ตาม
สคริปต์สำรองข้อมูลเขียนอย่างไร ให้สอดคล้องกับแนวคิด เทคโนโลยีสแตกของ crater เรื่องการดำเนินงานอัตโนมัติ: ไม่พึ่งปลั๊กอินแบบ GUI ใช้ cron กับสคริปต์ ถ้าล้มเหลวให้ส่งการแจ้งเตือน
สอง ความถี่และนโยบายเก็บรักษา: ไม่ใช่ยิ่งสำรองบ่อยยิ่งดี
ข้อสรุปที่ขัดกับสัญชาตญาณ: การสำรองข้อมูลไม่ได้ยิ่งบ่อยยิ่งดี สำรองบ่อยเกินไปจะกินพื้นที่จัดเก็บและ IO มหาศาล แถมตอนกู้คืนยังยุ่งกว่าเดิม เพราะคุณจะเจอกองไฟล์สำรองที่หน้าตาใกล้เคียงกันไปหมด จนแยกไม่ออกว่าอันไหนสะอาด ความถี่ที่เหมาะสมควรกำหนดตามความเร็วของการเปลี่ยนแปลงทางธุรกิจ: ฐานข้อมูลสำรองทุก 4 ชั่วโมง เพราะลูกค้าอาจส่งคำถามเข้ามาได้ตลอด ส่วนไฟล์สำรองวันละครั้ง เพราะการอัปโหลดรูปไม่บ่อย
นโยบายการเก็บรักษาใช้โมเดลปู่-พ่อ-ลูกสามชั้น: ไฟล์สำรองรายวันเก็บ 30 วัน รายสัปดาห์เก็บ 12 สัปดาห์ รายเดือนเก็บ 12 เดือน รายปีเก็บ 3 ปี วิธีนี้ทำให้คุณกู้คืนบทความที่เผลอลบเมื่อวานได้ และกู้คืนเวอร์ชันสะอาดก่อนถูกแฮ็กเมื่อครึ่งปีก่อนได้ด้วย
| ประเภทการสำรองข้อมูล | ความถี่ | ระยะเวลาจัดเก็บ | ตำแหน่งที่จัดเก็บ | ใช้ทำอะไร |
|---|---|---|---|---|
| full backup ฐานข้อมูล | ตี 3 ทุกวัน | 30 วัน | object storage นอกสถานที่ | กู้คืนกรณีลบพลาดในชีวิตประจำวัน |
| binlog แบบเพิ่มทีละส่วนของฐานข้อมูล | ทุก 4 ชั่วโมง | 7 วัน | เครื่องท้องถิ่น+ต่างพื้นที่ | กู้คืนแม่นถึงระดับนาที |
| ไฟล์แบบเต็มจำนวน | เช้ามืดวันอาทิตย์ | 12 สัปดาห์ | object storage นอกสถานที่ | ย้อนกลับระดับสัปดาห์ |
| ไฟล์แบบเพิ่มทีละส่วนด้วย rsync | เช้ามืดทุกวัน | 30 วัน | object storage นอกสถานที่ | ย้อนกลับระดับวัน |
| จัดเก็บรายเดือน | วันที่ 1 ของทุกเดือน | 12 เดือน | สำรองเย็นแบบ Glacier | รายเดือนเพื่อการปฏิบัติตามข้อกำหนดและระยะยาว |
| จัดเก็บรายปี | มกราคมของทุกปี | 3 ปี | สำรองเย็นแบบ Glacier | การตรวจสอบประจำปีและข้อมูลย้อนหลัง |
ตัวอย่างสถานการณ์: เว็บไซต์ที่ทำตลาดต่างประเทศแห่งหนึ่งพบว่าฐานข้อมูลถูกฝังเนื้อหาอันตรายเมื่อบ่ายวันที่ 15 มีนาคม เมื่อมี binlog backup แบบ incremental ก็กู้คืนฐานข้อมูลกลับไปยังเที่ยงวันวันที่ 15 มีนาคม ซึ่งเป็นสถานะก่อนการโจมตี เสียข้อมูลใบสอบถามแค่ครึ่งวัน แต่ถ้ามีแค่ full backup รายวัน จะกู้คืนได้แค่ตี 3 ของวันที่ 15 มีนาคม เสียใบสอบถามไปทั้งวัน นี่คือความต่างระหว่าง incremental ทุก 4 ชั่วโมงกับ full backup รายวัน
สาม ตำแหน่งจัดเก็บ: หลักการ 3-2-1 ต่างพื้นที่คือข้อบังคับ
หลักการสำรองข้อมูล 3-2-1 หมายความว่า: ข้อมูลสำคัญเก็บไว้ 3 ชุด เก็บบนสื่อ 2 ประเภทที่ต่างกัน โดย 1 ชุดวางไว้ต่างพื้นที่ นี่ไม่ใช่ทฤษฎี แต่สรุปมาจากเหตุการณ์ ransomware นับครั้งไม่ถ้วน ในอุบัติเหตุจริง ผู้โจมตีเข้ารหัสเซิร์ฟเวอร์แล้วยังเข้ารหัสไฟล์สำรองในเครื่องด้วย เพราะไฟล์สำรองอยู่เครื่องเดียวกับเว็บไซต์
เลือกสามชั้นการจัดเก็บอย่างไร: ชั้นแรกไฟล์สำรองในเครื่อง วางไว้พาร์ติชันดิสก์อีกตัวของเซิร์ฟเวอร์ กู้คืนเร็วที่สุดแต่ทนความเสี่ยงได้แย่ที่สุด ชั้นที่สอง object storage ต่างพื้นที่ ใช้ AWS S3 หรือ Alibaba Cloud OSS สำรองข้าม availability zone ไม่กลัวเซิร์ฟเวอร์เครื่องเดียวล่ม ชั้นที่สามคลังสำรองเย็น ใช้ S3 Glacier หรือ OSS Archive ถูกแต่กู้คืนช้า ใช้สำหรับการปฏิบัติตามข้อกำหนดรายปีและการเก็บระยะยาว
| ชั้นการจัดเก็บ | ตำแหน่ง | ความเร็วในการกู้คืน | ต้นทุน | การใช้งานหลัก |
|---|---|---|---|---|
| ไฟล์สำรองบนดิสก์ในเครื่อง | พาร์ติชันอื่นของเซิร์ฟเวอร์ | ระดับวินาที | 0 หยวน | กู้คืนเร็วในชีวิตประจำวัน |
| object storage นอกสถานที่ | S3/OSS ข้ามโซน | ระดับนาที | ประมาณ 0.02 หยวน/GB/เดือน | ไฟล์สำรองหลัก ซิงก์ทุกวัน |
| คลังสำรองเย็น | Glacier/OSS Archive | ระดับชั่วโมงถึงวัน | ประมาณ 0.005 หยวน/GB/เดือน | การปฏิบัติตามข้อกำหนดรายปีและระยะยาว |
| สื่อออฟไลน์ | ฮาร์ดดิสก์/เทปในเครื่อง | หยิบแผ่นด้วยมือ | ต้นทุนฮาร์ดดิสก์ครั้งเดียว | ตัวสำรองกรณี ransomware ขั้นรุนแรง |
เตือนสวนทางความเชื่อ：ไฟล์สำรองข้อมูลอย่าวางไว้ในโฟลเดอร์เว็บ หลายคนวางไฟล์สำรองไว้ที่ wp-content/backup/ คิดว่ามีสำเนาเพิ่มอีกชุด แต่จริงๆ แล้วแฮกเกอร์สแกนเจอเส้นทางนี้ก็ดาวน์โหลดได้เลย ชื่อฐานข้อมูลและชื่อตารางรั่วหมด วิธีที่ถูกคือวางไฟล์สำรองไว้นอก web root หรืออัปโหลดไป object storage อัตโนมัติหลังสำรองเสร็จแล้วลบสำเนาในเครื่องทิ้ง ขั้นตอนการเก็บกวาดหลังถูกแฮกดูที่หลังเว็บไซต์ถูกแฮก。
และ CDN เร่งความเร็วทั่วโลก ข้อควรระวังในการใช้งาน：CDN cache ไม่ใช่ backup มันแค่คัดลอกเนื้อหา static ของคุณไปไว้ที่ edge node ถ้า origin ล่ม cache บน CDN ก็หมดอายุเช่นกัน อย่าเอา CDN cache มาเป็นแผนกู้คืนระบบ
สี่、ซ้อมกู้คืน：ไตรมาสละครั้ง เพื่อพิสูจน์ว่า backup ใช้ได้จริง
ขั้นตอนที่ถูกละเลยมากที่สุดในแผนสำรองข้อมูลคือการซ้อมกู้คืน หลายองค์กรรันสคริปต์สำรองข้อมูลมาหนึ่งปีแต่ไม่เคยกู้คืนสักครั้ง พอเกิดเหตุจริงถึงพบว่าไฟล์สำรองเสีย หารหัสผ่านแตกไฟล์ไม่เจอ หรือขั้นตอนกู้คืนทำตามไม่ได้เลย ในเหตุการณ์จริงกว่า 40% ของการกู้คืน backup ล้มเหลว สาเหตุมาจากสามประเภทนี้
ทำ recovery drill อย่างไร: ทุกไตรมาสเลือกช่วง maintenance window หนึ่งช่วง ดึง backup ล่าสุดจาก object storage ต่างพื้นที่ กู้คืนไปยังสภาพแวดล้อมทดสอบใหม่เอี่ยม แล้วรันกระบวนการทั้งหมดให้ครบ ทั้งกู้คืนไฟล์ นำเข้าฐานข้อมูล ตั้งค่า nginx เข้าถึงเว็บไซต์ และตรวจสอบการส่งฟอร์มสอบถาม จับเวลาทั้งกระบวนการ บันทึก RTO (เป้าหมายเวลากู้คืน) และ RPO (ปริมาณข้อมูลที่สูญหาย) ที่เกิดขึ้นจริง ส่วนจะกำหนด RTO/RPO อย่างไรดูได้ที่การกู้คืนระบบหลังภัยพิบัติของเว็บไซต์อิสระและนิยาม RTO/RPO。
| ขั้นตอนการซ้อม | การดำเนินการ | เกณฑ์ผ่าน | จุดที่มักล้มเหลว |
|---|---|---|---|
| 1 ดึงข้อมูลสำรอง | ดาวน์โหลด full + incremental ล่าสุดจาก S3 | ดาวน์โหลดเสร็จภายใน 5 นาที | credential ของ object storage หมดอายุ |
| 2 ตรวจสอบการแตกไฟล์ | tar -tzf เพื่อดูรายการไฟล์ | จำนวนไฟล์ครบถ้วน ไม่เสียหาย | แพ็กเกจ gzip เสีย ไม่มีการตรวจสอบ |
| 3 กู้คืนไฟล์ | แตกไฟล์ไปยังโฟลเดอร์เว็บของสภาพแวดล้อมทดสอบ | สิทธิ์ถูกต้อง 755/644 | สิทธิ์หาย เว็บจอขาว |
| 4 นำเข้าฐานข้อมูล | mysql < backup.sql | จำนวนตารางตรงกับบน production | charset ผิด ภาษาจีนเป็นตัวขยะ |
| 5 ตั้งค่า nginx | คัดลอก config แล้วเปลี่ยนพอร์ต | เข้าถึงโดเมนได้ | กฎ rewrite หาย |
| 6 ตรวจสอบฟังก์ชัน | ลองส่งฟอร์มสอบถามหนึ่งรอบ | อีเมลได้รับ CRM บันทึกเข้าฐานข้อมูล | รหัสผ่าน SMTP ฮาร์ดโค้ดไว้ใน config |
ตัวอย่างสถานการณ์：ทีมหนึ่งไม่ซ้อมกู้คืนมาครึ่งปี พอฮาร์ดดิสก์เซิร์ฟเวอร์เสียถึงดึง backup ต่างพื้นที่มาใช้ ปรากฏว่าแตกไฟล์ไปได้ครึ่งทางก็ error กลายเป็นว่าสคริปต์สำรองข้อมูลเมื่อสามเดือนก่อนตั้งค่า gzip ผิด ทำให้ backup สองเดือนหลังจากนั้นเสียหายทั้งหมด สุดท้ายกู้คืนได้แค่จาก backup เก่าที่สมบูรณ์กว่า ทำให้ข้อมูลสองเดือนหายไป อุบัติเหตุแบบนี้แค่ซ้อมกู้คืนไตรมาสละครั้งก็เจอล่วงหน้าได้
การตั้งค่ามอนิเตอร์ backup ดูที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์：งานสำรองข้อมูลล้มเหลวต้องแจ้งเตือนผ่าน WeCom ขนาดไฟล์สำรองลดฮวบต้องแจ้งเตือน อายุ backup เกิน 24 ชั่วโมงต้องแจ้งเตือน รายการบำรุงรักษาประจำวันดูที่งาน 6 อย่างที่ต้องทำทุกเดือนในช่วงดูแลเว็บไซต์。
FAQ คำถามที่พบบ่อย
เว็บไซต์อิสระใช้ปลั๊กอินอะไรสำรองข้อมูล UpdraftPlus พอไหม？
ควรตั้งความถี่สำรองข้อมูลเท่าไหร่ ต้องสำรองทุกชั่วโมงไหม
หลักการสำรองข้อมูล 3-2-1 ลงมือทำจริงอย่างไร
ทำ recovery drill อย่างไร ทำบ่อยแค่ไหน
ไฟล์สำรองควรเข้ารหัสไหม เก็บกุญแจอย่างไร
ถ้าสคริปต์ backup ล้มเหลว จะรู้ได้ยังไง แจ้งเตือนยังไง
ทิ้งท้าย
เรื่อง backup สิ่งที่ห้ามที่สุดคือ “ติดปลั๊กอินแล้วคิดว่าจบ” ปลั๊กอินรันทุกวัน ไฟล์ backup ถูกสร้างทุกวัน แต่ไม่เคย restore สักครั้ง พอเกิดเรื่องจริงถึงรู้ว่า backup เสีย รหัสผ่านหาย ขั้นตอนทำไม่ผ่าน กลยุทธ์ backup ครึ่งหนึ่งคือเก็บยังไง อีกครึ่งคือ restore ยังไง ซึ่งอย่างหลังสำคัญกว่าสิบเท่า
ลงมือสามขั้น ขั้นแรก วาง backup สามชั้นตามหลัก 3-2-1 ให้ครบ ชั้นละหนึ่งชุด ได้แก่ ในเครื่อง object storage ต่างพื้นที่ และ cold archive ขั้นที่สอง กำหนดความถี่และนโยบายการเก็บ ฐานข้อมูลเพิ่มแบบ incremental ทุก 4 ชั่วโมงบวก full ทุกวัน ไฟล์เพิ่มแบบ incremental ทุกวัน เก็บ 30 วันถึง 3 ปี ขั้นที่สาม ทุกไตรมาสซ้อม restore หนึ่งครั้ง เดินขั้นตอน restore ให้ครบใน test environment แล้วบันทึก RTO และ RPO ที่ได้จริง ทำสามขั้นนี้เสร็จ ถึงจะกล้าบอกว่ามี backup
ประโยคที่จำได้ง่าย ๆ backup ที่ไม่เคย restore เท่ากับไม่มี backup สคริปต์ backup รันมาหนึ่งปีไม่เท่ากับการซ้อม restore ครบหนึ่งครั้ง ในอุบัติเหตุจริง 40% ของ backup เปิดไม่ได้ในวินาทีสำคัญ