backup ที่รายงานว่าสำเร็จ 1,769 ไฟล์ แต่ป้องกันอะไรไม่ได้เลย — 3-2-1 ไม่พอแล้ว

วันหนึ่งเราเปิดงานสำรองไฟล์เอกสารภาษีอิเล็กทรอนิกส์บนเครื่องใช้งานจริง

มันคัดลอกไฟล์ที่เซ็นรับรองแล้วครบ 1,769 ไฟล์ รายงานว่า ล้มเหลว 0 เขียวสนิททุกตัวเลข

แล้วเราก็พบว่าปลายทางที่ตั้งไว้เป็นค่าเริ่มต้นอยู่บนดิสก์ก้อนเดียวกับไฟล์ต้นฉบับ

แปลว่าถ้าดิสก์พัง — ซึ่งเป็นเหตุผลข้อแรกที่ backup มีอยู่ — เราจะเสียทั้งต้นฉบับและสำเนาพร้อมกัน

เราไม่ได้เจอตอนมันพัง แต่เจอตอนอ่านโค้ดที่รวมเข้าระบบไปแล้ว

ทำไมเรื่องนี้แย่กว่าไม่มี backup เลย

ระบบที่ไม่มี backup อย่างน้อยทุกคนรู้ว่าไม่มี จึงระวังตัวและไม่ทำอะไรเสี่ยง

ส่วนระบบที่มี backup ซึ่งใช้กู้ไม่ได้จริง ผลิตความมั่นใจปลอม — ไม่มีใครไปตั้งปลายทางจริง เพราะหน้าจอบอกว่าเรียบร้อยแล้ว

เราเรียกรูปแบบนี้ในทีมว่า “เขียวปลอม” และนิยามของมันคือ

ด่านที่ไม่มีข้อมูลให้ตรวจ หน้าตาเหมือนด่านที่ตรวจแล้วสะอาด

ทั้งสองสภาพให้ตัวเลขเดียวกันเป๊ะคือศูนย์ ถ้าดูแค่ตัวเลขจะแยกไม่ออกตลอดกาล

บทความนี้จึงเป็นสองเรื่องพร้อมกัน — รูปแบบ backup ที่ใช้จริงมีอะไรบ้างนอกจาก 3-2-1 และทำไมส่วนที่ยากที่สุดไม่ใช่การสำรอง แต่คือการพิสูจน์ว่าสำรองได้จริง

3-2-1 คืออะไร และทำไมไม่พออีกต่อไป

สูตรคลาสสิกที่ทุกคนรู้จัก

• 3 — เก็บข้อมูลไว้ 3 ชุด (ต้นฉบับ + สำเนา 2)
• 2 — อยู่บนสื่อ 2 ชนิดที่ต่างกัน
• 1 — อย่างน้อย 1 ชุดอยู่คนละสถานที่

สูตรนี้ออกแบบมาในยุคที่ศัตรูคือฮาร์ดแวร์พังและไฟไหม้ ซึ่งมันกันได้ดีมาก

ปัญหาคือศัตรูเปลี่ยนไปแล้ว — มัลแวร์เรียกค่าไถ่สมัยนี้ไล่เข้ารหัส backup ก่อนเสมอ เพราะรู้ว่าถ้าเหยื่อกู้ได้ก็ไม่จ่าย

สำเนา 3 ชุดที่เครื่องเข้าถึงได้ทั้งหมด จึงถูกทำลายพร้อมกันได้ในคำสั่งเดียว

3-2-1-1-0 — สูตรที่ใช้กันตอนนี้

ต่อยอดจากเดิมด้วยสองตัวเลขที่แก้ช่องโหว่คนละแบบ

1 เพิ่ม — สำเนาที่แก้ไขหรือลบไม่ได้

ต้องมีอย่างน้อยหนึ่งชุดที่ตัดขาดจากระบบ หรือล็อกไว้จนแก้ไม่ได้

หัวใจอยู่ที่ว่า — ถ้าผู้บุกรุกได้สิทธิ์ผู้ดูแลระบบสูงสุดไปแล้ว เขาจะลบสำเนาชุดนี้ได้หรือไม่

ถ้าคำตอบคือได้ แปลว่ายังไม่มีชุดนี้ — และสิทธิ์ผู้ดูแลระบบคือสิ่งที่ผู้โจมตีหาก่อนเป็นอันดับแรกเสมอ

0 เพิ่ม — การกู้คืนต้องผ่านโดยไม่มีข้อผิดพลาด

backup ที่ไม่เคยลองกู้ ยังไม่นับว่ามี

ข้อนี้ฟังดูเป็นคำคม แต่มีเหตุผลทางเทคนิคชัดเจน — ความล้มเหลวส่วนใหญ่ของการกู้คืนไม่ได้อยู่ที่ “ไม่มีไฟล์” แต่อยู่ที่ไฟล์มีอยู่แต่ใช้ไม่ได้

คัดลอกไม่ครบ · เปิดไม่ออก · รหัสยืนยันความถูกต้องเพี้ยน · กุญแจถอดรหัสหาย · โครงสร้างฐานข้อมูลไม่ตรงกับที่โปรแกรมปัจจุบันคาดหวัง

ทั้งหมดนี้ผ่านการตรวจแบบ “มีไฟล์ใหม่วันนี้ไหม” ได้หมด

4-3-2

เข้มกว่าอีกขั้น — 4 สำเนา · 3 สถานที่ · 2 ในนั้นอยู่นอกองค์กร

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

แกนที่สอง — จะเก็บย้อนหลังนานแค่ไหน

สามสูตรข้างบนตอบว่า “มีกี่ชุด” แต่ไม่ได้ตอบว่า “ย้อนกลับไปได้ถึงเมื่อไร” ซึ่งเป็นคนละคำถาม

GFS — ปู่ พ่อ ลูก

วิธีหมุนสำเนาที่ใช้กันมากที่สุด

ชั้น	รอบ	เก็บไว้
ลูก	รายวัน	ราว 1-2 สัปดาห์
พ่อ	รายสัปดาห์	ราว 1-2 เดือน
ปู่	รายเดือนหรือรายปี	หลายปี

ประโยชน์คือย้อนกลับได้ทั้ง “เมื่อวาน” และ “สามเดือนก่อน” โดยไม่ต้องเก็บทุกวันไว้ตลอดกาล

สำหรับธุรกิจไทย เรื่องนี้ไม่ใช่แค่เรื่องเทคนิค — เอกสารทางบัญชีและภาษีมีข้อกำหนดให้เก็บหลายปี ถ้าเก็บ backup แค่ 30 วัน แล้ววันหนึ่งต้องย้อนไปดูข้อมูลของปีก่อน จะไม่มีอะไรให้ย้อน

ข้อควรระวังของ GFS คือชั้นปู่มักถูกลืม — คนตั้งค่ารายวันกับรายสัปดาห์เรียบร้อย แล้วลืมว่าชั้นที่ต้องอยู่หลายปีต้องแยกที่เก็บและแยกงบ

Tower of Hanoi

วิธีหมุนสำเนาที่ให้ความละเอียดย้อนหลังดีกว่าด้วยจำนวนสื่อเท่ากัน แต่ตารางการหมุนซับซ้อนจนคนทำตามผิดบ่อย

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

แกนที่สาม — ถ่ายข้อมูลด้วยวิธีไหน

วิธี	เก็บอะไร	ข้อแลกเปลี่ยน
Full	ทั้งหมดทุกครั้ง	กู้ง่ายที่สุด แต่กินพื้นที่และเวลามากที่สุด
Incremental	เฉพาะที่เปลี่ยนจากครั้งก่อน	ประหยัดสุด แต่กู้ต้องไล่ทั้งห่วงโซ่ — ขาดกลางห่วงโซ่หนึ่งจุด กู้ไม่ได้ทั้งสาย
Differential	ที่เปลี่ยนจาก full ครั้งล่าสุด	กู้ใช้แค่สองชิ้น ปลอดภัยกว่า แต่โตขึ้นเรื่อย ๆ
Synthetic full	ประกอบ full ใหม่จาก incremental ที่ปลายทาง	ได้ความง่ายของ full โดยไม่ต้องอ่านต้นทางซ้ำ

สำหรับฐานข้อมูล — PITR

ฐานข้อมูลต่างจากไฟล์ทั่วไป เพราะมันเปลี่ยนตลอดเวลา

การสำรองด้วยการดัมป์ข้อมูลออกมาวันละครั้ง แปลว่าถ้าพลาดตอนบ่าย จะเสียงานทั้งวัน

PostgreSQL มีวิธีที่ดีกว่า — เก็บบันทึกการเปลี่ยนแปลงทุกครั้งต่อเนื่อง แล้วเวลากู้ ให้เอาสำเนาเต็มชุดล่าสุดมาเดินบันทึกต่อจนถึงจุดเวลาที่ต้องการ

ผลคือย้อนกลับไปที่ “หนึ่งนาทีก่อนที่จะพลาด” ได้ ไม่ใช่แค่ “เมื่อคืน”

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

Snapshot ไม่ใช่ backup

ระบบไฟล์และอุปกรณ์จัดเก็บสมัยใหม่ถ่าย snapshot ได้เร็วมากจนถ่ายทุกชั่วโมงได้

แต่ snapshot อยู่บนอุปกรณ์เดียวกับข้อมูลจริง — อุปกรณ์พัง หายทั้งคู่ · ถูกเข้ารหัสเรียกค่าไถ่ อาจถูกลบทิ้งพร้อมกัน

มันคือเครื่องมือย้อนกลับที่ยอดเยี่ยม แต่ยังไม่นับเป็น backup จนกว่าจะถูกส่งออกไปที่อื่น

แกนที่สี่ — ป้องกันตัว backup เอง

Immutable / Object Lock / WORM

เก็บสำเนาบนที่เก็บข้อมูลที่ตั้งล็อกตามระยะเวลาได้ — เขียนได้ครั้งเดียว หลังจากนั้นแก้ไม่ได้ ลบไม่ได้ จนกว่าจะครบกำหนด

จุดสำคัญคือแม้แต่บัญชีผู้ดูแลสูงสุดก็ลบไม่ได้ ซึ่งเป็นเหตุผลทั้งหมดที่มันมีอยู่

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

Air gap จริง

ถอดสายออกจริง — เทปหรือฮาร์ดดิสก์ที่เก็บในตู้

กันได้ทุกอย่างรวมถึงกรณีที่รหัสผ่านผู้ดูแลระบบหลุด แต่แลกด้วยแรงคนและความช้าตอนต้องกู้จริง

เหมาะกับชั้นปู่ของ GFS มากกว่าชั้นรายวัน

บทเรียนจากระบบของเรา — เขียวปลอมสามรอบ

ส่วนนี้คือเหตุผลที่เราคิดว่าเลข 0 ในสูตรสำคัญที่สุด

เราเจอรูปแบบเดียวกันซ้ำสามครั้งในงานเดียวกัน ต่างที่กันคนละจุด

ครั้งที่ 1 — สำเนาอยู่ดิสก์เดียวกับต้นฉบับ

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

คัดลอกสำเร็จทุกไฟล์ = ล้มเหลวศูนย์ = เขียว

ครั้งที่ 2 — ตรวจแล้วแต่ไม่เคยเปิดไฟล์

เรามีงานตรวจสอบ backup อยู่แล้ว แต่มันเช็คแค่ว่ามีไฟล์ใหม่เกิดขึ้นใน 24 ชั่วโมงหรือไม่

ซึ่งตอบได้แค่เรื่องเดียว — สคริปต์สำรองข้อมูลยังรันอยู่

ไฟล์ที่คัดลอกไม่ครบ เปิดไม่ออก หรือเสียหาย ผ่านด่านนี้ได้หมด เพราะด่านนี้ไม่เคยลองเปิดไฟล์เลย

ครั้งที่ 3 — ยังไม่เคยสำรองเลยสักไฟล์

ตอนที่เราทำงานซ้อมกู้คืนเสร็จ พบว่าตัวงานสำรองข้อมูลยังตั้งค่าเริ่มต้นเป็นปิดอยู่ เครื่องจริงจึงไม่เคยสำรองอะไรเลย

รายการไฟล์จึงว่างเปล่า และงานซ้อมกู้คืนรายงานว่า “ผ่าน 0 ไฟล์”

ซึ่งให้ตัวเลขเดียวกับ “กู้ครบทุกไฟล์ ไม่มีไฟล์ไหนเพี้ยน” เป๊ะ

สิ่งที่เราเปลี่ยนเพื่อไม่ให้เกิดอีก

1. สถานะต้องบอกเฉพาะสิ่งที่พิสูจน์ได้

ตอนเขียนตัวตรวจปลายทาง เราอยากมีสถานะชื่อ “อยู่นอกสถานที่” เพราะเป็นสิ่งที่อยากรู้จริง ๆ

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

ถ้าเราตั้งชื่อสถานะว่า “อยู่นอกสถานที่” ทั้งที่พิสูจน์ไม่ได้ เราก็กำลังสร้างเขียวปลอมอีกอัน — ซึ่งเป็นปัญหาเดียวกับที่ตัวตรวจนี้เกิดมาเพื่อแก้

ชื่อสถานะจึงบอกเฉพาะสิ่งที่พิสูจน์ได้จริง — อยู่ดิสก์เดียวกับต้นฉบับ · อยู่คนละดิสก์ · เป็นเส้นทางบนเครือข่าย

2. ธงรับทราบต้องปิดเสียงสิ่งที่พิสูจน์แล้วว่าแย่ไม่ได้

เรามีธงให้เจ้าของระบบกดรับทราบเพื่อปิดการเตือน ซึ่งจำเป็นเพราะไม่งั้นคนจะเมินการเตือนทั้งหมด

แต่ธงนี้ปิดได้เฉพาะกรณีที่เราตรวจไม่ได้จริง ๆ เช่นกรณี “คนละดิสก์” ที่เราไม่รู้ว่านอกสถานที่หรือเปล่า

ส่วนกรณี “ดิสก์เดียวกับต้นฉบับ” ปิดเสียงไม่ได้ เพราะเราพิสูจน์แล้วว่าสำเนานั้นไม่รอด

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

3. แยก “ไม่มีปัญหา” ออกจาก “ไม่เคยตรวจ”

นี่คือการแก้ที่รากของทั้งสามครั้ง

เราทำให้สถานะ “ยังไม่เคยสำรองเลย” เป็นสถานะของตัวเอง และมันบล็อกไม่ให้ระบบอ้างได้ว่าพิสูจน์การกู้คืนแล้ว

หลักการที่ใช้ทั้งระบบคือ — ตรวจแล้วไม่เจออะไร = เงียบได้ · แต่ยังไม่เคยตรวจ หรือถูกปิดไว้ = ต้องส่งเสียง

สองสภาพนี้ให้เลขศูนย์เหมือนกัน แต่ความหมายตรงข้ามกันโดยสิ้นเชิง

4. ซ้อมกู้คืนจริงเป็นรอบ

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

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

ถ้าเผลอส่งที่อยู่จริงเข้าไป งานซ้อมจะเอาสำเนาทับต้นฉบับ ซึ่งคือความเสียหายที่ backup มีไว้ป้องกันตั้งแต่แรก

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

5. รายงานต้องบอกขอบเขตของสิ่งที่พิสูจน์ได้

การกู้คืนสำเร็จจากสำเนาที่อยู่ดิสก์เดียวกับต้นฉบับ พิสูจน์ได้แค่ว่าไฟล์ไม่เสีย ไม่ได้พิสูจน์ว่ากู้ได้ตอนดิสก์พัง

รายงานจึงต้องบอกให้ชัดว่าที่ผ่านนั้นผ่านในขอบเขตไหน ไม่ใช่ขึ้นคำว่า “ผ่าน” ลอย ๆ

วิธีตรวจสอบว่าอันไหนที่ทีมเราทำจริง

เวลาเพิ่มด่านตรวจใหม่ เราใช้วิธีที่เรียกกันในทีมว่าพิสูจน์ด้วยสีแดง

คือหลังเขียนด่านเสร็จ ให้ถอดเงื่อนไขนั้นออกชั่วคราว แล้วดูว่าชุดทดสอบแดงกี่เคส

• ถ้าแดงตรงเคสที่ตั้งใจพอดี แปลว่าด่านนี้ทำงานจริง
• ถ้าไม่แดงเลย แปลว่าเพิ่งเขียนด่านที่ไม่ได้ตรวจอะไร — ซึ่งคือเขียวปลอมอีกอันหนึ่ง

ฟังดูเป็นขั้นตอนเล็ก ๆ แต่มันคือความต่างระหว่าง “มีเทสต์” กับ “มีเทสต์ที่จับอะไรได้จริง”

เช็กลิสต์สำหรับตรวจ backup ของคุณเอง

1. สำเนาอยู่คนละอุปกรณ์กับต้นฉบับจริงหรือไม่ — ตรวจเส้นทางจริง ไม่ใช่เชื่อชื่อโฟลเดอร์ที่มีคำว่า backup
2. ถ้าบัญชีผู้ดูแลระบบหลุด สำเนาชุดไหนที่ยังลบไม่ได้ — ถ้าตอบไม่ได้ แปลว่าไม่มี
3. เคยกู้จริงครั้งล่าสุดเมื่อไร — ถ้าคำตอบคือ “ยังไม่เคย” ก็ยังไม่นับว่ามี backup
4. ย้อนกลับได้ถึงเมื่อไร — และตรงกับระยะเวลาที่กฎหมายบังคับให้เก็บเอกสารหรือไม่
5. ถ้าลบข้อมูลผิดตอนบ่าย จะเสียงานกี่ชั่วโมง — คำตอบคือระยะห่างของรอบสำรอง ไม่ใช่ศูนย์
6. การแจ้งเตือนแยก “ไม่มีปัญหา” ออกจาก “ไม่เคยตรวจ” หรือยัง
7. ใครได้รับการแจ้งเตือน และเขาเปิดอ่านจริงไหม

ตัวอย่างเล็ก ๆ ที่เจอระหว่างเขียนบทความนี้

ระบบ deploy เว็บที่คุณกำลังอ่านอยู่นี้ สำรองไฟล์ธีมเดิมไว้ก่อนทับทุกครั้ง ซึ่งเป็นนิสัยที่ดี

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

แปลว่ามันกันได้แค่ “deploy แล้วพังทันทีในรอบเดียวกัน” ซึ่งก็มีประโยชน์จริง แต่ไม่ใช่ backup และถ้าไม่พูดให้ชัดก็จะมีคนเข้าใจว่ามี

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

สรุป

1. 3-2-1 ยังถูกอยู่ แต่ไม่พอ — เพราะออกแบบมากันฮาร์ดแวร์พัง ไม่ได้กันคนที่ตั้งใจลบ backup ของคุณ
2. เติม 1 = สำเนาที่แม้แต่ผู้ดูแลระบบก็ลบไม่ได้
3. เติม 0 = ต้องเคยกู้จริงและผ่าน — และนี่คือข้อที่คนข้ามมากที่สุด
4. GFS ตอบคำถามคนละข้อ คือย้อนได้ถึงเมื่อไร ซึ่งผูกกับข้อกำหนดทางกฎหมายโดยตรง
5. Snapshot ไม่ใช่ backup จนกว่าจะออกจากเครื่อง
6. สำหรับฐานข้อมูล การเก็บบันทึกการเปลี่ยนแปลงต่อเนื่องคุ้มกว่าดัมป์รายวันมาก เพราะความผิดพลาดที่พบบ่อยสุดคือคนสั่งผิด ไม่ใช่ดิสก์พัง
7. สิ่งที่ต้องระวังที่สุดคือหน้าจอสีเขียว — ถามเสมอว่าเขียวเพราะตรวจแล้วสะอาด หรือเขียวเพราะไม่มีอะไรให้ตรวจ

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