สำรองข้อมูลเว็บไซต์แบรนด์ตัวเอง: กลยุทธ์สำรองฐานข้อมูล ไฟล์ และการตั้งค่า พร้อมเก็บไว้ต่างพื้นที่
หนึ่ง ทำไมจึงสำรอง “ทั้งดิสก์เป็นก้อนเดียว” ไม่ได้
กลยุทธ์สำรองข้อมูลของเว็บมาสเตอร์หลายคนคือ “แพ็กทั้งเซิร์ฟเวอร์เก็บไว้ทุกวัน” ฟังดูปลอดภัย แต่จริง ๆ มีปัญหาสามข้อ
ข้อแรก ก้อนใหญ่เกินไป สำรองครั้งหนึ่งใช้เวลาหลายชั่วโมง ทำ incremental ให้ละเอียดไม่ได้เลย ข้อสอง ทรัพย์สินทั้งสามประเภทมีความถี่ในการเปลี่ยนแปลงต่างกันสุดขั้ว ฐานข้อมูลเปลี่ยนทุกชั่วโมง ไฟล์เปลี่ยนนาน ๆ ครั้ง การตั้งค่าไม่แตะเป็นเดือน ถ้าใช้ความถี่เดียวกันก็จะสิ้นเปลืองหรือไม่พอ ข้อสาม เวลากู้คืนทั้งก้อนจะได้ไฟล์ขยะและโค้ดที่ถูกฝังมัลแวร์กลับมาด้วย เท่ากับกู้คืนอุบัติเหตุกลับมาพร้อมกัน
การตัดสินที่ขัดกับสัญชาตญาณอยู่ตรงนี้:คุณค่าของการสำรองไม่ได้ขึ้นกับ “สำรองไปเท่าไร” แต่ขึ้นกับ “กู้คืนได้ไหม เร็วแค่ไหน” ผมเห็นเว็บที่ “สำรองทุกวัน” มามากเกินไป พอถึงวันที่เซิร์ฟเวอร์ล่มจริง ๆ ถึงพบว่าไฟล์สำรองเสีย รหัสผ่านไม่รู้ และชุดที่เก็บต่างพื้นที่ไม่เคยอัปโหลดสำเร็จเลย
เกณฑ์ตรวจรับของกลยุทธ์สำรองมีข้อเดียว: เอาไฟล์สำรองนี้ไปวางบนเครื่องใหม่เอี่ยม แล้วรันเว็บให้ขึ้นภายใน 4 ชั่วโมงได้ไหม นี่ก็เป็นเหตุผลที่การสำรองและกู้คืนเว็บไซต์ เน้น “การตรวจสอบว่ากู้คืนได้”
| ประเภทสินทรัพย์ | ประกอบด้วยอะไร | ความถี่ในการเปลี่ยนแปลง | ผลของการสำรองไม่ครบ |
|---|---|---|---|
| ฐานข้อมูล | ตารางออเดอร์ ใบสอบถาม ผู้ใช้ เนื้อหา | ระดับทุกชั่วโมง | ข้อมูลธุรกรรมและลูกค้าหาย |
| เอกสาร | สิ่งที่ผู้ใช้อัปโหลด รูปภาพ ไฟล์แนบ มีเดีย | ระดับทุกวัน | ไฟล์แนบและรูปสินค้าหาย |
| การตั้งค่า / โค้ด | ธีม ปลั๊กอิน การตั้งค่า Nginx ตัวแปรสภาพแวดล้อม | ทุกครั้งที่แก้ไข | ติดตั้งใหม่แล้วจำลองเว็บเดิมไม่ได้ |
| แพ็กทั้งดิสก์ | ทั้งหมดข้างต้นบวกไฟล์ขยะของระบบ | ทุกวัน | ใหญ่เกินไป ช้าเกินไป กู้คืนแล้วได้มัลแวร์มาด้วย |
สอง การสำรองฐานข้อมูล: full บวก incremental ควบคุม RPO ให้อยู่ภายใน 1 ชั่วโมง
ฐานข้อมูลเป็นสินทรัพย์ที่สำคัญที่สุดในสามประเภท และเป็นสิ่งที่สูญหายไม่ได้มากที่สุด กลยุทธ์ที่ใช้คือ “full backup บวก incremental” คือทำ logical full backup วันละครั้งตอนกลางคืน (mysqldump หรือเครื่องมือที่เทียบเท่า) และเปิด binlog ทำ incremental ทุกชั่วโมง กรณีแย่ที่สุดจะเสียข้อมูลแค่ 1 ชั่วโมงล่าสุด ตัวชี้วัดนี้เรียกว่า RPO (Recovery Point Objective)
มีสองรายละเอียดที่ต้องทำ ข้อแรก อย่ารัน full backup ช่วงที่ธุรกิจพีค ให้รันตอนตี 3 ถึงตี 5 ข้อสอง ไฟล์ backup ต้องตรวจสอบความสมบูรณ์ อย่าดูแค่ “ไฟล์ถูกสร้างแล้ว” ให้ทดสอบด้วยการ restore ไปยังฐานข้อมูลชั่วคราวแบบสุ่มตัวอย่าง ไม่อย่างนั้นไฟล์ backup อาจเสียหายตั้งแต่ครั้งใดครั้งหนึ่งโดยไม่รู้ตัว เมื่อฐานข้อมูลมีขนาดใหญ่ขึ้น logical backup จะช้าลง ถึงตอนนั้นค่อยพิจารณาใช้ physical backup หรือ automatic backup ที่มาพร้อมกับ cloud database
ตัวอย่างสถานการณ์: ตี 4 ฐานข้อมูลถูกลบตารางออเดอร์หนึ่งตารางโดยไม่ตั้งใจ ขั้นตอนกู้คืน: นำ full backup ของเมื่อวานตอนกลางคืนมา restore ไปยังฐานข้อมูลชั่วคราวก่อน จากนั้น replay binlog ตั้งแต่ตี 4 ของเมื่อวานจนถึงก่อนเกิดเหตุ ฐานข้อมูลก็จะกลับไปอยู่ในสภาพก่อนเกิดเหตุ 1 นาที ใช้เวลาทั้งหมดประมาณ 1 ชั่วโมง ความเสียหายถูกควบคุมให้น้อยที่สุด
| วิธี backup | ความถี่ | RPO | ช่วงที่เหมาะใช้งาน |
|---|---|---|---|
| full logical backup ทุกวัน | วันละ 1 ครั้ง | ประมาณ 24 ชั่วโมง | ยอดเข้าชมต่อวันต่ำกว่า 5000 |
| full + binlog incremental | full ทุกวัน incremental ทุกชั่วโมง | ≤ 1 ชั่วโมง | แผนมาตรฐานสำหรับระบบที่มีธุรกรรม |
| automatic backup ของ cloud database | ผู้ให้บริการดูแล | ปกติภายใน 5 นาที | ตัวเลือกสบายใจหลังขึ้น cloud |
| primary-replica sync แบบเรียลไทม์ | เรียลไทม์ | ใกล้ 0 | เพิ่มเมื่อต้องการ high availability |
สาม ไฟล์และการตั้งค่า: แยกสำรอง อย่าปนเข้า backup ฐานข้อมูล
ไฟล์ (ไฟล์แนบคำถามที่ผู้ใช้อัปโหลด รูปสินค้า สื่อ) มีขนาดใหญ่และเปลี่ยนแปลงช้า ไม่เหมาะยัดเข้า backup ฐานข้อมูลรายวัน ให้ใช้เครื่องมือ sync แบบ incremental แยกต่างหาก sync โฟลเดอร์อัปโหลดไปยัง object storage ต่างพื้นที่ วันละครั้งก็เพียงพอ การจัดการไฟล์ขนาดใหญ่อย่างรูปและวิดีโอ เทียบเคียงได้กับ การจัดการสินทรัพย์สื่อ。
การตั้งค่าและโค้ดเป็นสิ่งที่ถูกละเลยมากที่สุด หลายคน backup ฐานข้อมูลได้ดี แต่ลืมว่า Nginx config เวอร์ชันปลั๊กอิน และ environment variable กระจัดกระจายอยู่ตามเซิร์ฟเวอร์ พอติดตั้งใหม่ก็ไม่รู้เลยว่าเดิมรันยังไง
วิธีที่ถูกต้องคือ: โค้ดและการตั้งค่าทั้งหมดเข้า Git repository ส่วน environment variable และคีย์เก็บแยกไว้ใน password vault ไม่เข้า Git ด้วยวิธีนี้การตั้งค่าไม่ได้มาจากการ “backup” แต่ทุกครั้งที่แก้ไขมีเวอร์ชันกำกับ ดึงกลับไปสถานะใดในอดีตก็ได้ทุกเมื่อ
| สินทรัพย์ | เครื่องมือ / วิธี backup | ความถี่ | พื้นที่จัดเก็บต่างถิ่น |
|---|---|---|---|
| full backup ฐานข้อมูล | สคริปต์อัตโนมัติ mysqldump | ทุกวันตอนกลางคืน | object storage คนละ region |
| incremental ฐานข้อมูล | binlog archive | ทุกชั่วโมง | ต่างถิ่นพร้อม full backup |
| ไฟล์ที่ผู้ใช้อัปโหลด | sync แบบ incremental ไปยัง object storage | ทุกวัน | เขียนลงพื้นที่จัดเก็บต่างถิ่นโดยตรง |
| โค้ดและการตั้งค่า | Git commit | ทุกครั้งที่แก้ไข | remote repository บน cloud |
| environment variable และคีย์ | password vault | บันทึกทันทีเมื่อเปลี่ยนแปลง | เก็บรักษาบน cloud แบบเข้ารหัส |
สี่ พื้นที่จัดเก็บต่างถิ่น: หลักการ 3-2-1 ลงมือจริงอย่างไร
3-2-1 เป็นหลักการสำรองข้อมูลแบบเดิมที่ใช้กันมานาน แต่ทีมคนเดียวมักทำได้แค่ครึ่งแรก ความหมายเต็ม ๆ คือ เก็บข้อมูลไว้ 3 ชุด เก็บบนสื่อ 2 ชนิดที่ต่างกัน และมี 1 ชุดเก็บไว้นอกสถานที่ คำว่าอยู่นอกสถานที่ไม่ได้หมายถึงแค่ “อีกฮาร์ดดิสก์หนึ่งลูก” แต่หมายถึง “อีกสถานที่หนึ่งที่จะไม่พังไปพร้อมกันจากเหตุการณ์เดียวกัน”
เมื่อนำมาวางบนเซิร์ฟเวอร์คลาวด์หนึ่งเครื่อง ก็คือ เก็บสำรองล่าสุดไว้บนดิสก์ในเครื่อง (กู้คืนเร็วที่สุด) เก็บอีกชุดไว้ในดาต้าเซ็นเตอร์ที่เซิร์ฟเวอร์ตั้งอยู่ แล้วส่งอีกชุดไปเก็บใน object storage ที่อยู่อีกเมืองหนึ่ง สแนปช็อตของบล็อกดิสก์ในบัญชีและรีเจียนเดียวกันยังไม่นับเป็นนอกสถานที่จริง เพราะถ้าห้องเซิร์ฟเวอร์ไฟไหม้หรือบัญชีถูกล็อก ชุดเหล่านั้นจะหายไปพร้อมกัน ควรเก็บสำรองนอกสถานที่ไว้อย่างน้อย 30 วัน และเก็บไฟล์ถาวรเดือนละหนึ่งชุดย้อนหลังครึ่งปี เพื่อกันไม่ให้แรนซัมแวร์เข้ารหัสสำรองเก่าไปด้วย
ตัวอย่างสถานการณ์: เซิร์ฟเวอร์ถูกแรนซัมแวร์เข้ารหัส สำรองในเครื่องและสำรองบนเซิร์ฟเวอร์ถูกเข้ารหัสไปด้วย แต่สำรองใน object storage ที่อีกเมืองซึ่งเก็บไว้เมื่อ 30 วันก่อนยังออฟไลน์อยู่ ซอฟต์แวร์เข้ารหัสเข้าไม่ถึง คุณนำสำรองชุดนี้ไปกู้คืนบนเครื่องใหม่ เสียข้อมูลมากสุด 30 วัน เว็บยังอยู่
นี่คือความหมายของสำรองนอกสถานที่ ไม่ได้มีไว้เพื่อกู้คืนให้เร็วขึ้น แต่มีไว้เพื่อให้ยังเหลือสักชุดตอนที่ “สำรองออนไลน์ทุกชุดหายหมด” ขั้นตอนล้างข้อมูลหลังถูกแฮกดูได้ที่หลังเว็บไซต์ถูกแฮก。
| ตำแหน่งสำรอง | สื่อ | ระยะเวลาเก็บรักษา | หน้าที่ |
|---|---|---|---|
| ดิสก์ในเครื่องเซิร์ฟเวอร์ | คลาวด์ดิสก์ | 7 วันล่าสุด | กู้คืนเร็วในชีวิตประจำวัน |
| object storage ในดาต้าเซ็นเตอร์เดียวกัน | object storage | 30 วันล่าสุด | กู้คืนเมื่อเซิร์ฟเวอร์ขัดข้อง |
| object storage นอกสถานที่ | บัคเก็ตในรีเจียนอื่น | 30 วัน + ไฟล์ถาวรรายเดือน | ภัยระดับดาต้าเซ็นเตอร์ / บัญชี |
| สำรองที่ดาวน์โหลดไว้ในเครื่อง | ฮาร์ดดิสก์ส่วนตัว | ไตรมาสละหนึ่งชุด | ตัวสำรองสุดท้ายเมื่อผู้ให้บริการก็เชื่อถือไม่ได้ |
ห้า ข้อควรระวัง: ความปลอดภัยลวงตาที่พบบ่อยที่สุดในสี่แบบของการสำรองข้อมูล
กับดักแรกคือ “สำรองไว้บนเครื่องเดียวกัน” ถ้าเก็บไฟล์สำรองไว้ในโฟลเดอร์อื่นบนเซิร์ฟเวอร์ พอเซิร์ฟเวอร์ล่มหรือถูกลบ ทั้งสองชุดก็หายไปพร้อมกัน สำรองต้องออกจากเครื่องนี้ กับดักที่สองคือ “ไม่เคยทดสอบกู้คืน” สคริปต์รายงานว่าสำรองสำเร็จทุกวัน แต่ไม่เคยกู้คืนจริงสักครั้ง เป็นไปได้สูงว่าสำรองชุดหนึ่งเริ่มเสียตั้งแต่ครึ่งปีก่อน
กับดักที่สามคือ “สำรองแค่ข้อมูล ไม่สำรองการตั้งค่า” กู้ฐานข้อมูลกลับมาได้ แต่จำไม่ได้ว่าใช้ปลั๊กอินเวอร์ชันไหน ตั้งค่า Nginx ไว้อย่างไร เว็บก็ยังรันไม่ขึ้น กับดักที่สี่คือ “สำรองไม่มีแจ้งเตือน” สคริปต์สำรองเงียบไปสามสัปดาห์โดยไม่มีใครรู้ จนถึงวันที่ต้องกู้คืนถึงพบว่าไฟล์ว่างเปล่า งานสำรองต้องผูกกับการแจ้งเตือนเมื่อล้มเหลว ถ้าไม่สำเร็จติดกันสองวันให้แจ้งคุณทันที
| ความปลอดภัยลวงตา | อาการที่เห็น | ปัญหาจริง | วิธีแก้ที่ถูกต้อง |
|---|---|---|---|
| สำรองไว้อีกโฟลเดอร์บนเครื่องเดียวกัน | มีไฟล์สำรองทุกวัน | เซิร์ฟเวอร์ล่มก็หายหมด | ต้องเก็บไว้นอกสถานที่แยกต่างหาก |
| ไม่เคยทดสอบกู้คืน | สคริปต์สำรองรายงานว่าสำเร็จ | ไฟล์สำรองอาจเสียหายแล้ว | ซ้อมกู้คืนทุกไตรมาส |
| สำรองแค่ฐานข้อมูล | ฐานข้อมูลถูกสำรองทุกวัน | โค้ดตั้งค่ากระจัดกระจายอยู่ข้างนอก | เก็บการตั้งค่าไว้ใน Git เก็บคีย์ไว้ในตู้เซฟ |
| สำรองไม่มีแจ้งเตือน | ตั้งไว้สามสัปดาห์แล้วยังไม่รู้ | งานสำรองข้อมูลล้มเหลวแบบเงียบ | ล้มเหลวติดกัน 2 วันแจ้งเตือนทันที |
FAQ คำถามที่พบบ่อย
เว็บไซต์ของตัวเองควรสำรองข้อมูลบ่อยแค่ไหน?
ในหลัก 3-2-1 คำว่า “ต่างพื้นที่” ต้องห่างแค่ไหนถึงนับ?
ทำไมต้องซ้อมกู้คืน มีไฟล์สำรองอยู่ก็พอไม่ใช่หรือ?
ใช้สแนปช็อตอัตโนมัติของผู้ให้บริการคลาวด์พอไหม?
รูปภาพและไฟล์แนบที่ผู้ใช้อัปโหลดควรสำรองพร้อมฐานข้อมูลไหม?
สคริปต์สำรองข้อมูลจะรู้ได้ยังไงว่าตัวเองแอบล้มไปแล้ว?
ทิ้งท้าย
การสำรองข้อมูลเป็นเรื่องที่หลอกตัวเองได้ง่ายที่สุด: สคริปต์รันอยู่ ไฟล์ถูกเก็บไว้ ดูเหมือนปลอดภัยดี แต่การทดสอบจริงมีแค่ครั้งเดียวคือตอนกู้คืน สำหรับเว็บไซต์เดี่ยวที่ทำคนเดียว ให้แยกสำรองข้อมูลสามประเภทออกจากกัน เก็บสำเนาไว้ต่างพื้นที่ตามหลัก 3-2-1 และซ้อมกู้คืนไตรมาสละครั้ง ทั้งชุดนี้ทำเสร็จได้ในบ่ายเดียว หลังจากนั้นก็รันอัตโนมัติทุกวัน แค่ดูการแจ้งเตือนสัปดาห์ละครั้ง
ลงมือสามขั้น: หนึ่ง ฐานข้อมูลสำรองเต็มทุกวันบวกส่วนเพิ่มทุกชั่วโมง ตั้งเป้า RPO 1 ชั่วโมง สอง แยกไฟล์กับคอนฟิกออกจากกัน ไฟล์ซิงก์ไปยัง object storage ต่างพื้นที่ทุกวัน ส่วนโค้ดและคอนฟิกเข้า Git สาม ซ้อมกู้คืนไตรมาสละครั้ง จับเวลาให้เสร็จภายใน 4 ชั่วโมง และตั้งการแจ้งเตือนเมื่องานสำรองล้มเหลว
ทำสามขั้นนี้เสร็จ ความมั่นใจเวลเซิร์ฟเวอร์มีปัญหาจะเปลี่ยนจาก “หวังว่าข้อมูลสำรองจะใช้ได้” เป็น “มั่นใจว่ากลับมาเปิดเว็บได้ภายในครึ่งวัน” จังหวะการดูแลเทียบเคียงกับ ช่วงดูแลเว็บไซต์ จัดตารางไปพร้อมกันได้เลย
ประโยคเดียวที่จำไว้ได้: การสำรองข้อมูลไม่ใช่แค่คัดลอกไฟล์เก็บไว้อีกชุด แต่คือการซื้อประกัน “พังแล้วเริ่มใหม่ได้” ให้เว็บของคุณ กรมธรรม์ที่ไม่เคยซ้อมเคลมก็เท่ากับกระดาษเปล่า