เนื้อหาสนับสนุน สนับสนุนโดย THAI DATA CLOUDหมายความว่าอย่างไร
Cloudทดสอบกู้คืน Backup ตามคำแนะนำ CISA: สำรองเซิร์ฟเวอร์ขึ้นคลาวด์กับ THAI DATA CLOUD
ทดสอบกู้คืน Backup ตามคำแนะนำ CISA หลังประกาศเรื่อง SafePay 20 ต.ค. 2026 พร้อมสำรองเซิร์ฟเวอร์ขึ้นคลาวด์ด้วย Agent ของ THAI DATA CLOUD เลือกจุดเวลากู้ได้
โดย กองบรรณาธิการ THAI DATA อ่าน 6 นาที
สรุปประเด็นสำคัญ
- FBI, CISA และหน่วยงานพันธมิตรออกประกาศ #StopRansomware เรื่อง SafePay เมื่อ 20 ตุลาคม 2026 ระบุว่าผู้โจมตีปิดบริการที่ใช้กู้คืนระบบ และบางกรณีลบ backup ที่ต่อกับเครือข่ายทั้งหมด
- ประกาศแนะนำให้เก็บ backup แบบ offline และทดสอบกู้คืน Backup อย่างสม่ำเสมอ ให้ backup เข้ารหัสและแก้ไขหรือลบไม่ได้ (immutable) และเก็บสำเนาข้อมูลกับเซิร์ฟเวอร์ไว้แยกทางกายภาพ เช่น บนคลาวด์
- On-Premise to Cloud Backup ของ THAI DATA CLOUD ติดตั้ง Agent บนเซิร์ฟเวอร์ต้นทาง เข้ารหัส AES-256 ตั้งแต่บนเครื่อง ส่งผ่าน HTTPS และเก็บบนคลาวด์แบบ 3 สำเนา
- หน้าบริการการันตีความเร็ว Backup 1TB ต่อชั่วโมง ยกตัวอย่างข้อมูล 5TB ใช้รอบแรกราว 5 ชั่วโมง และรอบต่อไปส่งเฉพาะส่วนที่เปลี่ยน
- ราคาคิดตามปริมาณข้อมูลจริง จำนวนเครื่อง และ Policy ไม่ต้องซื้อ Backup Server หรือ License เพิ่ม ทีมประเมินให้ฟรี และมี Support ตลอด 24 ชั่วโมง
ทดสอบกู้คืน Backup เป็นหนึ่งในคำแนะนำของ FBI และ CISA ในประกาศเรื่องแรนซัมแวร์ SafePay เมื่อ 20 ตุลาคม 2026 ซึ่งพบว่าผู้โจมตีลบ backup ที่ต่อกับเครือข่าย THAI DATA CLOUD ให้บริการ On-Premise to Cloud Backup ที่ติดตั้ง Agent บนเซิร์ฟเวอร์เดิม ส่งสำเนาที่เข้ารหัสแล้วขึ้นคลาวด์นอกอาคาร และเลือกจุดเวลามากู้คืนเพื่อทดสอบได้ตลอด
บทความนี้เป็นเนื้อหาสนับสนุนจาก THAI DATA CLOUD ซึ่งเป็นผู้ดำเนินงานเว็บไซต์ thaidata.co.th ขอบเขตบริการและตัวเลขของบริการมาจากหน้า On-Premise to Cloud Backup บน thaidata.cloud ณ วันที่ 4 พฤศจิกายน 2026 ส่วนพฤติกรรมของแรนซัมแวร์และคำแนะนำเรื่อง backup มาจากประกาศร่วมของ FBI และ CISA
CISA เตือนอะไรเรื่อง backup ในประกาศ SafePay
ประกาศ #StopRansomware รหัส AA26-293A ออกร่วมกันโดย FBI, CISA, หน่วย Secret Service ของสหรัฐฯ, ตำรวจรัฐ Rheinland-Pfalz ของเยอรมนี และหน่วยงานด้านอาชญากรรมของสหราชอาณาจักร ระบุว่ากลุ่ม SafePay เคลื่อนไหวมาตั้งแต่สิงหาคม 2024 เจาะเข้าเครือข่ายด้วยรหัสผ่านที่ถูกขโมยหรือเดาได้ ช่องโหว่ในระบบความปลอดภัย และฟิชชิง ก่อนเข้ารหัสไฟล์และเรียกค่าไถ่
ส่วนที่เกี่ยวกับการสำรองข้อมูลโดยตรงคือ ผู้โจมตีปิดบริการที่ใช้กู้คืนระบบ และในบางกรณีลบ backup ทั้งหมดที่ต่อกับเครือข่าย ประกาศจึงแนะนำมาตรการด้าน backup 3 ข้อ
- เก็บ backup แบบ offline และทดสอบกระบวนการสำรองกับกู้คืนอย่างสม่ำเสมอ
- เข้ารหัส backup ทั้งหมดและทำให้ immutable คือแก้ไขหรือลบไม่ได้ ครอบคลุมข้อมูลทั้งองค์กร
- เก็บสำเนาข้อมูลและเซิร์ฟเวอร์หลายชุดไว้ในที่แยกทางกายภาพ แบ่งเครือข่ายและปลอดภัย เช่น ฮาร์ดดิสก์ อุปกรณ์จัดเก็บ หรือคลาวด์
ข้อแรกจึงไม่ได้ขอแค่ให้มี backup แต่ให้ทดสอบกู้คืน Backup เป็นประจำด้วย หน่วยงานผู้ออกประกาศไม่สนับสนุนการจ่ายค่าไถ่ เพราะการจ่ายไม่ได้รับประกันว่าจะได้ไฟล์คืน องค์กรที่ทดสอบกู้คืน Backup มาแล้วจึงมีทางเลือกที่ไม่ต้องพึ่งผู้โจมตี
ทำไม backup ในตึกเดียวกันไม่พอ
หน้าบริการของ THAI DATA CLOUD อธิบายด้วยกฎ 3-2-1 คือ เก็บข้อมูลอย่างน้อย 3 ชุด บนสื่ออย่างน้อย 2 ชนิด และอย่างน้อย 1 ชุดอยู่นอกสถานที่ ห้องเซิร์ฟเวอร์ทั่วไปที่ backup ลง NAS หรือ external disk ในอาคารเดียวกันผ่านสองข้อแรก แต่ตกข้อสุดท้าย เพราะไฟไหม้ น้ำท่วม หรือแรนซัมแวร์ที่วิ่งข้ามวงแลนไปถึงไดรฟ์ที่ mount ค้างไว้ กวาดทุกชุดไปพร้อมกันได้ และชุดนอกสถานที่ที่ไม่เคยทดสอบกู้คืน Backup ก็ยังไม่ใช่หลักประกัน รายละเอียดของกฎนี้อยู่ในคู่มือกฎ Backup 3-2-1
ชุดบนคลาวด์ทำหน้าที่เป็นชุดนอกสถานที่นั้น หน้าบริการระบุว่าเครื่องต้นทางจะอยู่ที่สำนักงาน ใน Data Center ในประเทศหรือต่างประเทศก็สำรองขึ้นคลาวด์ได้ และองค์กรเลือกได้ว่าจะให้ข้อมูลสำรองอยู่ในประเทศไทยหรือต่างประเทศ
บทความนี้เน้นเซิร์ฟเวอร์ที่ลง Agent ได้ ส่วนอุปกรณ์ NAS ที่สำรองผ่าน SMB และ NFS โดยไม่ต้องลง Agent อ่านได้ที่สำรองข้อมูล NAS ขึ้น Cloud
Agent สำรองเซิร์ฟเวอร์ขึ้นคลาวด์อย่างไร
On-Premise to Cloud Backup ติดตั้ง Agent บนเครื่องที่ต้องการสำรองเท่านั้น ไม่ต้องซื้อ Backup Server ไม่ต้องจ่ายค่า Software License และไม่ต้องย้ายระบบเดิม หน้าบริการอธิบายลำดับงาน 5 ขั้นบนเครื่องต้นทาง
- เลือกเฉพาะ block ที่เปลี่ยน หลังรอบแรก รอบต่อไปส่งเฉพาะส่วนที่เปลี่ยน
- ตัดข้อมูลซ้ำก่อนส่ง block ที่เหมือนกันเก็บครั้งเดียว
- บีบอัด หน้าบริการยกตัวอย่างอัตรา 30:1 คือข้อมูล 30GB เหลือ 1GB
- เข้ารหัส AES-256 ตั้งแต่ยังอยู่บนเครื่อง และส่งผ่านช่องทาง HTTPS ที่เข้ารหัสอีกชั้น
- ส่งขึ้นคลาวด์ เก็บแบบ Three Data Copies พร้อม service availability 99.9%
อัตราบีบอัดที่ได้จริงต่างกันตามชนิดข้อมูล ตัวเลขที่ควรใช้วางแผนจึงมาจากการประเมินข้อมูลขององค์กรเอง ซึ่งทีมทำให้ฟรี แล้วควรวัดซ้ำตอนทดสอบกู้คืน Backup ครั้งแรก
ทดสอบกู้คืน Backup ให้ครบทุกชนิดเซิร์ฟเวอร์
หน้าบริการเขียนไว้ว่า Backup ที่คัดลอกไบต์ครบแต่กู้กลับมาใช้ไม่ได้ ไม่นับว่าเป็น Backup การทดสอบกู้คืน Backup จึงต้องเลือกวิธีตามชนิดเครื่อง
| เซิร์ฟเวอร์ | สิ่งที่มักพลาด | วิธีสำรองที่หน้าบริการแนะนำ | สิ่งที่ต้องตรวจตอนทดสอบกู้คืน |
|---|---|---|---|
| File Server | คัดลอกไฟล์ทั้งก้อนทุกครั้ง | สำรองเฉพาะส่วนที่เปลี่ยน พร้อมตัดข้อมูลซ้ำก่อนส่ง | สุ่มเปิดไฟล์จากหลายโฟลเดอร์และหลายจุดเวลา |
| Application Server | สำรองแต่ข้อมูล ลืม config และ dependency | สำรองทั้งเครื่องระดับ image และ One-click Disaster Recovery | กู้ทั้งเครื่องลงที่แยก แล้วตรวจว่าแอปขึ้นได้ |
| Database Server | คัดลอกไฟล์ขณะฐานข้อมูลยังเขียนอยู่ | สำรองแบบรู้จักฐานข้อมูล รองรับ MySQL, Oracle, SQL Server และ SAP HANA | ฐานข้อมูล start ได้และตัวเลขสำคัญตรงกับต้นทาง |
| เครื่องที่ Data Center ต่างจังหวัดหรือต่างประเทศ | งานสำรองค้างเงียบ ๆ เพราะไม่มีคนที่ไซต์ | สำรองขึ้นคลาวด์ตรงจากที่ตั้งเดิม ดูสถานะผ่าน Control Panel | ตรวจว่ามีชุดล่าสุดครบทุกเครื่องก่อนกู้ |
ทุกครั้งที่ทดสอบกู้คืน Backup ให้จดสองตัวเลข คือเวลาที่ใช้กู้จนระบบกลับมาใช้ได้ และจุดเวลาของข้อมูลที่ได้คืน แล้วเทียบกับเป้าที่ตั้งไว้ ถ้าเกินเป้าแปลว่าต้องปรับรอบสำรองหรือวิธีกู้ก่อนเกิดเหตุจริง
ตั้งรอบสำรองและระยะเก็บย้อนหลัง
องค์กรกำหนด Policy เองได้ทั้งความถี่ จำนวนชุด และระยะเก็บย้อนหลัง หน้าบริการแนะนำให้เริ่มจากคำถามว่า "ถ้าเครื่องพังตอนนี้ ยอมเสียข้อมูลย้อนหลังได้กี่ชั่วโมง" คำตอบคือ RPO ซึ่งควรเป็นตัวกำหนดความถี่ของรอบสำรอง
| เรื่อง | สิ่งที่หน้าบริการระบุ |
|---|---|
| ความเร็วรอบแรก | การันตี 1TB ต่อชั่วโมง ข้อมูล 5TB ใช้ราว 5 ชั่วโมงเป็นตัวอย่างการคำนวณ ไม่ใช่การรับประกันเวลาของงานแต่ละราย |
| รอบประจำ | ส่งเฉพาะส่วนที่เปลี่ยน ตัวเลขที่ต้องดูคือข้อมูลเปลี่ยนวันละเท่าไร |
| การเลือกจุดกู้คืน | มีปฏิทินและไทม์ไลน์ให้เลือกช่วงเวลาที่ต้องการกู้ |
| ระยะเก็บย้อนหลัง | กำหนดเอง การบีบอัดช่วยให้เก็บได้นานขึ้นในพื้นที่เท่าเดิม |
ผลจากการทดสอบกู้คืน Backup คือตัวบอกว่ารอบสำรองที่ตั้งไว้พอหรือไม่ การเก็บหลายจุดเวลาสำคัญกับแรนซัมแวร์ เพราะการติดเชื้อมักถูกพบหลังเกิดไปแล้ว ถ้ามี backup ชุดเดียวที่เขียนทับทุกคืน ชุดนั้นอาจติดไปด้วยแล้ว
เรื่องที่ควรถามก่อนเซ็นสัญญา
- Immutable CISA แนะนำให้ backup แก้ไขหรือลบไม่ได้ หน้าบริการ On-Premise to Cloud Backup ไม่ได้ระบุคุณสมบัตินี้ไว้ องค์กรที่ต้องการควรขอให้ระบุในใบเสนอราคา
- ที่เก็บข้อมูล เลือกให้ข้อมูลสำรองอยู่ในไทยหรือต่างประเทศ ซึ่งเป็นคำถามที่หลายองค์กรต้องตอบเวลาถูกตรวจสอบเรื่อง PDPA
- สิทธิ์เข้าถึงคอนโซล บัญชีที่สั่งลบหรือแก้ Policy ได้ควรแยกจากบัญชีโดเมนที่ใช้ทำงานประจำ และเปิด MFA
- การทดสอบกู้คืน Backup ถามว่ากู้ลงเครื่องทดสอบที่แยกจากระบบจริงได้หรือไม่ และมีค่าใช้จ่ายเพิ่มหรือเปล่า
- ราคา หน้าบริการคิดตามปริมาณข้อมูลจริง จำนวนเครื่อง และ Policy ไม่ได้ขายเป็นแพ็กเกจสำเร็จรูป จึงยังไม่มีตัวเลขราคาบนหน้า
เริ่มสำรองเซิร์ฟเวอร์ขึ้นคลาวด์กับ THAI DATA CLOUD
- สำรวจข้อมูลและกำหนด Policy นับเครื่อง ชนิดข้อมูล ปริมาณข้อมูล และปริมาณที่เปลี่ยนต่อวัน แล้วตกลง RPO กับระยะเก็บย้อนหลัง
- ติดตั้ง Agent บนเครื่องต้นทาง เครื่องเดิมทำงานตามปกติ
- Backup ชุดแรก จัดไว้นอกเวลาทำการ
- เข้าสู่รอบปกติ ตรวจสถานะทุกเครื่องผ่าน Control Panel
- ทดสอบกู้คืน Backup เลือกจุดเวลาจากปฏิทินแล้วกู้จริง พร้อม Support ตลอด 24 ชั่วโมง
ขอคำปรึกษาและใบเสนอราคาได้ฟรี ไม่มีข้อผูกมัด ที่หน้า On-Premise to Cloud Backup ของ THAI DATA CLOUD หรือโทร 098-894-2499, 082-653-2659 และ LINE @thaidatacloud
ติดตามข่าวคลาวด์และการสำรองข้อมูลอื่น ๆ ได้ที่หมวด Cloud
คำถามที่พบบ่อย
ทดสอบกู้คืน Backup ควรทำบ่อยแค่ไหน?
CISA แนะนำให้ทดสอบกระบวนการสำรองและกู้คืนอย่างสม่ำเสมอ โดยไม่ได้กำหนดความถี่ตายตัว แนวทางที่ใช้ได้จริงคือทดสอบกู้คืน Backup หลังตั้งระบบครั้งแรก หลังเปลี่ยนเซิร์ฟเวอร์หรือแอปสำคัญ และตามรอบที่ทีมกำหนดไว้ล่วงหน้า เช่น ทุกไตรมาส
ทดสอบกู้คืน Backup ต้องตรวจอะไรบ้าง?
ทดสอบกู้คืน Backup ให้ครบตามชนิดเครื่อง File Server ต้องเปิดไฟล์ได้จริง Application Server ต้องกู้ทั้งเครื่องแล้วแอปขึ้นได้ ฐานข้อมูลต้อง start ได้และข้อมูลไม่เพี้ยน และจดเวลาที่ใช้กู้กับจุดเวลาของข้อมูลที่ได้กลับมา เทียบกับ RTO และ RPO ที่ตั้งไว้
Backup บนคลาวด์ช่วยเรื่องแรนซัมแวร์ได้แค่ไหน?
ชุดสำรองบนคลาวด์อยู่นอกอาคารและไม่ได้ต่อค้างไว้ในวงแลนเดียวกับเครื่องต้นทาง จึงไม่โดนเหตุเดียวกันง่าย ๆ และการเก็บหลายจุดเวลาช่วยให้ย้อนไปก่อนวันติดเชื้อได้ แต่ backup ไม่ได้ป้องกันการโจมตี องค์กรยังต้องแบ่งเครือข่าย เปิด MFA และทดสอบกู้คืน Backup เป็นประจำ
On-Premise to Cloud Backup ต่างจากสำรองข้อมูล NAS ขึ้น Cloud อย่างไร?
On-Premise to Cloud Backup ติดตั้ง Agent บนเซิร์ฟเวอร์ต้นทาง เหมาะกับ File Server, Application Server และฐานข้อมูลที่ต้องกู้ทั้งเครื่องหรือกู้แบบรู้จักฐานข้อมูล ส่วน NAS Backup สำรองอุปกรณ์ NAS ผ่าน SMB และ NFS โดยไม่ต้องลง Agent หลายองค์กรใช้ทั้งสองแบบคู่กัน
แหล่งอ้างอิง
- Backup On Premise to Cloud Hybrid — THAI DATA CLOUD
- #StopRansomware: SafePay Ransomware — CISA
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- ประเทศและสถานที่
- สหรัฐอเมริกา613เยอรมนี140สหราชอาณาจักร257
- ผลิตภัณฑ์และเทคโนโลยี
- MySQL14SQL Server24LINE56
- กฎหมายและมาตรฐาน
- PDPA266
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ