THAI DATA CLOUD
Manual THAI DATA CLOUD Platform

Backup Plan: วางกฎ 3-2-1 ให้ข้อมูลบนเซิร์ฟเวอร์คลาวด์ปลอดภัย

วาง Backup Plan ของเซิร์ฟเวอร์คลาวด์ตามกฎ 3-2-1-1-0 แยก Snapshot, Backup และ Replica มีชุดที่ลบไม่ได้ กำหนดระยะเก็บ และซ้อมกู้คืนจริงตามตาราง

โดย ทีมงาน THAI DATA CLOUD อ่าน 13 นาที

แชร์FacebookXLINELinkedIn
Backup Plan — Backup Plan: วางกฎ 3-2-1 ให้ข้อมูลบนเซิร์ฟเวอร์คลาวด์ปลอดภัย
Backup Plan: วางกฎ 3-2-1 ให้ข้อมูลบนเซิร์ฟเวอร์คลาวด์ปลอดภัย

คำตอบสั้น ๆ: วาง Backup Plan ของเซิร์ฟเวอร์คลาวด์ตามกฎ 3-2-1-1-0 แยก Snapshot, Backup และ Replica มีชุดที่ลบไม่ได้ กำหนดระยะเก็บ และซ้อมกู้คืนจริงตามตาราง

คู่มือนี้อธิบาย Backup Plan ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย

Backup Plan คือแผนที่ตอบให้ได้ว่าข้อมูลอะไรถูกสำรอง เก็บไว้กี่ชุด อยู่ที่ไหน เก็บนานเท่าไร ใครเป็นคนกู้ และกู้ได้จริงหรือไม่ Backup Plan ที่ดีบนเซิร์ฟเวอร์คลาวด์มักยึดกฎ 3-2-1 คือมีข้อมูลอย่างน้อย 3 ชุด เก็บบนสื่อหรือระบบอย่างน้อย 2 แบบ และอย่างน้อย 1 ชุดอยู่นอกสถานที่ ปัจจุบันนิยมเพิ่มเป็น 3-2-1-1-0 คืออีก 1 ชุดที่แก้ไขหรือลบไม่ได้ และ 0 ข้อผิดพลาดเมื่อตรวจการกู้คืน

คู่มือนี้เหมาะกับผู้ดูแลระบบที่มีเว็บไซต์ ฐานข้อมูล หรือไฟล์งานอยู่บน Cloud Server และต้องการเปลี่ยนจาก “ตั้งสำรองไว้แล้ว” เป็น Backup Plan ที่ตรวจสอบได้ เมื่อทำครบ คุณจะมีรายการข้อมูลพร้อมเจ้าของ แยกบทบาทของ Snapshot, Backup และ Replica ได้ วางสำเนาตามกฎ 3-2-1 มีชุดที่แรนซัมแวร์ลบไม่ได้ กำหนดระยะเก็บ และมีตารางซ้อมกู้คืนที่ทำจริง

สิ่งที่ต้องเตรียม

  • รายชื่อเซิร์ฟเวอร์และระบบทั้งหมด พร้อมผู้รับผิดชอบฝั่งธุรกิจของแต่ละระบบ เช่น ฝ่ายบัญชีเป็นเจ้าของฐานข้อมูล ERP
  • เป้าหมายว่าแต่ละระบบยอมเสียข้อมูลได้กี่ชั่วโมงและยอมหยุดได้นานเท่าไร ถ้ายังไม่มี ให้ทำตาม คู่มือกำหนด RTO และ RPO ไปพร้อมกัน
  • สิทธิ์ root หรือ Administrator บนเซิร์ฟเวอร์ และสิทธิ์จัดการบริการสำรองข้อมูลในพอร์ทัลของผู้ให้บริการ
  • ที่เก็บข้อมูลปลายทางอย่างน้อยหนึ่งแห่งที่อยู่นอกเซิร์ฟเวอร์ต้นทาง เช่น Object Storage ที่รองรับ S3 หรือเซิร์ฟเวอร์สำรองในอีกศูนย์ข้อมูล
  • เซิร์ฟเวอร์ทดสอบหนึ่งเครื่องสำหรับซ้อมกู้คืน ใช้เครื่องสเปกเล็กที่เปิดเฉพาะวันซ้อมก็พอ
แผนภาพ Backup Plan ที่ข้อมูลจาก web-01 และ db-01 ถูกสำรองเป็นชุดที่สองบนแพลตฟอร์ม และชุดที่สามแบบเข้ารหัสใน Object Storage อีกศูนย์ข้อมูล
สามชุด สองระบบจัดเก็บ หนึ่งชุดอยู่นอกศูนย์ข้อมูลและลบไม่ได้ด้วยสิทธิ์ของเครื่องต้นทาง

ขั้นตอนที่ 1: ทำรายการข้อมูลที่ต้องอยู่ใน Backup Plan

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

  • ฐานข้อมูล: ต้องสำรองด้วยเครื่องมือของฐานข้อมูล เช่น mysqldump, pg_dump หรือ Backup ของ SQL Server ห้ามคัดลอกโฟลเดอร์ข้อมูลขณะฐานข้อมูลทำงาน เพราะไฟล์ที่ได้อาจเปิดไม่ขึ้น
  • ไฟล์ที่ผู้ใช้อัปโหลด: เช่น /var/www/example.com/uploads หรือแชร์ไดรฟ์ของแผนก
  • ค่าตั้งระบบ: /etc, ไฟล์ Nginx หรือ IIS, crontab, ไฟล์ .env และ docker-compose.yml ซึ่งถ้าหายต้องนั่งตั้งใหม่ทั้งวัน
  • ความลับ: ใบรับรอง SSL, คีย์ API และรหัสเข้ารหัสของตัว Backup เอง ต้องเก็บแยกไว้ใน Password Manager นอกเซิร์ฟเวอร์
  • ข้อมูลนอกเซิร์ฟเวอร์: DNS zone, การตั้งค่าไฟร์วอลล์ในพอร์ทัล และรายการผู้ใช้ ซึ่งไม่อยู่ในดิสก์ของเครื่อง

ใน Backup Plan จัดระดับความสำคัญเป็นสามระดับพอ เช่น ระดับ 1 หยุดแล้วธุรกิจหยุด ระดับ 2 หยุดได้หนึ่งวัน ระดับ 3 สร้างใหม่ได้ ระดับนี้จะใช้กำหนดความถี่และจำนวนชุดในขั้นตอนถัดไป

ขั้นตอนที่ 2: แยก Snapshot, Backup และ Replica ให้ชัด

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

  • Snapshot: ภาพของดิสก์ ณ เวลาหนึ่ง สร้างเร็ว กู้กลับทั้งดิสก์ได้เร็ว เหมาะกับก่อนอัปเดตระบบ แต่โดยมากอยู่ในระบบจัดเก็บเดียวกับต้นทาง ถ้าระบบจัดเก็บหรือบัญชีมีปัญหา Snapshot ก็ใช้ไม่ได้ไปด้วย
  • Backup: สำเนาข้อมูลที่ถูกคัดลอกออกไปเก็บแยก มีหลายเวอร์ชันย้อนหลัง กู้ทีละไฟล์ได้ และใช้กู้ได้แม้เครื่องต้นทางหายทั้งเครื่อง
  • Replica: สำเนาที่ซิงก์ตามต้นทางตลอดเวลา เช่น MySQL Replication ช่วยให้กลับมาให้บริการได้เร็ว แต่ถ้ามีคนลบตารางหรือแรนซัมแวร์เข้ารหัสไฟล์ ความเสียหายจะถูกซิงก์ไปที่ Replica ทันที จึงไม่นับเป็น Backup
ตารางเปรียบเทียบ Snapshot, Backup และ Replica ในเรื่องการกู้ไฟล์ที่ลบผิด แรนซัมแวร์ ระบบจัดเก็บเสีย และจำนวนเวอร์ชันย้อนหลัง
Replica ช่วยให้กลับมาเร็ว แต่มีเพียง Backup ที่ย้อนเวลากลับไปก่อนเกิดเหตุได้

สำหรับเซิร์ฟเวอร์บน THAI DATA CLOUD วิธีเปิดบริการสำรองข้อมูลของแพลตฟอร์มอยู่ใน คู่มือการ Backup Server บน Cloud ของ TDC ให้ถือว่าบริการนั้นเป็นหนึ่งชุดใน Backup Plan แล้ววางอีกชุดไว้นอกระบบเดิมตามขั้นตอนที่ 3

ขั้นตอนที่ 3: วางกฎ 3-2-1 ใน Backup Plan ของแต่ละระบบ

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

  1. ชุดที่ 1: ข้อมูลใช้งานจริงบนดิสก์ของ web-01 และ db-01
  2. ชุดที่ 2: บริการ Backup ของแพลตฟอร์มรายวัน และไฟล์ Dump ฐานข้อมูลรายชั่วโมงที่เก็บใน Volume แยกจากดิสก์ระบบ ใช้กู้เร็วเมื่อลบไฟล์ผิดหรืออัปเดตพัง
  3. ชุดที่ 3: สำเนาเข้ารหัสใน Object Storage ที่อยู่ศูนย์ข้อมูลอื่นหรือผู้ให้บริการอื่น ส่งทุกคืนด้วย restic หรือ rclone ใช้เมื่อทั้งระบบต้นทางใช้ไม่ได้

ใน Backup Plan คำว่า “2 สื่อ” บนคลาวด์หมายถึงสองระบบจัดเก็บที่ไม่พึ่งกัน เช่น ดิสก์ของเครื่องกับ Object Storage ส่วน “1 นอกสถานที่” หมายถึงอยู่คนละศูนย์ข้อมูล ไม่ใช่แค่คนละโฟลเดอร์ ถ้าทั้งสามชุดใช้รหัสผ่านหรือ Access Key ชุดเดียวกัน ให้ถือว่ายังไม่ผ่านกฎข้อนี้ เพราะคนที่ได้สิทธิ์เดียวลบได้ทุกชุด

บน Windows Server ระวังข้อจำกัดของ Windows Server Backup ที่สำรองไปยัง Network Share เพราะการสำรองเครื่องเดิมไปยังโฟลเดอร์เดิมจะเขียนทับชุดก่อนหน้า เหลือเพียงชุดล่าสุดชุดเดียว จึงต้องมีชุดอื่นที่เก็บหลายเวอร์ชันประกอบด้วย

ขั้นตอนที่ 4: เพิ่มชุดที่ลบไม่ได้และตรวจให้ได้ 0 ข้อผิดพลาด

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

  • Object Lock: Bucket ที่รองรับ S3 Object Lock เก็บข้อมูลแบบเขียนครั้งเดียวอ่านได้หลายครั้ง (WORM) โหมด Compliance ไม่มีใครลบได้จนครบกำหนด ส่วนโหมด Governance ผู้มีสิทธิ์พิเศษยังข้ามได้ Object Lock ต้องเปิด Versioning ด้วย (ดู เอกสาร S3 Object Lock) ผู้ให้บริการ Object Storage แต่ละรายรองรับไม่เท่ากัน ให้ถามผู้ให้บริการก่อน
  • Append-only: ใช้ restic ส่งไปยัง rest-server ที่รันด้วย --append-only เครื่องต้นทางเพิ่มข้อมูลได้แต่ลบไม่ได้ การล้างข้อมูลเก่าทำจากเครื่องสำรองด้วยสิทธิ์อีกชุด
  • Offline: สำเนารายเดือนที่ดึงออกไปเก็บในที่ที่ไม่ได้ต่อเครือข่ายตลอดเวลา

ส่วนเลข 0 คือการตรวจว่าชุดสำรองอ่านได้ครบ สำหรับ restic ให้ตั้งงานตรวจรายสัปดาห์ที่อ่านข้อมูลจริงบางส่วน ผลที่ต้องการคือข้อความ no errors were found คำสั่งเพิ่มเติมดูได้ใน เอกสาร restic เรื่องการตรวจ Repository

restic check --read-data-subset=5%

ขั้นตอนที่ 5: กำหนดความถี่และระยะเก็บใน Backup Plan

ความถี่ของ Backup Plan ต้องมาจากเป้า RPO ของแต่ละระบบ ไม่ใช่ค่าเริ่มต้นของโปรแกรม ถ้าฝ่ายขายยอมเสียออเดอร์ได้ไม่เกินหนึ่งชั่วโมง การ Dump ฐานข้อมูลวันละครั้งไม่พอ ต้อง Dump ทุกชั่วโมงหรือเก็บ Binary Log เพิ่ม ส่วนระยะเก็บให้ใช้แบบขั้นบันได เช่น รายวัน 14 ชุด รายสัปดาห์ 8 ชุด รายเดือน 12 ชุด ซึ่งย้อนได้ราวหนึ่งปีโดยไม่เปลืองพื้นที่มาก

restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

คำเตือน: forget --prune ลบข้อมูลจริงและเรียกคืนไม่ได้ ให้รันพร้อม --dry-run ก่อนทุกครั้งที่เปลี่ยนนโยบาย ข้อมูลบางประเภท เช่น เอกสารบัญชีหรือข้อมูลส่วนบุคคล อาจมีข้อกำหนดเรื่องระยะเก็บขั้นต่ำหรือต้องลบเมื่อหมดความจำเป็นตาม PDPA ให้ยืนยันระยะเก็บกับที่ปรึกษากฎหมายขององค์กร แล้วบันทึกไว้ใน Backup Plan

ลำดับรอบสำรองใน Backup Plan ตั้งแต่ Dump ฐานข้อมูลรายชั่วโมง สำรองรายคืน รายสัปดาห์ รายเดือน จนถึงชุด offline
ชุดถี่เก็บสั้น ชุดห่างเก็บยาว ย้อนได้ราวหนึ่งปีโดยไม่เปลืองพื้นที่

ขั้นตอนที่ 6: ซ้อมกู้คืนตาม Backup Plan และบันทึกผล

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

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

ตัวอย่างการกู้ฐานข้อมูลเข้าฐานข้อมูลทดสอบโดยไม่แตะของจริง (ใช้บนเครื่องทดสอบเท่านั้น)

mysql -e "CREATE DATABASE restore_test"
gunzip < /var/backups/mysql/shop-2026-11-12.sql.gz | mysql restore_test
mysql -e "SELECT MAX(created_at) FROM restore_test.orders"

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

เช็กลิสต์ผลการซ้อมกู้คืนตาม Backup Plan เช่น กู้จากชุดนอกสถานที่ จับเวลาเทียบ RTO และบันทึกปัญหา
ซ้อมผ่านเมื่อคนที่ไม่ได้ตั้งระบบกู้ได้เองภายในเวลาที่ตกลงไว้

ปัญหาที่พบบ่อยเกี่ยวกับ Backup Plan

Snapshot ของผู้ให้บริการนับเป็นสำเนาหนึ่งชุดในกฎ 3-2-1 ได้หรือไม่?

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

ใช้ RAID หรือ Replica แทน Backup Plan ได้ไหม?

ไม่ได้ RAID กันดิสก์เสียหนึ่งลูก Replica ช่วยให้กลับมาให้บริการเร็ว แต่ทั้งคู่ส่งต่อการลบผิดและไฟล์ที่ถูกเข้ารหัสไปทันที Backup คือสิ่งเดียวที่ย้อนกลับไปยังเวลาก่อนเกิดเหตุได้

สำรองแล้วทุกคืน แต่จะรู้ได้อย่างไรว่างานไม่ล้มเงียบ ๆ?

ทุกงานใน Backup Plan ควรส่งสัญญาณเมื่อทำเสร็จ และให้ระบบภายนอกแจ้งเตือนเมื่อสัญญาณไม่มาตามเวลา เช่น ใช้บริการแบบ Healthchecks ที่รอสัญญาณจากงาน และตรวจขนาดไฟล์สำรองล่าสุดว่าไม่เล็กผิดปกติ

Backup Plan ควรทบทวนบ่อยแค่ไหน?

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

ถ้าต้องการให้ทีมช่วยออกแบบ Backup Plan วางสำเนานอกสถานที่ หรือซ้อมกู้คืนร่วมกับทีมของคุณ ติดต่อทีมงาน THAI DATA CLOUD หรือดูรายละเอียดบริการ Disaster Recovery (DR) and Backup

อ่านเพิ่มเติมเกี่ยวกับ Backup Plan

แชร์FacebookXLINELinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน