🎙️ เรื่องเล่าจากโลกเซิร์ฟเวอร์: Backup ไม่ใช่แค่การคัดลอก — ต้องวางแผนด้วย ผู้เขียน Stefano Marinelli ยกตัวอย่างเคสจริงที่เจอมา เช่น datacenter ไฟไหม้, ห้องเซิร์ฟเวอร์น้ำท่วม, หรือแผ่นดินไหวพังเครื่องไปหมด — และสามารถกู้คืนทั้งหมดได้ในไม่กี่ชั่วโมง ด้วยระบบ backup ที่ออกแบบไว้อย่างดี แนวคิดหลักคือ: - การแบ็กอัปต้อง “สามารถกู้คืนได้จริง” และรวดเร็ว - ไม่ควรผูกติดกับระบบ/ซอฟต์แวร์ใดเป็นพิเศษ - ต้องมีความสม่ำเสมอและตรวจสอบได้ตลอดเวลา บทความจึงเน้นให้เริ่มจากการตอบคำถามเชิงกลยุทธ์ เช่น: - ข้อมูลใดที่ “ต้องรอด” ไม่ว่าจะเกิดอะไรขึ้น - จะยอม downtime ได้มากแค่ไหน - ขนาดพื้นที่จัดเก็บมีเท่าไร - อยาก backup ทั้ง disk หรือเฉพาะไฟล์ โดยแบ่งทางเลือกออกเป็น 2 แนว: - Full Disk Backup (เช่น VM snapshot) - File-Level Backup (ใช้ rsync/tar เป็นต้น) รวมถึงอธิบายว่า “snapshot ก่อน backup” คือสิ่งสำคัญเพื่อให้ข้อมูลสอดคล้อง ไม่เกิดความเสียหายระหว่างการกู้คืน สุดท้ายพูดถึงสถาปัตยกรรมแบบ push หรือ pull ซึ่งผู้เขียนแนะนำว่าการ backup โดยให้ “เซิร์ฟเวอร์เป็นฝ่ายเรียกข้อมูลเอง” จะปลอดภัยกว่า หากสามารถออกแบบได้ ✅ Backup ที่ดีต้องกู้คืนได้เร็ว ปลอดภัย และเป็นอิสระจากระบบที่ใช้ ➡️ ไม่ควรพึ่งเฉพาะ cloud หรือคิดว่า RAID คือ backup ✅ ต้องเริ่มจากการวางแผน เช่น ข้อมูลไหนสำคัญแค่ไหน ➡️ และต้องการ downtime หรือระยะกู้คืนเท่าไร ✅ การเก็บ backup ไว้ในเครื่องเดียวกันกับข้อมูลจริงเป็นสิ่งที่ควรหลีกเลี่ยง ➡️ หากเครื่องพังหรือไฟดับ จะไม่สามารถใช้งาน backup ได้ ✅ เปรียบเทียบระหว่าง Full Disk Backup และ File Backup ➡️ Full Disk ดีตรงกู้ทั้งระบบ แต่ใช้พื้นที่สูง ส่วน File ดีตรงยืดหยุ่นและเร็วกว่าบางกรณี ✅ Snapshot ของระบบไฟล์เป็นหัวใจของการทำ backup ที่สอดคล้อง ➡️ เช่นใช้ ZFS, BTRFS, LVM หรือ VSS ใน Windows เพื่อเก็บสภาพแบบ freeze ก่อนคัดลอก ✅ สถาปัตยกรรม backup แบบ Pull จะปลอดภัยกว่า Push หากจัดการได้ ➡️ เพราะลดโอกาสที่ client จะเข้ามาลบ backup หากถูกโจมตี ✅ ควรมี snapshot ฝั่ง server backup เพื่อความปลอดภัยอีกชั้น ➡️ ถ้า client ถูกเจาะ ระบบยังสามารถย้อนคืนได้ด้วย snapshot ฝั่ง server ‼️ การคัดลอกไฟล์ของระบบที่เปิดใช้งานอยู่ (เช่น database) อาจใช้งานไม่ได้จริง ⛔ ไฟล์ที่อยู่ระหว่างการเปลี่ยนแปลงจะไม่สามารถกู้คืนได้ และอาจ corrupt ‼️ บาง snapshot เช่น LVM หรือ DattoBD อาจทำให้ระบบ freeze หากใช้ผิดจังหวะ ⛔ โดยเฉพาะตอนลบ snapshot ระหว่าง I/O หนัก อาจต้อง reboot ระบบ ‼️ การเก็บ backup ใกล้เกินไปจากระบบหลัก อาจสะดุดตอนต้องใช้ในเหตุฉุกเฉิน ⛔ เช่น backup บน LAN หรือเครื่องเดียวกัน เมื่อภัยพิบัติเกิด อาจใช้ไม่ได้ ‼️ หากไม่มี snapshot ฝั่ง server backup แล้วโดน client เจาะลึก อาจลบข้อมูลหมดโดยไม่รู้ตัว ⛔ ควรตั้งระบบ snapshot ฝั่ง server ไว้นานพอเพื่อระบุการโจมตีและกู้คืนได้ https://it-notes.dragas.net/2025/07/18/make-your-own-backup-system-part-1-strategy-before-scripts/