"Backup ไว้ในโฮสต์เดิมก็พอ" — วันเซิร์ฟเวอร์โดน เว็บกับ backup หายพร้อมกัน
ไฟล์ backup ที่อยู่เครื่องเดียวกับเว็บอาจหายไปพร้อมกันเมื่อดิสก์เสีย ถูกเจาะ หรือโดน ransomware เช็กวิธีวาง backup แบบ 3-2-1-1-0 และคำถามที่ต้องตอบให้ได้ก่อนวันกู้จริง
ลูกค้าคนหนึ่งเคยถามผมว่า “ผมมีปลั๊กอิน backup แล้วครับ มันเก็บไฟล์ไว้ในเว็บอัตโนมัติ แบบนี้พอไหม”
คำตอบสั้นๆ คือ ดีกว่าไม่มี แต่ยังไม่พอสำหรับวันกู้จริง เพราะถ้าไฟล์เว็บและไฟล์ backup อยู่บนโฮสต์หรือสิทธิ์เข้าถึงชุดเดียวกัน เหตุเดียวอาจทำลายทั้งสองชุดพร้อมกัน
Backup ที่ดีไม่ใช่แค่ “มีไฟล์” แต่ต้องยังอยู่ เปิดได้ และมีคนกู้กลับได้เมื่อระบบหลักใช้งานไม่ได้
บทความนี้จึงไม่พาอ้อมครับ เราจะดูว่าความเสี่ยงอยู่ตรงไหน วาง backup ตามกฎ 3-2-1-1-0 อย่างไร และต้องถามอะไรผู้ให้บริการก่อนวางใจ
Backup ในโฮสต์เดิมยังไม่ใช่แผนกู้คืน
การเก็บสำเนาไว้ใน /wp-content/ หรือโฟลเดอร์อื่นบนบัญชีโฮสต์เดิมมีประโยชน์เวลาแก้ไฟล์พลาดและระบบหลักยังทำงานอยู่ แต่สำเนานั้นยังอยู่ใน จุดเสียหายร่วมเดียวกัน กับเว็บ
ลองนึกถึงการถ่ายเอกสารสำคัญแล้วใส่สำเนาไว้ในกระเป๋าใบเดียวกับต้นฉบับ วันที่กระเป๋าหาย เราไม่ได้เหลือสำเนาเพิ่มขึ้นเลย การ backup ก็เหมือนกัน: ถ้าเครื่องเดียวกัน ดิสก์เดียวกัน หรือบัญชีเดียวกันถูกกระทบ สำเนาที่อยู่ข้างในอาจหายไปพร้อมต้นฉบับ
ดังนั้นไฟล์ backup บนโฮสต์เดิมควรเป็นเพียง สำเนาชั้นหนึ่งเพื่อความสะดวก ไม่ใช่สำเนาสุดท้ายที่ธุรกิจฝากความหวังไว้ทั้งหมด
4 เหตุการณ์ที่ทำให้เว็บและ backup หายพร้อมกัน
ต้นเหตุอาจต่างกัน แต่ผลลัพธ์เหมือนกันเมื่อเว็บกับ backup อยู่ในขอบเขตเดียวกัน:
- ดิสก์หรือระบบไฟล์เสีย — เว็บและไฟล์ backup บนดิสก์ชุดเดียวกันอ่านไม่ได้พร้อมกัน
- Ransomware เข้ารหัสทั้งเครื่อง — สำเนาที่ระบบหลักยังเขียนถึงได้อาจถูกเข้ารหัสตามไปด้วย
- บัญชีโฮสต์หรือเว็บถูกยึด — ผู้โจมตีที่เข้าถึงไฟล์เว็บได้ก็มักเข้าถึงโฟลเดอร์ backup ในบัญชีเดียวกันได้
- คนลบผิดหรือระบบทำงานผิดพลาด — คำสั่งลบ การ sync หรือการตั้งค่า retention ที่ผิดอาจกระทบทั้งต้นฉบับและสำเนาที่ผูกกันอยู่
จุดที่ต้องแก้จึงไม่ใช่แค่ “ทำ backup ให้บ่อยขึ้น” แต่ต้อง แยกจุดเก็บและแยกสิทธิ์เข้าถึง เพื่อไม่ให้เหตุเดียวล้มทุกสำเนา
กฎ 3-2-1-1-0 แบบเข้าใจง่าย
กฎนี้เป็นกรอบตรวจแผน backup ไม่ใช่สูตรตายตัวสำหรับซื้อพื้นที่เก็บข้อมูล:
- 3 — มีข้อมูลรวมอย่างน้อย 3 ชุด: ข้อมูลที่ใช้งานอยู่ 1 ชุด และสำเนาอีกอย่างน้อย 2 ชุด
- 2 — กระจายไว้บนระบบหรือสื่ออย่างน้อย 2 แบบ ไม่ผูกทุกชุดกับเครื่องหรือ storage เดียวกัน
- 1 — มีอย่างน้อย 1 ชุดอยู่นอกระบบหลักหรือ off-site
- +1 — มี 1 ชุดที่ลบหรือแก้ไขตามได้ยาก เช่น immutable, offline หรือ air-gapped
- 0 — ผลตรวจและการทดสอบกู้ต้องไม่มี error ที่ยังไม่ได้แก้
แก่นสำคัญคือ off-site อย่างเดียวอาจยังไม่พอ หากผู้โจมตีใช้บัญชีเดียวกันลบสำเนาปลายทางได้ จึงควรแยก credential เปิดใช้การป้องกันการลบ และทดสอบ restore เป็นรอบๆ
5 คำถามก่อนเชื่อว่า backup ใช้ได้จริง
ไม่ว่าจะทำเองหรือผู้ให้บริการทำให้ ควรตอบคำถามเหล่านี้ได้ชัดเจน:
- สำรองอัตโนมัติบ่อยแค่ไหน? ถ้ากู้ชุดล่าสุด ธุรกิจยอมเสียข้อมูลย้อนหลังได้กี่ชั่วโมงหรือกี่วัน
- เก็บคนละที่กับเว็บจริงไหม? ต้องไม่ใช่แค่คนละโฟลเดอร์แต่ยังอยู่ดิสก์ เครื่อง หรือบัญชีเดียวกัน
- ถูกลบหรือเข้ารหัสตามได้ไหม? ตรวจเรื่อง immutable/offline และการแยกสิทธิ์ของปลายทาง backup
- เก็บย้อนหลังเท่าไร? หลายเวอร์ชันช่วยให้ย้อนไปก่อนวันที่มัลแวร์เริ่มทำงานหรือก่อนข้อมูลถูกแก้ผิด
- เคยกู้จริงเมื่อไร และใครเป็นคนกู้? ต้องรู้ทั้งขั้นตอน ผู้รับผิดชอบ และเวลาคร่าวๆ ที่ใช้กู้ไฟล์ ฐานข้อมูล และการตั้งค่ากลับมา
คำว่า “โฮสต์มี backup ให้” จึงยังไม่ใช่คำตอบสุดท้าย ต้องรู้ขอบเขต ความถี่ ระยะเก็บ และเงื่อนไขการ restore ด้วย
สิ่งที่ควรทำวันนี้
- ตรวจตำแหน่งไฟล์ปัจจุบัน — ถ้าทุกชุดอยู่ในบัญชีโฮสต์เดียวกัน ให้ถือว่ายังมีความเสี่ยงเดียวกัน
- เพิ่มปลายทาง off-site แบบอัตโนมัติ — ใช้บัญชีและสิทธิ์ที่แยกจากระบบหลักเท่าที่ทำได้
- กำหนด retention ตามธุรกิจ — เลือกจำนวนชุดรายวัน รายสัปดาห์ หรือรายเดือนให้ย้อนกลับได้ไกลกว่าช่วงที่มักตรวจพบปัญหา
- ป้องกันสำเนาสำคัญจากการเขียนทับ — ใช้ immutable หรือ offline copy อย่างน้อยหนึ่งชุดเมื่อระบบรองรับ
- ซ้อมกู้บน staging — เปิดดูหน้าเว็บ ทดสอบ login และตรวจข้อมูลสำคัญ ไม่ใช่แค่ดูว่าไฟล์ backup ถูกสร้างสำเร็จ
ให้บันทึกวันที่ทดสอบ ผลที่พบ และคนรับผิดชอบไว้ด้วย วันเกิดเหตุจะได้ไม่ต้องเริ่มหาคำตอบตอนตีสอง
PhalconHost ดูแล backup อย่างไร
แนวคิดของ PhalconHost คือ backup ต้องเป็นตาข่ายกันตก ไม่ใช่ไฟล์ที่สร้างไว้ให้รู้สึกอุ่นใจ เราจึงจัดให้มี auto backup แยกจากระบบเว็บ เก็บหลายเวอร์ชัน และมี Dev ช่วยเลือกจุดกู้ที่เหมาะสมเมื่อเกิดปัญหา
อย่างไรก็ตาม เจ้าของเว็บควรมีสำเนาที่ตัวเองควบคุมได้อีกชั้นเสมอ โดยเฉพาะข้อมูลสำคัญต่อธุรกิจ เพราะไม่มีระบบใดควรพึ่งจุดเดียว แม้จุดนั้นจะเป็นผู้ให้บริการ backup ก็ตาม
ถ้าตอนนี้ยังไม่แน่ใจว่า backup ของคุณอยู่นอกระบบหลักจริงไหม หรือเคยทดสอบกู้สำเร็จหรือยัง ทักไลน์มาเล่าโครงสร้างปัจจุบันได้ครับ บอกว่าทำด้วยเครื่องมืออะไร เก็บไว้ที่ไหน และเก็บกี่เวอร์ชัน เดี๋ยวผมช่วยชี้จุดเสี่ยงให้ตรงๆ ครับ
ต้องการสอบถามข้อมูลเพิ่มเติม?
สามารถแอดไลน์คุยกันก่อนได้ที่ line: @PhalconHost
