การสำรองและปกป้องข้อมูล: RAID, NAS/SAN, SDS & VM Backup

สาระสำคัญของบทความ

RAID ป้องกันแค่ดิสก์เสีย — ไฟล์ถูกลบและ Ransomware ยังต้องพึ่ง Snapshot/Backup: RAID ≠ Backup
NAS = ไฟล์ผ่าน NFS/SMB, SAN = บล็อกผ่าน FC/iSCSI — เลือกตาม Workload ไม่ใช่ตามความคุ้นเคย
Storage สองชุดที่ Replicate เข้ากัน (Sync/Async) + ชุดละ 2 Controller — ดิสก์หรือคอนโทรลเลอร์พังก็ไม่มี Downtime
ระดับ VM: Backup แบบ Incremental ผ่าน CBT + Replica + สำเนา Immutable ตามหลัก 3-2-1-1-0 → RPO≈0 กู้คืนระดับนาที

3-2-1-1-0 หลักสำรองข้อมูล: 3 สำเนา 2 ชนิดสื่อ 1 ชุดนอกสถานที่ 1 ชุดกันแก้ (Immutable) และตรวจกู้คืนได้ 0 ข้อผิดพลาด

RPO ≈ 0 Data loss ใกล้ศูนย์เมื่อ Replicate แบบ Synchronous ระหว่าง Storage สองชุด

2 Controllers Active-Active + Cache Mirroring คอนโทรลเลอร์ตัวหนึ่งพัง งานไม่หยุด

ระดับนาที เวลากู้คืน VM จาก Replica/Backup เทียบกับการไล่ติดตั้ง Server ใหม่เป็นวัน

ปัญหาของข้อมูลยุคเดิม

ทำไมข้อมูลหนึ่งชุดต้องมีหลายชั้นของการปกป้อง

ดิสก์เสียเป็นแค่ 1 ใน 4 สาเหตุของการเสียข้อมูล — ความผิดพลาดของมนุษย์, Ransomware และเหตุระดับอาคาร ต้องการคนละเครื่องมือการปกป้อง การพึ่งชั้นเดียวจึงไม่เคยพอ

ดิสก์เสีย 1–2 ลูก

แก้ด้วย RAID (Parity/Mirror) + Hot Spare — ระบบยังรันต่อได้ระหว่างเปลี่ยนดิสก์

คนลบไฟล์ผิด

RAID ไม่รู้ว่าไฟล์ไหนถูกต้องลบ — ต้องพึ่ง Snapshot/Backup ย้อนเวลา (History) เท่านั้น

Ransomware

เข้ารหัสข้อมูลทุกสำเนาที่มองเห็น — ต้องมีสำเนา Immutable (WORM) และ Air-Gap ที่แก้ไม่ได้

เหตุทั้งไซต์

ไฟดับ น้ำท่วม ไฟไหม้ — เครื่องเดียว/ตู้เดียวเอาไม่อยู่ ต้องมี Storage ชุดที่ 2 คนละที่

Protect RAID + Cache ที่กันไฟดับ ป้องกันดิสก์เสียและการเขียนขาดหาย

Redundant 2 Controller ในตู้เดียว Active-Active พังครึ่งใบงานไม่หยุด

Replicate ทำสำเนาไป Storage ชุดที่ 2 ทันที (RPO≈0) ผ่าน Replication

Back up สำรองเป็น Version บน Media อื่น นอกสถานที่ และ Immutable (WORM)

Verify ทดสอบกู้คืนจริงตามรอบ (Restore Test) ให้ได้ 0 ข้อผิดพลาดตามหลัก 3-2-1-1-0

1. ชั้นที่ 1: Hardware RAID

1. Hardware RAID ชั้นแรกของการปกป้องข้อมูล

ก่อนจะไปถึง Replication หรือ Backup ทุกตู้ Array เริ่มจากชั้นเดียวกัน: เอาดิสก์หลายลูกมาจัดเป็น RAID เพื่อทนการเสียของดิสก์ และ Cache บนคอนโทรลเลอร์ที่กันข้อมูลเขียนขาดหาย

1.1 ระดับ RAID ที่ใช้จริงในตู้ Array

ระดับ RAID	วิธีทำงาน	ทนดิสก์เสีย	เหมาะกับ
RAID 1 (Mirror)	เขียนดิสก์ 2 ลูกเหมือนกันทุกบิต พื้นที่เหลือใช้ 50%	1 ลูก	พาร์ทิชัน OS/Boot และ Volume สำคัญขนาดเล็ก
RAID 5	Parity กระจายทั่วดิสก์ — พื้นที่เหลือใช้ n−1 ลูก แต่ช่วง Rebuild เสี่ยง URE กับดิสก์ความจุสูง	1 ดวง (+เสี่ยงดวงช่วง Rebuild)	งานอ่านเป็นหลักที่งบจำกัด
RAID 6	Parity สองชุด — เหลือใช้ n−2 ลูก ปลอดภัยกว่ากับดิสก์ลูกใหญ่	2 ลูกพร้อมกัน	Volume ข้อมูลทั่วไปขององค์กร (ค่าเริ่มต้นขององค์กรทั่วไป)
RAID 10	Mirror + Stripe เร็วสุด ค่าใช้จ่ายสูงสุด (เหลือใช้ 50%)	1 ลูกต่อกลุ่ม Mirror	Database / VMFS ที่ต้องการ IOPS สูง

1.2 สิ่งที่ RAID ทำได้มากกว่าที่คุณคิด (และสิ่งที่มันทำไม่ได้)

Write-Back Cache + แบตเตอรี่/ซูปเปอร์แคป

คอนโทรลเลอร์รับ Write ไว้ใน Cache ทันที (Write-Back) แล้วค่อยเขียนลงดิสก์ — แบต/ซูปเปอร์แคปบนการ์ด (BBU/Flash Vault) คอยประคองข้อมูลใน Cache ยามไฟดับ เมื่อไม่มีแบตเตอรี่ คอนโทรลเลอร์จะลดตัวเองเป็น Write-through อัตโนมัติ (เขียนช้าลงมากแต่ข้อมูลไม่หาย)

Hot Spare & Rebuild

ดิสก์เสีย → คอนโทรลเลอร์เปลี่ยนไปอ่าน Parity จากลูกอื่นทันทีและ Rebuild เข้า Hot Spare อัตโนมัติ แต่ช่วง Rebuild คือหน้าต่างของ URE (Unrecoverable Read Error) ที่อาจกลายเป็นดิสก์ลูกที่สองพังเงียบ ๆ

RAID ไม่ใช่ Backup

RAID ทำให้ระบบ 'ไม่หยุด' เมื่อดิสก์พัง แต่มันไม่รู้จักเวลา — ลบผิดไฟล์, Ransomware หรือ Silent Corruption ถูกเขียนกระจายไปทุกลูกใน Array อย่างซื่อสัตย์ ประวัติของข้อมูลต้องมาจาก Snapshot/Backup เท่านั้น (หัวข้อถัด ๆ ไป)

2. ชั้นที่ 2: NAS และ SAN

2. NAS หรือ SAN: ระดับไฟล์ หรือระดับบล็อก

เมื่อข้อมูลต้องออกจากเซิร์ฟเวอร์ตัวเดียวไปสู่ระบบส่วนกลาง มีให้เลือก 2 ตระกูลตามระดับที่โปรโตคอลมองเห็น: NAS ให้บริการ 'ไฟล์' ผ่าน NFS/SMB บน Ethernet ทั่วไป ส่วน SAN ให้บริการ 'บล็อก (LUN)' ผ่าน Fibre Channel/iSCSI ผ่านเครือข่าย Storage แยกต่างหาก

สถาปัตยกรรม NAS/SAN แบบ Dual Controller พร้อมลิงก์ Replication

NAS — File-Level ผ่าน NFS/SMB

แชร์ไฟล์/โฟลเดอร์ผ่านโปรโตคอลไฟล์บนแลนทั่วไป — Home Directory, NFS Datastore และ Backup Repository

ประเด็น	NAS (File-Level)	SAN (Block-Level)
โปรโตคอล	NFS v4.1 / SMB 3 บน Ethernet 10–25GbE เดิมขององค์กร	Fibre Channel / iSCSI / NVMe-oF บน Fabrics แยก + Multipath
สิ่งที่ Host มองเห็น	Path/Folder ที่แชร์พร้อมสิทธิ์ ACL ระดับไฟล์	Lun ที่ OS มองเป็นดิสก์ท้องถิ่น (Raw Block)
เหมาะกับ	ไฟล์องค์กร, NFS Datastore ให้ VM, NAS สำรองข้อมูล/Backup Repository	Database หลัก, Cluster ที่ต้องการ Latency ต่ำ/IOPS สูง
การป้องกันข้อมูลในตัว	Snapshot ระดับไฟล์/แชร์, Object Lock/WORM, Replication ข้ามไซต์	Snapshot ระดับ LUN, Metro Replication, Thin-provision

หมายเหตุจากงานจริง: Array ยุคใหม่ส่วนใหญ่เป็น Unified — กล่องเดียวพูดได้ทั้ง NFS, SMB และ iSCSI/FC ดังนั้นโจทย์การเลือกจึงไม่ใช่ 'NAS หรือ SAN ดีกว่ากัน' แต่คือ 'Workload นี้ควรใช้โปรโตคอลระดับไหน' — File Service = NAS, Core DB/Cluster = SAN

3. ชั้นที่ 3: SDS

3. Software-Defined Storage: สมองของ Storage ย้ายไปอยู่ในซอฟต์แวร์

แทนที่จะล็อกความฉลาดของ Storage ไว้ในคอนโทรลเลอร์ราคาแพงของผู้ขายเจ้าเดียว SDS ใช้ซอฟต์แวร์ (Ceph, ZFS/TrueNAS, VMware vSAN, Proxmox PVE/PBS) รวมดิสก์จากหลายเครื่องให้เป็น Pool เดียวแล้วบริหารด้วยนโยบาย — เหมือนที่ Hypervisor ทำกับ CPU/RAM ในบทความ Virtual Machine

Pool จากหลายโหนด ขยายแบบ Scale-Out

ซอฟต์แวร์จัดเก็บรวมดิสก์จาก Server 3–4 ตัวเป็น Pool เดียว ขยายความจุด้วยการ 'เพิ่มโหนด' แทนการซื้อ JBOD ใบใหม่ และกระจายข้อมูลทั่วทั้งคลัสเตอร์

Erasure Coding แทน Hardware RAID

แทน Parity บนตู้เดียว Erasure Coding กระจายข้อมูล+Parity ข้าม 'โหนด' ทั้งคลัสเตอร์ (เช่น Replicas=2/3, EC 4+2) — โหนดทั้งเครื่องพังก็ยังอ่านข้อมูลได้ และ Rebuild เร็วเพราะทุกโหนดช่วยกันอ่าน

SDS + Hypervisor = HCI

เมื่อ Storage เป็นซอฟต์แวร์บน Server ตัวเดียวกับที่รัน VM (HCI) นโยบายข้อมูลจะย้ายมาอยู่กับ VM: กำหนดจำนวน Replica และ Policy ต่อ VM ได้โดยตรง — ต่อเนื่องจากบทความ Virtual Machine & HCI

Open Source = ลดค่า License

Ceph, ZFS และ Proxmox PBS เป็น Open Source — จ่ายเฉพาะ Support ที่เลือกซื้อได้เหมือน Hypervisor ทางเลือกในยุคที่ License แบบ Subscription มีต้นทุนสูงขึ้น

Array แบบดั้งเดิม (Dual Controller)

กล่องพร้อมคอนโทรลเลอร์ 2 ตัว + JBOD — ง่าย มี SLA ผู้ขาย รองรับผ่าน Multipath แต่ขยายความจุทีละชั้น (Scale-Up) ตามที่ผู้ขายกำหนด

SDS / HCI

ซอฟต์แวร์รันบน x86 มาตรฐาน รวมดิสก์ทั้งคลัสเตอร์เป็น Pool เดียว ขยายด้วย 'การเพิ่มโหนด' ไม่มีจุดตายที่คอนโทรลเลอร์เดียว เพราะความฉลาดกระจายอยู่ทุกโหนด

4. ชั้นที่ 4: Dual Controller

4. Dual Controller: เมื่อคอนโทรลเลอร์ครึ่งตู้ต้องพังได้

RAID แก้ปัญหาดิสก์ลูกเดียวพัง แต่ถ้าคอนโทรลเลอร์ของตู้ทั้งตู้เสีย ลูนทั้งหมดจะหายไปด้วย — Array ระดับองค์กรจึงใส่คอนโทรลเลอร์มา 2 ตัวเสมอ นี่คือชั้นที่ 'งานไม่หยุด' แม้ฮาร์ดแวร์ครึ่งระบบจะล้ม

Active–Active / ALB

คอนโทรลเลอร์ทั้งสองตัว 'รับ IO พร้อมกัน' คนละครึ่งของลูน (Asymmetric Load Balancing) ไม่ใช่ตัวสำรองเงียบ ๆ — โหลดถูกแบ่งสองทางเสมอ และเมื่ออีกตัวเสีย อีกตัวจะรับ LUNs ทั้งหมดมาถือไว้ชั่วคราว

Cache Mirroring

Write ที่ยังค้างใน Cache ของคอนโทรลเลอร์ Active ถูก Mirror ข้ามไป Cache ของอีกตัวทันที — ไฟดับหรือคอนโทรลเลอร์พังกลางอากาศ ข้อมูลที่ถูก Acknowledged แล้วก็ไม่หาย (Write-Back ต่อเนื่อง)

Multipath + Hot Swap

Host ทุกตัวเดินสาย 2 เส้นทางผ่าน Switch Storage 2 ตัว (Multipath) — เส้นทาง/คอนโทรลเลอร์ที่เสียจะถูกสลับอัตโนมัติในระดับวินาที และเปลี่ยนคอนโทรลเลอร์/PSU ที่เสียได้สด ๆ โดยไม่ต้องปิดระบบ

สิ่งที่ Dual Controller ไม่ทำให้

มันซื้อ 'ความพร้อมใช้งาน' ไม่ได้ซื้อ 'ประวัติของข้อมูล' — ไฟล์ที่ถูกลบหรือถูก Ransomware เข้ารหัสไปแล้ว ก็ถูก Mirror ไปอีกคอนโทรลเลอร์อย่างซื่อสัตย์เช่นกัน ถึงตรงนี้ต้องพึ่ง Replication และ Backup ในหัวข้อถัดไป

5. ชั้นที่ 5: Replication

5. การ Replicate ข้อมูลระหว่าง NAS/SAN สองชุด

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

โหมด Replication	วิธีทำงาน	RPO	ข้อจำกัด/ระยะทาง
Synchronous (Sync)	Mirror ข้อมูลที่เขียนทุกบิตไปชุดที่ 2 ก่อน แล้วค่อยส่งสัญญาณ Ack กลับ Host	≈0 (ไม่เสียข้อมูลเลย)	ต้อง Latency ต่ำ (ระยะ Metro ~<100 กม.) กิน Bandwidth และ Write Latency สูงขึ้น
Asynchronous (Async)	Ack Host ทันทีบนชุดหลัก เก็บ Delta ค้างไว้แล้วส่งตามรอบไปยังชุดที่ 2	วินาที–นาที	ไกลแค่ไหนก็ได้ กิน Bandwidth น้อย แต่ข้อมูลช่วงท้ายจะเสียหากไซต์หลักพัง
Snapshot-Based	ส่งเฉพาะ Delta จากรอบ Snapshot ก่อนหน้า — เป็นวิธีหลักของ NAS ยุคใหม่ (เช่น Snapshot Replication)	ตามรอบ Snapshot (นาที–ชม.)	มีประสิทธิภาพสูงบน WAN แต่ประวัติทั้งหมดอยู่ใน Storage ทั้งสองชุด

5.1 Replication ไม่ใช่ Backup

Replica คือสำเนา 'ที่มีชีวิต'

Ransomware ที่เข้ารหัสชุดหลัก ก็ลามไปเข้ารหัส Replica ผ่าน Replication ด้วยเสมอ — ประวัติย้อนเวลาต้องมาจาก Snapshot ที่มี Version + Immutable (WORM/Object-Lock) และสำเนา Air-Gap เท่านั้น

สถาปัตยกรรมสองชุด: Primary + DR

ชุด Production ประสานงานประจำวัน — ชุดที่ 2 (คนละห้อง/คนละอาคาร) เก็บ Replica + สำรองข้อมูลเป็น Version + สำเนา Offline ตามหลัก 3-2-1-1-0 ครบข้อ: 2 สื่อ, 1 นอกสถานที่, 1 Immutable

Failover & ทดสอบ DR จริง

เมื่อ Site หลักล่ม ให้เปิดบริการจาก Replica (Failover) แล้วค่อยย้ายกลับ (Failback) — ต้องซ้อมเป็นรายไตรมาส เพราะ 'การกู้คืนที่ไม่เคยทดสอบ คือการกู้คืนที่ไม่ได้' ตามข้อ 0 ของ 3-2-1-1-0

6. ชั้นที่ 6: VM Layer

6. ใช้ VM ช่วยปกป้องข้อมูล: จาก Snapshot ถึง Instant Recovery

งานขององค์กรปัจจุบันรันอยู่บน VM เกือบหมด (ต่อจากบทความ Virtual Machine) การสำรองข้อมูลยุคใหม่จึงจัดการที่ระดับ 'เครื่องเสมือน' ทั้งเครื่อง แทนที่จะไล่ Backup ทีละแอปพลิเคชัน

Snapshot ≠ Backup

Snapshot ของ Hypervisor เก็บบน Array ตัวเดิม Controller ตัวเดิมกับข้อมูลจริง — Ransomware ที่ลามเข้า Storage ก็เจอทั้งคู่อันแรก เก็บไว้กัน User ลบผิดไม่กี่วันเท่านั้น ไม่ใช่ประวัติระยะยาว

Agentless Incremental ผ่าน CBT

Hypervisor (VMware CBT / Proxmox Dirty Bitmap) จดจำให้ว่า Block ไหนเปลี่ยนตั้งแต่รอบก่อน — Backup Server จึงก๊อปเฉพาะ 'ส่วนต่าง' ทุกคืน ไม่ต้อง Agent ใน VM และไม่ต้อง Backup เต็มซ้ำทุกคืน

Repository คือ NAS ในบทความนี้

ไฟล์สำรองที่ Dedup+Compress แล้วควรอยู่บน NAS อีกชุดหนึ่ง (Backup Repository) แบบ Immutable/WORM — และ NAS ตัวนั้นเองก็ Replication ข้ามไซต์ตามหัวข้อ 5: ผู้ปกป้องข้อมูลของคนอื่น ก็ต้องถูกปกป้องตัวเอง

Replica + Instant VM Recovery

Backup รุ่นใหม่ส่งดิสก์ของ VM ไปเป็น Replica ที่ไซต์ B อย่างต่อเนื่อง — เมื่อ Host พัง ก็ Boot VM จาก Replica หรือจากไฟล์ Backup ได้ทันทีระดับนาที แล้วค่อยย้ายกลับหลังซ่อมเสร็จ

7. บทสรุป

7. สรุป: ออกแบบทั้ง 5 ชั้นให้ทำงานร่วมกัน

ไม่มีชั้นใดชั้นหนึ่งปกป้องข้อมูลได้ลำพัง — RAID/Controller ซื้อความพร้อมใช้งาน Replication ซื้อ RPO≈0 และ Backup แบบ Immutable ซื้อประวัติที่เปลี่ยนไม่ได้ เมื่อประกอบกันตามหลัก 3-2-1-1-0 องค์กรก็กู้คืนได้ทุกสถานการณ์

เลือกชั้นตามภัย ไม่ใช่ตามความเคยชิน

ดิสก์เสีย→RAID · คอนโทรลเลอร์เสีย→Dual Controller · ไซโลข้อมูลเสีย→Replication 2 ชุด · ไฟล์เสีย/ ransomware→Immutable Backup + VM Backup

เลือก NAS หรือ SAN ตาม Workload

ไฟล์/Backup Repository → NAS (NFS/SMB) · Database/Cluster IOPS สูง → SAN (FC/iSCSI) และเมื่อเป็น SDS ทั้ง Storage Layer จะกลายเป็นนโยบายต่อ VM เช่นในบทความ Virtual Machine

3-2-1-1-0 เป็นแบบแปลน

3 สำเนา 2 ชนิดสื่อ 1 นอกสถานที่ 1 Immutable ตรวจกู้คืนจริงจนเหลือ 0 ข้อผิดพลาด

สองชุดเสมอ

Primary + DR คนละตู้ คนละห้อง/คนละอาคาร Sync ในอาคารเดียว Async ข้ามสาขา

สำรองที่ระดับ VM

CBT Incremental + Live Replica + Instant VM Recovery = กู้คืนระดับนาที

พร้อมสู่ SDS

Ceph/ZFS/PBS เป็น Open Source จ่ายแค่ Support ต่อเนื่องจากยุค Hypervisor ทางเลือก

อ่านต่อ: วิวัฒนาการของ Virtual Machine ดูผลิตภัณฑ์ Storage & Backup โซลูชันปกป้องข้อมูลธุรกิจ

เขียนโดย Supakiat L.

Supakiat L. เขียนจากงานจริงของทีมวิศวกร BKV และจะเขียนบทความใหม่ลงบอร์ดองค์ความรู้เรื่อย ๆ

การสำรองและปกป้องข้อมูล: จาก Hardware RAID สู่ Software-Defined Storage