การสำรองข้อมูล (Backup)

การสำรองข้อมูลเว็บไซต์ต้องมีอะไรบ้าง

การสำรองข้อมูลเว็บไซต์ต้องมีทั้งไฟล์ ฐานข้อมูล และการตั้งค่า ถ้าเก็บแค่ไฟล์ที่สร้างหน้าจอ ข้อมูลที่สะสมทุกวันอย่างการจอง · สมาชิก · คำสั่งซื้อ · บทความจะย้อนกลับไม่ได้

สิ่งที่มักมองข้ามคือการตั้งค่า บันทึกการเชื่อมโดเมน (DNS) กฎรีไดเรกต์ และการตั้งค่าอีเมลติดต่อ ปกติมองไม่เห็น แต่ถ้าหายไป แม้เว็บไซต์เปิดได้ อีเมลก็ไม่เข้าหรือที่อยู่เก่าก็ขาด

ถ้าเป็นเว็บไซต์ที่พัฒนาขึ้นเอง ซอร์สโค้ดมักเก็บแยกไว้ในคลังโค้ดอย่าง GitHub อยู่แล้ว แต่ฐานข้อมูลและรูปที่ลูกค้าอัปโหลดไม่ได้อยู่ในคลังนั้น จึงต้องสำรองแยก

กฎการสำรองข้อมูล 3-2-1 คืออะไร

กฎ 3-2-1 คือหลักการสำรองข้อมูลที่ใช้กันแพร่หลาย ให้มีสำเนา 3 ชุด แยกเก็บใน 2 รูปแบบการจัดเก็บที่ต่างกัน และเก็บ 1 ชุดไว้คนละสถานที่ ไม่ใช่กฎที่กฎหมายกำหนด แต่เป็นเกณฑ์ง่าย ๆ ที่ช่วยไม่ให้สำเนาทั้งหมดหายไปในเหตุการณ์ครั้งเดียว

สำหรับเว็บไซต์ร้านเล็ก ทำได้ประมาณ “ต้นฉบับบนเซิร์ฟเวอร์ปัจจุบัน + สำรองอัตโนมัติของบริษัทโฮสติ้ง + สำเนาในที่เก็บคลาวด์อื่น” หัวใจคือสำเนาชุดสุดท้ายอยู่กับบริษัทอื่นและบัญชีอื่นที่ไม่ใช่ของเซิร์ฟเวอร์

การโจมตีที่ล็อกไฟล์อย่างแรนซัมแวร์ อาจล็อกที่เก็บข้อมูลที่เชื่อมต่ออยู่ไปด้วย จึงควรมีสำเนาสักชุดที่ปกติไม่ได้เชื่อมกับเว็บไซต์เพื่อความปลอดภัย

บัญชีที่เก็บสำเนาก็ต้องปกป้องแยกต่างหาก ถ้าบัญชีผู้ดูแลเว็บไซต์กับบัญชีสำรองข้อมูลใช้รหัสผ่านเดียวกัน เมื่อฝั่งหนึ่งถูกเจาะ สำเนาก็อาจถูกลบไปด้วย บัญชีสำรองข้อมูลควรใช้รหัสผ่านอื่นและการยืนยันตัวตน 2 ขั้นตอน

ควรสำรองข้อมูลบ่อยแค่ไหน และเก็บไว้นานเท่าไร

รอบการสำรองข้อมูลกำหนดจาก “ถ้าเกิดปัญหา ยอมเสียข้อมูลได้กี่วัน” ถ้าเป็นเว็บไซต์แนะนำร้านที่เปลี่ยนเนื้อหาเดือนละ 1–2 ครั้ง ก็สำรองทุกครั้งที่เปลี่ยน ถ้ามีการจองเข้ามาทุกวัน ต้องเก็บอย่างน้อยวันละครั้ง ประวัติที่เสียไปจึงจะน้อยลง

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

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

นอกจากรอบ ให้กำหนดด้วยว่าจะรัน “เมื่อไร” ถ้าตั้งให้รันอัตโนมัติช่วงเช้ามืดที่ลูกค้าน้อย เว็บไซต์ก็ไม่ช้าลง และไม่มีปัญหาคนลืมทำ

ตรวจอย่างไรว่าข้อมูลสำรองกู้คืนได้จริง

ข้อมูลสำรองต้องลองกู้คืนจริงจึงจะรู้ว่าใช้ได้หรือไม่ หลายครั้งเชื่อแค่การแจ้งเตือน “สำรองข้อมูลเสร็จ” แล้วพอถึงวันที่ต้องใช้จริงถึงรู้ว่าไฟล์เสียหรือขาดไปบางส่วน

ถ้าฝากบริษัทไว้ คุณไม่ต้องทดสอบการกู้คืนเอง แต่ถามได้ว่าทดสอบการกู้คืนครั้งล่าสุดเมื่อไร ถ้าตอบไม่ได้ทันที ลองขอให้ทดสอบสักครั้ง

1. 01ตรวจว่าในรายการข้อมูลสำรอง วันที่ล่าสุดยังอยู่ตามกำหนด
2. 02เทียบขนาดข้อมูลสำรองกับครั้งก่อน ถ้าลดลงมากกะทันหัน อาจมีบางส่วนหายไป
3. 03ลองกู้คืนข้อมูลสำรองลงในพื้นที่ทดสอบ ไม่ใช่เว็บไซต์ที่ใช้งานอยู่
4. 04ตรวจว่าหน้าแรก · รูปภาพ · โพสต์ · ประวัติการจองแสดงครบ
5. 05จดเวลาที่ใช้กู้คืนไว้ จะรู้ว่าเมื่อเกิดเหตุจริงต้องรอนานเท่าไร
6. 06จดผลลัพธ์และวันตรวจครั้งถัดไป แล้วทำซ้ำประมาณไตรมาสละครั้ง

ฝากสำรองข้อมูล ต้องตรวจอะไรบ้าง

ความผิดพลาดที่พบบ่อยที่สุดคือคิดว่า “โฮสติ้งคงทำให้เอง” แล้วไม่ได้ตรวจ รอบการสำรอง ระยะเวลาเก็บ และค่ากู้คืนต่างกันไปตามแพ็กเกจ จึงควรถามเองแล้วจดคำตอบไว้

ต้องตรวจด้วยว่าเมื่อยกเลิกบริการ จะได้รับข้อมูลสำรองหรือไม่ เมื่อเปลี่ยนบริษัท ข้อมูลสำรองที่อยู่เฉพาะบนเซิร์ฟเวอร์ของบริษัทนั้นอาจหายไปพร้อมกัน

ถามด้วยว่า “กู้คืนได้เร็วแค่ไหน” แม้มีข้อมูลสำรอง ถ้ากู้คืนใช้เวลาหลายวัน ระหว่างนั้นก็รับจอง · คำสั่งซื้อไม่ได้ ถ้ารู้เวลาตอบสนองเมื่อระบบขัดข้องเร่งด่วนและเวลาที่ใช้กู้คืนไว้ล่วงหน้า เวลาเกิดเหตุจริงจะไม่ตื่นตระหนกมาก

• สำรองข้อมูลบ่อยแค่ไหน และเก็บไว้กี่ช่วงเวลา
• ข้อมูลสำรองเก็บไว้คนละที่กับเซิร์ฟเวอร์เว็บไซต์หรือไม่
• สำรองฐานข้อมูลและรูปที่อัปโหลดไปด้วยหรือไม่
• เมื่อต้องกู้คืน ต้องแจ้งที่ไหน ใช้เวลานานเท่าไร และมีค่าใช้จ่ายไหม
• ใครถือรหัสผ่านหรือสิทธิ์เข้าถึงไฟล์สำรอง
• เมื่อสิ้นสุดสัญญา จะได้รับข้อมูลสำรองชุดสุดท้ายหรือไม่

ร้านเล็กต้องใช้ข้อมูลสำรองจริงเมื่อไร

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

ถ้าเป็นเว็บไซต์รับจอง ในวันที่เซิร์ฟเวอร์มีปัญหา สิ่งที่สำคัญที่สุดคือรายการจองที่เข้ามาในวันนั้น การจองที่เข้ามาหลังการสำรองครั้งล่าสุดกู้คืนไม่ได้ ถ้าเก็บ SMS หรืออีเมลแจ้งเตือนการจองไว้ด้วย ก็เติมช่องว่างนั้นได้

ถ้ารับชำระเงินออนไลน์ ประวัติคำสั่งซื้อ · การชำระเงินจะเก็บอยู่ในหน้าจัดการของผู้ให้บริการรับชำระเงิน (PG) ด้วย แม้ข้อมูลเว็บไซต์หายไป ก็ใช้ประวัตินั้นตรวจคำสั่งซื้อได้ จึงต้องใส่บัญชีผู้ดูแลของผู้ให้บริการรับชำระเงินไว้ในรายการบัญชีด้วย

ในแพ็กเกจดูแลรักษารายเดือนของ ISSYMO เราสำรองข้อมูลไปพร้อมกับการอัปเดตความปลอดภัยทุกเดือน ถ้าเป็นเว็บไซต์ที่มีข้อมูลสะสมทุกวันอย่างการจอง · คำสั่งซื้อ โปรดตรวจรอบการสำรองข้อมูลแยกต่างหากในการประชุม