Snapshot คืออะไร? เข้าใจ Synology Snapshot, Immutable Snapshot และ Backup 3-2-1

เมื่อพูดถึงการป้องกันข้อมูลบน NAS หลายคนมักนึกถึง RAID หรือการสำรองข้อมูลไปยังฮาร์ดดิสก์ภายนอกเป็นอันดับแรก แต่ยังมีอีกเทคโนโลยีหนึ่งที่ช่วยให้สามารถย้อนข้อมูลกลับไปยังช่วงเวลาก่อนเกิดปัญหาได้อย่างรวดเร็ว นั่นคือ Snapshot

Snapshot มีประโยชน์อย่างมากเมื่อผู้ใช้ลบไฟล์ผิด แก้ไขเอกสารทับไฟล์เดิม ระบบติดมัลแวร์ หรือไฟล์จำนวนมากถูกเข้ารหัสจาก Ransomware เพราะผู้ดูแลระบบสามารถเปิดดูสถานะของข้อมูล ณ เวลาก่อนเกิดเหตุ แล้วคัดลอกหรือกู้คืนข้อมูลกลับมาได้โดยไม่ต้องรอ Restore จากชุดสำรองขนาดใหญ่ทั้งหมด

อย่างไรก็ตาม Snapshot ไม่ได้ทำงานเหมือนการ Copy Folder และไม่ใช่ Backup ที่สามารถทดแทนการเก็บสำเนาข้อมูลไว้อีกอุปกรณ์หรืออีกสถานที่ได้ทั้งหมด บทความนี้จึงจะอธิบายตั้งแต่พื้นฐานว่า Snapshot คืออะไร ทำงานอย่างไร ใช้พื้นที่อย่างไร เหตุใด Snapshot บางรายการจึงแสดงขนาด 0 GB รวมถึงความแตกต่างระหว่าง Snapshot, Snapshot Replication, Immutable Snapshot และการสำรองข้อมูลขึ้น Object Storage เช่น Wasabi ตามหลัก 3-2-1 และ 3-2-1-1-0

หมายเหตุสำคัญ: ตัวอย่าง Day 1 ถึง Day 8 ในบทความนี้อ้างอิงลำดับเหตุการณ์จากเอกสาร “Understand How Snapshot Size Is Calculated” โดยตรง เอกสารต้นฉบับมีตัวอย่างถึง Day 8 เท่านั้น

Snapshot คืออะไร?

Snapshot คือภาพสถานะของข้อมูล ณ จุดเวลาหนึ่ง หรือ Point-in-Time Copy ซึ่งช่วยให้ระบบจดจำว่าในช่วงเวลาที่สร้าง Snapshot นั้น Shared Folder, ไฟล์ หรือ LUN มีสถานะเป็นอย่างไร

คำว่า “ภาพ” ในที่นี้ไม่ได้หมายความว่าระบบถ่ายสำเนาข้อมูลทั้งหมดขึ้นมาอีกหนึ่งชุด แต่หมายถึงการเก็บข้อมูลอ้างอิงของระบบไฟล์และรักษา Block เดิมที่จำเป็นต่อการย้อนกลับไปยังเวลานั้น ดังนั้นการสร้าง Snapshot ของ Shared Folder ที่มีข้อมูลหลายเทราไบต์จึงสามารถทำได้รวดเร็ว และในช่วงแรกอาจใช้พื้นที่เพิ่มเพียงเล็กน้อยหรือแสดงเป็น 0 GB

บน Synology NAS ฟังก์ชัน Snapshot สำหรับ Shared Folder ทำงานผ่านแพ็กเกจ Snapshot Replication และต้องใช้งานบน Volume ที่เป็นระบบไฟล์ Btrfs รวมถึงต้องเป็นรุ่น NAS ที่รองรับความสามารถดังกล่าว

Snapshot ไม่ใช่การ Copy ไฟล์ทั้งโฟลเดอร์

สมมติว่ามี Shared Folder ขนาด 5 TB หากเรา Copy ข้อมูลทั้งหมดไปไว้อีกโฟลเดอร์ ระบบจะต้องอ่านและเขียนข้อมูลจำนวนประมาณ 5 TB ใช้เวลานาน และต้องมีพื้นที่ว่างใกล้เคียงกับข้อมูลต้นฉบับ

แต่การสร้าง Snapshot ไม่จำเป็นต้องคัดลอกข้อมูล 5 TB ทั้งหมดในทันที ระบบจะสร้างจุดอ้างอิงของสถานะข้อมูลในขณะนั้น และเริ่มใช้พื้นที่เพิ่มเมื่อข้อมูลเดิมถูกแก้ไขหรือลบ แต่ Snapshot เก่ายังจำเป็นต้องรักษาข้อมูลเดิมไว้เพื่อให้ย้อนกลับได้

Shared Folder ปัจจุบัน
        │
        ├── Snapshot เวลา 09:00
        ├── Snapshot เวลา 12:00
        └── Snapshot เวลา 15:00

แต่ละ Snapshot ไม่จำเป็นต้องมีสำเนาไฟล์ทั้งหมดแยกจากกัน
ระบบสามารถใช้ Block ที่ยังเหมือนกันร่วมกันได้

หลักการ Copy-on-Write และ Block-Level ทำงานอย่างไร?

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

ไฟล์ Database.db
[Block A] [Block B] [Block C] [Block D]

เมื่อมี Snapshot และแอปพลิเคชันแก้ไขเฉพาะ Block B ระบบจะต้องรักษา Block B เวอร์ชันเดิมไว้ให้ Snapshot เก่าอ้างอิง ขณะเดียวกันสถานะปัจจุบันจะเขียนข้อมูลเวอร์ชันใหม่ลงใน Block ใหม่

Snapshot เดิม:   [A] [B เดิม] [C] [D]
ข้อมูลปัจจุบัน:  [A] [B ใหม่] [C] [D]

ดังนั้นพื้นที่ที่ Snapshot ใช้เพิ่มจึงสัมพันธ์กับ ปริมาณข้อมูลที่เปลี่ยนแปลง ไม่ได้สัมพันธ์กับขนาดรวมของ Shared Folder เพียงอย่างเดียว หากมีข้อมูล 10 TB แต่เปลี่ยนแปลงวันละ 20 GB พื้นที่ Snapshot จะเติบโตตาม Block ที่เปลี่ยนหรือลบ ไม่ได้เพิ่มวันละ 10 TB

อย่างไรก็ตาม การคำนวณจริงอาจแตกต่างจากการรวมขนาดไฟล์ด้วยมือ เพราะระบบจัดการในระดับ Block มี Metadata, การจัดสรรพื้นที่ และ Block ที่อาจถูกอ้างอิงร่วมกันระหว่างหลาย Snapshot

เหตุใด Snapshot แรกจึงอาจมีขนาด 0 GB?

ในเวลาที่สร้าง Snapshot แรก ข้อมูลปัจจุบันและข้อมูลใน Snapshot ยังคงอ้างอิง Block ชุดเดียวกันทั้งหมด ระบบจึงยังไม่จำเป็นต้องเก็บ Block เก่าเพิ่มเติม หากหลังจากนั้นมีการเพิ่มไฟล์ใหม่อย่างเดียว โดยไม่มีการแก้ไขหรือลบข้อมูลที่ Snapshot เดิมอ้างอิง พื้นที่ Snapshot ก็อาจยังคงเป็น 0 GB

Snapshot จะเริ่มใช้พื้นที่อย่างชัดเจนเมื่อเกิดสถานการณ์ต่อไปนี้

• ไฟล์ที่มีอยู่ก่อนสร้าง Snapshot ถูกลบ
• ไฟล์เดิมถูกแก้ไขหรือเขียนทับ
• ฐานข้อมูลหรือ Virtual Machine มี Block เปลี่ยนแปลงจำนวนมาก
• มีการเปลี่ยนชื่อ ย้าย หรือปรับโครงสร้างข้อมูลในลักษณะที่ทำให้ระบบต้องรักษา Block เดิม

ตัวอย่างการคำนวณ Snapshot Size แบบ Day 1 ถึง Day 8

ตัวอย่างต่อไปนี้ตั้งค่าให้สร้าง Snapshot วันละหนึ่งครั้ง และเก็บไว้ไม่เกิน 5 วัน รูป Day 1 ถึง Day 8 สามารถนำมาจาก PDF แล้วเปลี่ยนค่า src ของแต่ละภาพให้ตรงกับตำแหน่งไฟล์จริงบนเว็บไซต์

Day 1: สร้าง Snapshot ครั้งแรก

วันแรกมีไฟล์ A ขนาด 5 GB, B ขนาด 10 GB และ C ขนาด 20 GB เมื่อสร้าง Snapshot 1 ระบบยังใช้ Block ชุดเดียวกับข้อมูลปัจจุบันทั้งหมด จึงรายงานขนาด Snapshot เป็น 0 GB

จุดสำคัญคือ Snapshot ไม่ได้คัดลอกข้อมูลรวม 35 GB ขึ้นมาอีกชุด แต่เพียงสร้างจุดอ้างอิงของสถานะข้อมูลในเวลานั้น

Day 2: เพิ่มไฟล์ D แต่ Snapshot ยังไม่โต

วันที่สองมีการเพิ่มไฟล์ D ขนาด 30 GB แต่ไฟล์ A, B และ C ยังคงเหมือนเดิม การเพิ่มไฟล์ใหม่ไม่ได้ทำให้ Snapshot 1 ต้องรักษา Block เก่าเพิ่มเติม เพราะไฟล์ D ไม่เคยอยู่ใน Snapshot 1 ตั้งแต่แรก

ดังนั้น Snapshot 1 จึงยังมีขนาด 0 GB แม้ว่าขนาดข้อมูลปัจจุบันของ Shared Folder จะเพิ่มขึ้นแล้วก็ตาม

Day 3: ลบไฟล์ A แต่ข้อมูลยังไม่หายจากดิสก์จริง

วันที่สามไฟล์ A ขนาด 5 GB ถูกลบออกจาก Shared Folder ผู้ใช้งานจึงมองไม่เห็นไฟล์นี้ใน File Station แล้ว แต่ Snapshot ก่อนหน้ายังต้องสามารถย้อนกลับไปยังสถานะที่มีไฟล์ A ได้ ระบบจึงยังไม่สามารถคืนพื้นที่ 5 GB ของไฟล์ A ให้กับ Storage Pool ได้

กล่าวอีกอย่างคือ ไฟล์ A “หายจากมุมมองปัจจุบัน” แต่ Block ของไฟล์ยังถูกเก็บไว้เพราะ Snapshot ล็อกการอ้างอิงอยู่

Day 4: Snapshot เริ่มแสดงพื้นที่ 5 GB

วันที่สี่มีการลบไฟล์ C ขนาด 20 GB และเพิ่มไฟล์ E กับ F ขึ้นมา ขณะนี้ Snapshot 3 แสดงขนาด 5 GB เพราะต้องเก็บข้อมูลของไฟล์ A ที่ไม่มีอยู่ในสถานะปัจจุบันแล้ว

ส่วนไฟล์ C เพิ่งถูกลบหลังจากจุดเวลาของ Snapshot 3 ดังนั้นพื้นที่ของ C จะไปปรากฏกับ Snapshot รุ่นถัดไปที่ต้องรักษาสถานะก่อนการลบนั้น

Day 5: Snapshot เก็บข้อมูลของไฟล์ C เพิ่มอีก 20 GB

วันที่ห้ามี Snapshot 3 ขนาด 5 GB สำหรับข้อมูลของไฟล์ A และ Snapshot 4 ขนาด 20 GB สำหรับข้อมูลของไฟล์ C รวมพื้นที่ข้อมูลเก่าที่ถูกเก็บเพราะ Snapshot ประมาณ 25 GB

ไฟล์ G และ H ที่เพิ่มเข้ามาใหม่ไม่ทำให้ Snapshot เก่าใช้พื้นที่เพิ่ม เพราะไฟล์เหล่านี้ไม่ได้มีอยู่ใน Snapshot ก่อนหน้า

Day 6: เริ่มเกิด Snapshot Rotation

เมื่อกำหนด Retention ไว้ 5 วัน Snapshot ที่เก่าเกินนโยบายจะเริ่มถูก Rotate ออก แต่การลบ Snapshot หนึ่งรายการไม่ได้หมายความว่าพื้นที่ที่มองเห็นใน Snapshot นั้นจะถูกคืนทันทีเสมอไป

สาเหตุคือ Block เดียวกันอาจยังถูก Snapshot รายการอื่นอ้างอิงอยู่ ตราบใดที่ยังมี Snapshot อย่างน้อยหนึ่งรายการต้องใช้ Block นั้นเพื่อการกู้คืน ระบบจะยังไม่ปล่อยพื้นที่กลับไปใช้งาน

Day 7: ลบ Snapshot เพิ่ม แต่ Block เดิมยังถูกอ้างอิง

วันที่เจ็ด Snapshot เก่าถูก Rotate ออกเพิ่มขึ้น แต่ข้อมูลของไฟล์ A และ C ยังไม่ถูกลบจากระบบทั้งหมด เพราะ Snapshot ที่ยังเหลืออยู่ยังต้องอ้างอิง Block เหล่านั้น

นี่คือเหตุผลที่ผู้ดูแล NAS บางรายลบ Snapshot ไปหนึ่งหรือสองรายการแล้วพบว่าพื้นที่ว่างแทบไม่เปลี่ยน ระบบไม่ได้ทำงานผิด แต่กำลังรักษา Block ที่ยังจำเป็นต่อ Snapshot อื่นอยู่

Day 8: Snapshot ที่อ้างอิงไฟล์ A หมดอายุและคืนพื้นที่ได้

วันที่แปด Snapshot 3 ซึ่งเป็น Snapshot สุดท้ายที่ต้องใช้ข้อมูลของไฟล์ A ถูก Rotate ออก เมื่อไม่มี Snapshot ใดอ้างอิง Block ของ A แล้ว ระบบจึงสามารถลบข้อมูลนั้นอย่างถาวรและคืนพื้นที่ประมาณ 5 GB กลับมาได้

ส่วนไฟล์ C ขนาด 20 GB ยังถูก Snapshot 4 อ้างอิงอยู่ จึงยังคงใช้พื้นที่ต่อไปจนกว่า Snapshot ที่เกี่ยวข้องจะหมดอายุหรือลบออกทั้งหมด

สรุปสูตรคิดพื้นที่ Snapshot แบบเข้าใจง่าย

แนวคิดพื้นฐานสามารถสรุปได้ว่า

พื้นที่ Snapshot โดยประมาณ
=
Block เดิมที่ถูกแก้ไขหรือลบ
และยังมี Snapshot อย่างน้อยหนึ่งรายการอ้างอิงอยู่

จึงไม่ควรใช้สูตร “ขนาด Shared Folder × จำนวน Snapshot” เพราะ Snapshot แต่ละรายการสามารถแชร์ Block ที่ไม่เปลี่ยนแปลงร่วมกันได้

ตัวอย่าง Shared Folder ขนาด 10 TB มีการเปลี่ยนแปลงเฉลี่ยวันละ 50 GB และเก็บ Snapshot รายวัน 30 วัน พื้นที่ Snapshot อาจอยู่ในระดับใกล้เคียงกับปริมาณ Block ที่เปลี่ยนในช่วง 30 วัน ไม่ใช่ 10 TB คูณ 30 แต่ตัวเลขจริงยังขึ้นอยู่กับรูปแบบการเขียนข้อมูล การแก้ไขซ้ำ Block เดิม การลบไฟล์ และการจัดสรรพื้นที่ของระบบไฟล์

ทำไมลบไฟล์แล้วพื้นที่ว่างไม่เพิ่มทันที?

เมื่อมี Snapshot อยู่ การลบไฟล์ออกจาก File Station ไม่ได้แปลว่า Block ของไฟล์จะถูกลบออกจากดิสก์ทันที หาก Snapshot เก่ายังต้องใช้ข้อมูลนั้น ระบบต้องรักษา Block ไว้เพื่อให้สามารถ Browse, Copy หรือ Restore ไฟล์จากช่วงเวลาก่อนลบได้

พื้นที่จะกลับคืนเมื่อครบทั้งสองเงื่อนไขต่อไปนี้

1. ไฟล์หรือ Block นั้นไม่มีอยู่ในข้อมูลปัจจุบันแล้ว
2. ไม่มี Snapshot รายการใดอ้างอิง Block นั้นอีกต่อไป

ดังนั้นก่อนลบ Snapshot เพื่อเร่งคืนพื้นที่ ควรตรวจสอบว่า Snapshot นั้นยังจำเป็นต่อ Recovery Point Objective หรือไม่ เพราะการลบ Snapshot เป็นการลดจำนวนจุดย้อนกลับของข้อมูล

Snapshot ช่วยกู้คืนอะไรได้บ้าง?

Snapshot เหมาะกับการกู้คืนเหตุการณ์ที่เกิดขึ้นกับข้อมูลใน Shared Folder หรือ LUN เช่น

• ผู้ใช้ลบไฟล์หรือโฟลเดอร์ผิด
• เอกสารถูกแก้ไขทับและต้องการย้อนเวอร์ชัน
• ไฟล์จำนวนมากเสียหายจากโปรแกรมหรือสคริปต์
• Ransomware เข้ารหัสไฟล์ที่ผู้ใช้เข้าถึงได้
• ฐานข้อมูลหรือ Application Data มีความผิดพลาดหลังการเปลี่ยนแปลง
• ต้องการตรวจสอบหรือคัดลอกไฟล์จากสถานะก่อนหน้าโดยไม่ Restore ทั้ง Shared Folder

Synology Snapshot Replication รองรับการ Browse Snapshot, คัดลอกไฟล์ออกมา และ Restore Shared Folder ไปยังจุดเวลาก่อนหน้า ส่วนการ Replication ไปอีก Synology NAS ช่วยให้มีสำเนา Snapshot ที่ปลายทางและรองรับการทำ Switchover หรือ Failover ตามรูปแบบการติดตั้ง

Snapshot มีข้อดีอะไร?

1. สร้างได้รวดเร็ว

เพราะไม่จำเป็นต้อง Copy ข้อมูลทั้งหมด การสร้าง Snapshot จึงใช้เวลาไม่นานและกระทบงานประจำค่อนข้างต่ำเมื่อเทียบกับการสำรองข้อมูลเต็มชุด

2. Restore ได้รวดเร็ว

ผู้ดูแลสามารถย้อน Shared Folder หรือคัดลอกเฉพาะไฟล์ที่ต้องการกลับมาได้ เหมาะกับเหตุการณ์ที่ต้องลด Downtime

3. ใช้พื้นที่อย่างมีประสิทธิภาพ

Block ที่ไม่เปลี่ยนแปลงสามารถใช้อ้างอิงร่วมกันระหว่างข้อมูลปัจจุบันกับหลาย Snapshot ได้ พื้นที่จึงเพิ่มตามข้อมูลที่เปลี่ยน ไม่ใช่ตามขนาดข้อมูลทั้งหมดทุกครั้ง

4. สร้างจุดกู้คืนได้ถี่

Snapshot Replication สามารถตั้ง Schedule ได้ถี่กว่างาน Backup ทั่วไปในหลายกรณี จึงช่วยลดช่วงข้อมูลที่อาจสูญหายระหว่าง Recovery Point

5. ผู้ใช้กู้ไฟล์บางรายการได้สะดวก

เมื่อตั้งค่าให้เหมาะสม ผู้ใช้สามารถเปิด Previous Versions หรือ Browse Snapshot เพื่อคัดลอกไฟล์เก่ากลับมา โดยไม่ต้องให้ผู้ดูแล Restore ชุด Backup ทั้งหมด

Snapshot มีข้อจำกัดและข้อเสียอะไร?

1. Snapshot ที่อยู่ใน NAS เครื่องเดียวกันไม่ป้องกันเหตุเสียหายทั้งเครื่อง

หาก NAS ถูกขโมย เกิดไฟไหม้ Storage Pool เสียหายรุนแรง หรืออุปกรณ์ถูกทำลาย Snapshot ที่อยู่บน Volume เดียวกันอาจสูญหายไปพร้อมข้อมูลหลัก จึงต้องมี Backup ไปยังปลายทางอื่นด้วย

2. Snapshot ไม่ใช่สำเนาข้อมูลอิสระเสมอไป

Local Snapshot ยังพึ่งพา Storage Pool และระบบไฟล์ต้นทาง การมี Snapshot จึงไม่ควรถูกนับเป็นการสำรองนอกอุปกรณ์โดยอัตโนมัติ

3. Workload ที่เปลี่ยนแปลงสูงอาจกินพื้นที่มาก

ฐานข้อมูล, Virtual Machine, Surveillance หรือไฟล์ขนาดใหญ่ที่ถูกเขียนทับบ่อย อาจทำให้ Block เปลี่ยนจำนวนมากและ Snapshot เติบโตเร็ว

4. Retention ที่ยาวเกินไปอาจใช้พื้นที่มาก

การเก็บ Snapshot ถี่และนานโดยไม่ประเมินอัตราการเปลี่ยนแปลงข้อมูล อาจทำให้ Volume เหลือพื้นที่น้อยจนกระทบระบบ

5. Snapshot ปกติอาจถูกผู้มีสิทธิ์สูงลบได้

หากบัญชีผู้ดูแลถูกโจมตี ผู้โจมตีอาจพยายามลบ Snapshot ก่อนเข้ารหัสข้อมูล จึงควรพิจารณา Immutable Snapshot และสำเนา Offsite ที่มี Object Lock เพิ่มเติม

Snapshot ต่างจาก Backup อย่างไร?

หัวข้อ	Snapshot	Backup
วัตถุประสงค์หลัก	ย้อนสถานะข้อมูลอย่างรวดเร็ว	สร้างสำเนาข้อมูลเพื่อกู้คืนเมื่อข้อมูลต้นทางเสียหายหรือสูญหาย
ตำแหน่งจัดเก็บ	Local Snapshot มักอยู่ใน Volume หรือระบบเดียวกับข้อมูลต้นทาง	สามารถเก็บอีก NAS, USB, File Server หรือ Cloud
ความเร็วในการสร้าง	รวดเร็วมาก	ช้ากว่า โดยเฉพาะการสำรองชุดแรก
ความเร็วในการ Restore	รวดเร็ว เหมาะกับไฟล์และ Shared Folder	ขึ้นอยู่กับปลายทาง ปริมาณข้อมูล และรูปแบบ Backup
ป้องกัน NAS เสียทั้งเครื่อง	Local Snapshot เพียงอย่างเดียวไม่เพียงพอ	ทำได้เมื่อเก็บสำเนาไว้อีกอุปกรณ์หรือ Offsite
สำรอง Package และ Configuration	ไม่ใช่หน้าที่หลัก	Hyper Backup รองรับข้อมูล แอปพลิเคชันบางรายการ และการตั้งค่าระบบ

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

Snapshot ต่างจาก RAID อย่างไร?

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

Snapshot ช่วยย้อนสถานะข้อมูล แต่ Local Snapshot ยังอยู่บน Storage Pool เดียวกัน หาก Storage Pool เสียหายเกินความสามารถของ RAID ข้อมูลและ Snapshot อาจสูญหายพร้อมกัน

Backup คือสำเนาที่แยกออกไปยังปลายทางอื่น เพื่อให้ยังมีข้อมูลกู้คืนเมื่อ NAS หรือ Storage Pool ต้นทางไม่สามารถใช้งานได้

RAID       = ลด Downtime จากดิสก์บางลูกเสีย
Snapshot   = ย้อนข้อมูลกลับไปยังจุดเวลาก่อนหน้า
Backup     = มีสำเนาแยกสำหรับกู้คืนเมื่อระบบต้นทางเสียหาย

Snapshot Replication คืออะไร?

Snapshot Replication เป็นแพ็กเกจของ Synology สำหรับสร้างและจัดการ Snapshot ของ Shared Folder และ LUN รวมถึง Replicate Snapshot ไปยัง Synology NAS ปลายทางที่รองรับ

การ Replication ต่างจาก Local Snapshot ตรงที่ข้อมูลถูกส่งไปยังอุปกรณ์อีกเครื่อง หาก NAS ต้นทางมีปัญหา ยังมีสำเนา Snapshot อยู่ที่ปลายทางและสามารถวางแผนการ Recovery, Switchover หรือ Failover ได้

Synology NAS ต้นทาง
Shared Folder + Snapshot
          │
          │ Replication
          ▼
Synology NAS ปลายทาง
Replicated Snapshot

หลังการ Replication ครั้งแรก งานรอบถัดไปจะเน้นส่งข้อมูลที่เปลี่ยนแปลงแทนการส่งข้อมูลทั้งหมดใหม่ทุกครั้ง จึงช่วยลด Bandwidth และเวลาที่ใช้ แต่ยังต้องวางแผน Link, Schedule, Retention และพื้นที่ปลายทางให้เหมาะสม

Immutable Snapshot คืออะไร?

Immutable Snapshot คือ Snapshot ที่ถูกกำหนดให้ไม่สามารถแก้ไขหรือลบได้ภายในช่วงเวลาคุ้มครองที่ตั้งไว้ โดย Synology อธิบายว่าเป็นเทคโนโลยีในลักษณะ WORM: Write Once, Read Many

เมื่อ Snapshot ถูกตั้งเป็น Immutable แม้บัญชีผู้ดูแลจะมีสิทธิ์สูง ก็ไม่ควรสามารถลบ Snapshot นั้นก่อนสิ้นสุด Protection Period ได้ และพื้นที่จัดเก็บที่มี Immutable Snapshot อยู่จะมีข้อจำกัดในการลบเพื่อป้องกันการหลีกเลี่ยงกลไกดังกล่าว

Snapshot ปกติ
ผู้ดูแลระบบ ──► อาจลบได้ตามสิทธิ์

Immutable Snapshot
ผู้ดูแลระบบ ──► ลบไม่ได้จนกว่าจะพ้น Protection Period

คุณสมบัตินี้ช่วยลดความเสี่ยงจากเหตุการณ์ต่อไปนี้

• บัญชี Admin ถูกขโมยและผู้โจมตีพยายามลบจุดกู้คืน
• Ransomware หรือสคริปต์อันตรายพยายามทำลาย Snapshot
• ผู้ดูแลลบ Snapshot หรือ Storage Space โดยไม่ตั้งใจ
• บุคคลภายในพยายามแก้ไขหรือลบหลักฐานข้อมูลย้อนหลัง

การใช้งาน Immutable Snapshot ต้องตรวจสอบเวอร์ชัน DSM และรุ่น Synology NAS ที่รองรับก่อน โดย Synology ระบุว่าใช้กับ DSM 7.2 หรือใหม่กว่าในอุปกรณ์ที่รองรับ และแนะนำ Protection Period ระดับ 7–14 วันเป็นแนวทางเริ่มต้นสำหรับบางกรณี แต่ระยะเวลาจริงควรกำหนดจากความเสี่ยง พื้นที่จัดเก็บ และนโยบายขององค์กร

Immutable Snapshot เหมือน Snapshot ปกติหรือไม่?

กลไกพื้นฐานในการเก็บสถานะ Point-in-Time และการใช้ Block ร่วมกันยังอยู่บนแนวคิดเดียวกัน ความแตกต่างสำคัญคือ ความสามารถในการลบหรือเปลี่ยนแปลงระหว่างช่วงคุ้มครอง

หัวข้อ	Snapshot ปกติ	Immutable Snapshot
ย้อนข้อมูลกลับตามเวลา	ได้	ได้
ใช้ Block-Level และประหยัดพื้นที่	ได้	ได้
ลบก่อนครบ Retention	ผู้มีสิทธิ์อาจลบได้	ลบไม่ได้ภายใน Protection Period
เหมาะกับการป้องกัน Ransomware	ช่วยได้ แต่ยังมีความเสี่ยงจากบัญชี Admin	แข็งแรงกว่าเพราะมีการล็อกการลบ
ข้อจำกัด	บริหารพื้นที่ยืดหยุ่นกว่า	หากตั้งนานเกินไปจะบังคับให้เก็บข้อมูลและใช้พื้นที่จนกว่าจะหมดช่วงคุ้มครอง

ข้อควรระวังก่อนเปิด Immutable Snapshot

Immutable ไม่ได้มีแต่ข้อดี เพราะเมื่อกำหนด Protection Period แล้ว ผู้ดูแลจะไม่สามารถลบ Snapshot เพื่อคืนพื้นที่ก่อนกำหนดได้ แม้พบว่าตั้งค่าผิดหรือพื้นที่ใกล้เต็มก็ตาม

ก่อนเปิดใช้งานควรตรวจสอบอย่างน้อยดังนี้

• ประเมินอัตราการเปลี่ยนแปลงข้อมูลต่อวัน
• กำหนด Protection Period ที่สมดุลระหว่างความปลอดภัยกับพื้นที่
• เผื่อพื้นที่ว่างของ Volume และ Storage Pool
• ตั้ง Alert เมื่อพื้นที่ถึง Threshold ที่กำหนด
• หลีกเลี่ยงการเริ่มด้วย Retention ยาวมากโดยยังไม่มีข้อมูลการใช้งานจริง
• ทดสอบ Restore และขั้นตอนรับมือ Ransomware เป็นระยะ

Immutable Snapshot ส่งขึ้น Wasabi ได้โดยตรงหรือไม่?

ประเด็นนี้ต้องแยกคำว่า Snapshot ออกจาก Backup Object ให้ชัดเจน

Snapshot Replication ไม่ได้ Replicate Snapshot ไปยัง Wasabi โดยตรง เพราะปลายทางของ Snapshot Replication คือ Synology NAS ที่รองรับ ไม่ใช่ Public Cloud Object Storage ทั่วไป

แนวทางที่ถูกต้องคือใช้ Hyper Backup สำรองข้อมูลจาก Synology NAS ไปยัง Wasabi ซึ่งเป็น S3-Compatible Object Storage และหากต้องการให้สำเนาบน Cloud ไม่สามารถถูกแก้ไขหรือลบก่อนครบกำหนด ต้องออกแบบ Bucket และนโยบาย Object Lock / Immutability ให้รองรับตั้งแต่เริ่มต้น

ข้อมูลใช้งานบน Synology NAS
        │
        ├── Local Snapshot
        ├── Immutable Snapshot
        │
        └── Hyper Backup
               │
               ▼
       Wasabi Object Storage
       + Versioning / Object Lock

ดังนั้นคำอธิบายที่แม่นยำคือ

• บน Synology: ใช้ Immutable Snapshot ป้องกันจุดกู้คืนในระดับระบบไฟล์
• บน Wasabi: ใช้ Hyper Backup ส่งชุดสำรองไปยัง S3-Compatible Storage
• ความเป็น Immutable บน Cloud: ใช้ Object Lock หรือ Immutability ของ Bucket ตามรูปแบบที่บริการและแอปพลิเคชันรองรับ

ก่อนใช้งานจริงควรทดสอบร่วมกันทั้งการ Backup, Retention, การลบงาน Backup, การหมดอายุของ Object และการ Restore เพราะการเปิด Object Lock อาจทำให้ข้อมูลไม่สามารถลบก่อนกำหนดและเกิดค่าใช้พื้นที่ต่อเนื่องตามระยะเวลาที่ล็อกไว้

Wasabi Object Lock ต่างจาก Synology Immutable Snapshot อย่างไร?

หัวข้อ	Synology Immutable Snapshot	Wasabi Object Lock
ตำแหน่ง	อยู่บน Synology NAS หรือ Synology ปลายทาง	อยู่บน Cloud Object Storage
ระดับการทำงาน	Snapshot ของ Shared Folder หรือ LUN	Object ภายใน Bucket
เครื่องมือส่งข้อมูล	Snapshot Replication ระหว่าง Synology	Hyper Backup หรือเครื่องมือที่รองรับ S3
การป้องกันสถานที่	หากอยู่ NAS เครื่องเดิม ยังอยู่สถานที่เดิม	เป็น Offsite Cloud Copy
การ Restore	รวดเร็ว เหมาะกับการย้อนข้อมูลระยะสั้น	ขึ้นอยู่กับ Internet, ปริมาณข้อมูล และกระบวนการ Restore

ทั้งสองอย่างจึงไม่ได้ทดแทนกัน แต่เสริมกันในคนละชั้นของระบบป้องกันข้อมูล

หลัก Backup 3-2-1 คืออะไร?

หลัก 3-2-1 เป็นแนวทางจัดเก็บสำเนาข้อมูลเพื่อลด Single Point of Failure ประกอบด้วย

• 3 Copies: มีข้อมูลอย่างน้อย 3 ชุด รวมข้อมูลใช้งานจริง
• 2 Media: เก็บบนสื่อหรือระบบจัดเก็บอย่างน้อย 2 ประเภท
• 1 Offsite: มีอย่างน้อย 1 ชุดอยู่นอกสถานที่หลัก

ตัวอย่างสำหรับ Synology และ Wasabi

สำเนาที่ 1: ข้อมูลใช้งานจริงบน Synology NAS
สำเนาที่ 2: Backup บน Synology NAS อีกเครื่องหรือ External Storage
สำเนาที่ 3: Hyper Backup บน Wasabi

ระบบจัดเก็บอย่างน้อย 2 แบบ:
- NAS / Local Storage
- Cloud Object Storage

Offsite อย่างน้อย 1 ชุด:
- Wasabi

Local Snapshot ช่วยเพิ่มจำนวน Recovery Point และทำให้กู้คืนเร็ว แต่ไม่ควรนับแทน Offsite Backup เพราะยังอาจอยู่บนอุปกรณ์และสถานที่เดียวกับข้อมูลต้นทาง

หลัก Backup 3-2-1-1-0 คืออะไร?

องค์กรที่ต้องรับมือ Ransomware มักขยายหลัก 3-2-1 เป็น 3-2-1-1-0

• 3: มีข้อมูลอย่างน้อย 3 ชุด
• 2: เก็บบนสื่อหรือระบบจัดเก็บอย่างน้อย 2 ประเภท
• 1: มีอย่างน้อย 1 ชุดอยู่นอกสถานที่
• 1: มีอย่างน้อย 1 ชุดเป็น Immutable, Offline หรือ Air-Gapped
• 0: Backup ต้องผ่านการตรวจสอบและทดสอบ Restore โดยไม่มีข้อผิดพลาดที่ยังไม่ได้แก้ไข

ตัวอย่าง Architecture ที่เหมาะสม

ผู้ใช้และ Server
        │
        ▼
Production Synology NAS
        │
        ├── Snapshot ทุก 1 ชั่วโมง
        ├── Immutable Snapshot 7–14 วัน
        │
        ├── Snapshot Replication ไป Synology NAS ปลายทาง
        │
        └── Hyper Backup ไป Wasabi
                     │
                     └── Object Lock ตามนโยบายองค์กร

โครงสร้างนี้มีจุดกู้คืนแบบรวดเร็วใน NAS มีสำเนาแยกบน NAS ปลายทาง และมี Offsite Copy บน Cloud หากระบบภายในทั้งหมดเสียหายพร้อมกัน

Snapshot, Immutable Snapshot, Replication และ Wasabi ควรแบ่งหน้าที่อย่างไร?

ชั้นการป้องกัน	เครื่องมือ	หน้าที่หลัก
ชั้นที่ 1	RAID / SHR	ช่วยให้บริการยังทำงานได้เมื่อดิสก์บางลูกเสีย
ชั้นที่ 2	Snapshot	ย้อนข้อมูลอย่างรวดเร็วเมื่อไฟล์ถูกลบหรือแก้ไข
ชั้นที่ 3	Immutable Snapshot	ป้องกันการลบจุดกู้คืนในช่วง Protection Period
ชั้นที่ 4	Snapshot Replication	ส่ง Snapshot ไปยัง Synology NAS อีกเครื่องเพื่อรองรับ DR
ชั้นที่ 5	Hyper Backup ไป Wasabi	สร้างสำเนา Offsite บน Cloud และเก็บย้อนหลังตามนโยบาย
ชั้นที่ 6	Wasabi Object Lock	ป้องกัน Object Backup ถูกลบหรือแก้ไขก่อนครบกำหนด

ตัวอย่าง Retention Policy สำหรับองค์กร

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

ประเภท	ความถี่ตัวอย่าง	ระยะเวลาเก็บตัวอย่าง	วัตถุประสงค์
Local Snapshot	ทุก 1 ชั่วโมง	48–72 ชั่วโมง	กู้คืนเหตุผิดพลาดล่าสุดอย่างรวดเร็ว
Daily Snapshot	วันละครั้ง	30 วัน	ย้อนข้อมูลรายวัน
Immutable Snapshot	ตามรอบความเสี่ยง	7–14 วัน หรือเป็นไปตามนโยบาย	ป้องกัน Ransomware และการลบโดยผู้มีสิทธิ์สูง
Hyper Backup ไป Wasabi	วันละครั้งหรือถี่กว่านั้น	30–365 วันตามข้อกำหนด	Offsite Backup และ Long-Term Retention

ตัวเลขข้างต้นเป็นเพียงตัวอย่าง องค์กรควรกำหนดจาก RPO, RTO, ปริมาณข้อมูลที่เปลี่ยนต่อวัน, ความเร็ว Internet, งบประมาณ และข้อกำหนดทางกฎหมาย

RPO และ RTO เกี่ยวข้องกับ Snapshot อย่างไร?

RPO หรือ Recovery Point Objective คือปริมาณข้อมูลย้อนหลังสูงสุดที่องค์กรยอมรับว่าสูญหายได้ หากตั้ง Snapshot ทุก 1 ชั่วโมง RPO ในชั้น Snapshot จะอยู่ใกล้เคียง 1 ชั่วโมงในกรณีปกติ

RTO หรือ Recovery Time Objective คือเวลาสูงสุดที่ระบบควรกลับมาใช้งานได้ Snapshot มักมี RTO ต่ำกว่าการ Restore จาก Cloud เพราะข้อมูลอยู่ใกล้และสามารถย้อนสถานะได้รวดเร็ว

แต่หาก NAS เสียทั้งเครื่อง Local Snapshot จะช่วยไม่ได้ ต้องใช้ Replicated Snapshot หรือ Backup จากปลายทางอื่น ซึ่งมี RTO แตกต่างกันตาม Architecture

วิธีประเมินพื้นที่ Snapshot ก่อนใช้งานจริง

ไม่ควรประเมินจากขนาดข้อมูลรวมเพียงอย่างเดียว ควรเก็บข้อมูลต่อไปนี้

1. ขนาด Shared Folder ปัจจุบัน
2. ปริมาณข้อมูลที่เพิ่มใหม่ต่อวัน
3. ปริมาณข้อมูลเดิมที่แก้ไขหรือลบต่อวัน
4. ประเภท Workload เช่น Office File, Database, VM หรือกล้องวงจรปิด
5. ความถี่ Snapshot
6. ระยะเวลา Retention และ Protection Period ของ Immutable Snapshot
7. พื้นที่สำรองสำหรับการเติบโตและเหตุการณ์ผิดปกติ

ตัวอย่าง Shared Folder ขนาด 20 TB แต่มีการเปลี่ยนแปลงเพียงวันละ 100 GB การเก็บ Snapshot รายวัน 14 วันอาจต้องเผื่อพื้นที่ตาม Change Rate ประมาณ 1.4 TB บวก Overhead และ Safety Margin ไม่ใช่ 280 TB แต่หากเป็น VM หรือฐานข้อมูลที่เขียนทับ Block จำนวนมาก Change Rate อาจสูงกว่าที่เห็นจากขนาดไฟล์ใหม่ใน File Station อย่างมาก

Best Practice สำหรับ Synology Snapshot

• ใช้ Btrfs และตรวจสอบว่า NAS รุ่นนั้นรองรับ Snapshot Replication
• แยก Shared Folder ตามความสำคัญและรูปแบบการเปลี่ยนแปลงข้อมูล
• กำหนด Schedule ตาม RPO ไม่ใช่สร้างถี่ที่สุดโดยไม่มีเหตุผล
• ใช้ Retention แบบหมุนเวียน เช่น Hourly, Daily, Weekly และ Monthly ตามความจำเป็น
• เปิด Immutable Snapshot ให้ข้อมูลสำคัญ โดยเริ่มจาก Protection Period ที่บริหารพื้นที่ได้
• ตั้ง Notification และ Threshold ของ Volume/Storage Pool
• ทำ Snapshot Replication ไปยัง Synology NAS อีกเครื่องสำหรับระบบที่ต้องการ DR เร็ว
• ใช้ Hyper Backup สำรองออกไปยัง Wasabi หรือ Cloud Storage อื่นสำหรับ Offsite Copy
• ใช้บัญชีและ Credential แยกสำหรับงาน Backup ลดความเสียหายเมื่อบัญชีหลักถูกโจมตี
• เปิด MFA และจำกัดสิทธิ์ Admin
• ทดสอบ Restore ทั้งไฟล์เดี่ยว Shared Folder และชุด Backup จาก Cloud
• บันทึกผลทดสอบเพื่อให้ส่วน “0 Error” ของแนวทาง 3-2-1-1-0 มีหลักฐานจริง

คำถามที่พบบ่อยเกี่ยวกับ Snapshot

Snapshot ทำให้ไฟล์เพิ่มเป็นสองเท่าหรือไม่?

ไม่จำเป็น Snapshot ไม่ได้ Copy ทุกไฟล์ใหม่ทั้งหมด แต่พื้นที่จะเพิ่มตาม Block เดิมที่ต้องรักษาไว้เมื่อข้อมูลถูกเปลี่ยนหรือลบ

สร้าง Snapshot แล้วถือว่า Backup ครบหรือยัง?

ยังไม่ครบ โดยเฉพาะ Local Snapshot ที่อยู่บน NAS และ Storage Pool เดียวกัน ควรมี Backup ไปยังอีกอุปกรณ์และ Offsite ตามหลัก 3-2-1

ลบ Snapshot แล้วพื้นที่จะคืนทันทีหรือไม่?

ไม่เสมอไป หาก Snapshot อื่นยังอ้างอิง Block ชุดเดียวกัน พื้นที่จะยังไม่ถูกคืนจนกว่าไม่มี Snapshot ใดต้องใช้ Block นั้น

Snapshot ป้องกัน Ransomware ได้หรือไม่?

ช่วยให้ย้อนข้อมูลกลับก่อนถูกเข้ารหัสได้ แต่ Snapshot ปกติอาจถูกลบหากบัญชี Admin ถูกยึด จึงควรใช้ Immutable Snapshot และ Offsite Immutable Backup ร่วมกัน

Immutable Snapshot ลบได้หรือไม่?

ไม่สามารถลบได้ในช่วง Protection Period ที่กำหนด เมื่อพ้นระยะคุ้มครองแล้วจึงบริหารตาม Retention Policy ได้

ส่ง Immutable Snapshot ขึ้น Wasabi ได้เลยหรือไม่?

ไม่ใช่การส่ง Snapshot Replication โดยตรงไป Wasabi แนวทางคือใช้ Hyper Backup สำรองข้อมูลไป Wasabi และใช้ Object Lock ที่ฝั่ง Cloud หากต้องการ Immutability

Snapshot Replication ไป Wasabi ได้หรือไม่?

ไม่ได้โดยตรง Snapshot Replication ใช้สำหรับ Replicate ระหว่าง Synology ที่รองรับ ส่วน Wasabi ใช้ผ่านงาน Backup แบบ S3-Compatible เช่น Hyper Backup

RAID, Snapshot และ Backup ต้องมีครบหรือไม่?

สำหรับข้อมูลสำคัญควรใช้ร่วมกัน เพราะแต่ละเทคโนโลยีแก้ปัญหาคนละประเภท RAID รับมือดิสก์เสีย Snapshot รับมือการเปลี่ยนแปลงข้อมูล และ Backup รับมือเหตุเสียหายของระบบต้นทางหรือสถานที่

สรุป

Snapshot คือเทคโนโลยี Point-in-Time ที่ช่วยให้ Synology NAS จดจำสถานะข้อมูล ณ เวลาหนึ่ง โดยไม่ต้อง Copy ข้อมูลทั้งหมดขึ้นมาใหม่ทุกครั้ง พื้นที่ Snapshot จะเพิ่มตาม Block เดิมที่ถูกแก้ไขหรือลบแต่ยังมี Snapshot อ้างอิงอยู่ จึงเป็นเหตุผลว่าทำไม Snapshot แรกอาจมีขนาด 0 GB และทำไมการลบไฟล์จึงไม่ทำให้พื้นที่ว่างเพิ่มทันที

Snapshot ให้ความเร็วและความสะดวกในการกู้คืน แต่ไม่ควรใช้แทน Backup ทั้งหมด เพราะ Local Snapshot ยังอาจสูญหายพร้อม NAS ต้นทางได้ การป้องกันที่รัดกุมควรใช้หลายชั้น ได้แก่ RAID หรือ SHR สำหรับความต่อเนื่องของบริการ, Snapshot สำหรับ Recovery ที่รวดเร็ว, Immutable Snapshot สำหรับป้องกันการลบ, Snapshot Replication สำหรับสำเนาบน Synology อีกเครื่อง และ Hyper Backup ไป Wasabi สำหรับ Offsite Copy

เมื่อเพิ่ม Wasabi Object Lock หรือกลไก Immutable ที่ปลายทาง พร้อมทดสอบ Restore อย่างสม่ำเสมอ ระบบจะเข้าใกล้แนวทาง 3-2-1-1-0 ซึ่งช่วยลดความเสี่ยงจากดิสก์เสีย ความผิดพลาดของผู้ใช้ Ransomware การโจมตีบัญชี Admin และภัยพิบัติที่กระทบอุปกรณ์ภายในสถานที่เดียวกัน

แหล่งข้อมูลอ้างอิง

• Synology Knowledge Center: Snapshot Replication และ Point-in-Time Snapshot
• Synology Knowledge Center: What is an immutable snapshot? How do I use it?
• Synology: Snapshot Replication Technical Specifications
• Synology: Backup & Data Protection และหลัก 3-2-1 / 3-2-1-1-0
• Wasabi Documentation: Synology Hyper Backup และ Object Lock
• เอกสารประกอบ: Understand How Snapshot Size Is Calculated, Day 1–Day 8

ต้องการปรึกษาผู้เชี่ยวชาญ หรือขอใบเสนอราคา สามารถติดต่อได้ที่
E-Mail: [email protected]
Line@: @sync.co.th

ทางบริษัทฯ ขอสงวนสิทธิ์ในการรับผิดชอบใด ๆ อันเนื่องจากข้อผิดพลาดทางการพิมพ์ (ผิด/ตก)
*** สงวนสิทธิ์ในบทความนี้ โดย บริษัท ซิงค์เทค โซลูชั่น จำกัด ห้ามมิให้คัดลอก ดัดแปลง ทำซ้ำ โดยไม่ได้รับอนุญาตจากทางบริษัทเป็นลายลักษณ์อักษร ***