ทำไมงานกู้คืนระบบจึงเริ่มที่ “การรู้จักระบบ” ไม่ใช่ที่เครื่องมือ
ในงานด้านโครงสร้างพื้นฐาน เราเห็นองค์กรลงทุนกับระบบสำรองข้อมูลกันอย่างจริงจัง แต่เมื่อเกิดเหตุจริง กลับพบว่าข้อมูลที่สำรองไว้ “เปิดได้แต่ใช้งานไม่ได้” หรือกู้คืนแล้วระบบไม่ยอมบูต สาเหตุส่วนใหญ่ไม่ได้อยู่ที่ตัวเครื่องมือ แต่อยู่ที่สมมติฐานของผู้วางระบบต่อคำถามพื้นฐานข้อเดียวว่า ระบบที่เราจะป้องกันนั้น เก็บสถานะของมันไว้ที่ใดบ้าง และสถานะใดคือสิ่งที่ทำให้ระบบกลับมามีชีวิตได้จริง
บทความชุดนี้แบ่งออกเป็น 4 ตอน ตอนที่ 1 จะปูพื้นฐานว่าสถานะของระบบกระจายอยู่ที่ใดในโครงสร้างไฟล์ซิสเต็ม ต่างกันอย่างไรระหว่างพื้นที่ของผู้ใช้และพื้นที่ของระบบ เกี่ยวข้องกับเคอร์เนลอย่างไร จุดอ่อนตรงรอยต่อระหว่างฮาร์ดแวร์กับเคอร์เนลคืออะไร และแอปพลิเคชันผูกพันกับระบบปฏิบัติการมากเพียงใด เพราะทั้งสี่เรื่องนี้เป็นตัวกำหนดว่าแผนสำรองและกู้คืนที่เราจะออกแบบในตอนต่อไป ต้องเก็บอะไร เก็บอย่างไร และตรวจสอบความถูกต้องได้จริงหรือไม่
1. โครงสร้างไฟล์ซิสเต็ม: ที่อยู่ของสถานะที่ต้องกู้
สิ่งที่ต้องทำความเข้าใจก่อนคือไฟล์ซิสเต็มไม่ได้เป็นเพียงที่เก็บไฟล์ แต่เป็นโครงสร้างข้อมูลที่มีเมทาดาทาและกลไกความสอดคล้องของตัวเอง การสำรองข้อมูลแบบคัดลอกไฟล์ (file-level copy) จะได้ผลก็ต่อเมื่อเราเข้าใจว่าเมทาดาทาส่วนใดถูกใช้ตัดสินความถูกต้องของระบบ
ฝั่ง Windows (NTFS)
- $MFT (Master File Table) เก็บระเบียนของทุกไฟล์และไดเรกทอรี รวมถึงที่อยู่ของข้อมูลจริง การกู้คืนระดับ sector จึงต้องกู้ทั้งตารางนี้ให้สอดคล้องกัน
- $LogFile เป็นเจอร์นัลที่ทำให้การเปลี่ยนแปลงเมทาดาทาเป็นแบบ all-or-nothing และ USN Journal เก็บประวัติการเปลี่ยนแปลงซึ่งระบบสำรองบางตัวใช้ตรวจว่ามีการเขียนเกิดขึ้นระหว่างสำเนา
- Alternate Data Stream และ ACL/SID เป็นข้อมูลที่เครื่องมือคัดลอกทั่วไปมักไม่พาไปด้วย ทำให้ไฟล์กู้คืนมีสิทธิ์ไม่ตรงกับต้นฉบับ
- System Volume Information เก็บ Volume Shadow Copy ซึ่งเป็นจุดอ้างอิงสำคัญเวลาต้องการสำเนาที่สอดคล้อง ณ จุดเวลาเดียวกัน
- WinSxS เป็นคลังคอมโพเนนต์ของ Windows ที่ผูกกับตัวระบบเอง การกู้คืนแบบ image-level จึงต่างจากการคัดลอกโฟลเดอร์ระบบแบบ file-level อย่างมีนัยสำคัญ
ฝั่ง Linux
- ระบบไฟล์ตระกูล ext4 มี superblock และ inode table พร้อมเจอร์นัล (โดยทั่วไปใช้โหมดที่ journal เฉพาะเมทาดาทา) ส่วน XFS ใช้ log สำหรับเมทาดาทาและมีพฤติกรรมหลังเหตุขัดข้องที่ต่างกัน
- /proc, /sys, /dev เป็นระบบไฟล์เสมือนที่สร้างขึ้นใหม่ทุกครั้งที่บูต จึงไม่ใช่สิ่งที่ต้องสำรอง แต่เป็นสิ่งที่ต้องสร้างใหม่ให้ถูกต้อง ซึ่งหมายถึงคอนฟิกที่กำกับมัน เช่น fstab และกฎของอุปกรณ์
- LVM metadata เก็บแผนที่ของ physical volume และ logical volume ถ้าสูญเสียส่วนนี้ ข้อมูลที่ยังอยู่ครบก็เปิดไม่ได้
- ระบบไฟล์แบบ copy-on-write อย่าง Btrfs หรือ ZFS ให้ snapshot ได้เกือบจะในทันที แต่ snapshot ไม่ใช่สำเนาที่ปลอดภัยจากความเสียหายของอุปกรณ์ชุดเดียวกัน
ประเด็นที่ต้องจำคือ การคัดลอกไฟล์ขณะระบบยังทำงานอยู่จะได้ชุดข้อมูลที่ “แต่ละไฟล์ถูกต้อง” แต่ “ทั้งชุดไม่สอดคล้องกัน” เพราะไม่มีกลไกใดรับประกันว่าไฟล์ที่อ่านต้นทางกับปลายทางอยู่ในจุดเวลาเดียวกัน
2. พื้นที่ของผู้ใช้กับพื้นที่ของระบบ: ขอบเขตที่ต้องแยกให้ชัด
การออกแบบแผนสำรองที่ใช้ได้จริงต้องแยก “สถานะที่ทำให้ระบบบูตได้” ออกจาก “สถานะที่ทำให้ระบบใช้งานได้” เพราะสองส่วนนี้มีวิธีป้องกันและวิธีทดสอบต่างกัน
- ฝั่ง Windows พื้นที่ระบบหมายถึงไดเรกทอรีระบบ โฟลเดอร์โปรแกรม โฟลเดอร์ข้อมูลโปรแกรม และรีจิสทรีส่วนเครื่อง (HKLM) ส่วนพื้นที่ผู้ใช้คือโปรไฟล์และรีจิสทรีส่วนผู้ใช้ (HKCU) ซึ่งมักเป็นที่เก็บคอนฟิกของแอปพลิเคชันและข้อมูลที่ผู้ใช้ถือว่า “ของฉัน”
- ฝั่ง Linux คอนฟิกอยู่ที่ /etc ข้อมูลที่เปลี่ยนแปลงตลอดเวลาอยู่ที่ /var โปรแกรมที่ติดตั้งเพิ่มเติมอยู่นอกตัวจัดการแพ็กเกจที่ /opt หรือ /usr/local ส่วนข้อมูลของผู้ใช้อยู่ที่ /home
- โมเดลสิทธิ์ ต่างกันโดยพื้นฐาน Windows ใช้ ACL ที่อ้าง SID ของผู้ใช้และกลุ่ม Linux ใช้สิทธิ์แบบ POSIX ร่วมกับ ACL และฉลากความมั่นคงของ SELinux หรือ AppArmor การกู้คืนที่สิทธิ์หรือฉลากเพี้ยน จะทำให้บริการไม่ยอมเริ่มทำงาน แม้ไฟล์จะอยู่ครบ
สถานะที่องค์กรมักลืมสำรอง ได้แก่ คอนฟิกใน /etc หรือรีจิสทรี ไฟล์ใบรับรองและกุญแจเข้ารหัส ตารางเวลาของ cron และ systemd timer บัญชีผู้ใช้และกลุ่ม นโยบายของโดเมน ข้อมูลลิขสิทธิ์ที่ผูกกับฮาร์ดแวร์ และใบอนุญาตของซอฟต์แวร์ เหล่านี้ล้วนเป็นสิ่งที่กู้คืนจากข้อมูลอย่างเดียวไม่ได้
3. เคอร์เนลกับไฟล์ที่เกี่ยวข้อง: จุดที่กำหนดว่าระบบ “บูตได้หรือไม่”
ลำดับการบูตเป็นห่วงโซ่ที่ผู้ปฏิบัติงานด้านสำรองข้อมูลควรรู้สึกคุ้นเคย เพราะการกู้คืนที่ล้มเหลวมักพังที่ห่วงใดห่วงหนึ่งต่อไปนี้
เฟิร์มแวร์ (UEFI หรือ BIOS) ส่งต่อไปยังบูตโหลดเดอร์ (GRUB2 หรือ Windows Boot Manager พร้อม BCD) ซึ่งโหลดเคอร์เนลและ initramfs เข้าสู่หน่วยความจำ จากนั้นเคอร์เนลจึงเมานต์ระบบไฟล์รากและส่งต่อให้ init ของระบบ (เช่น systemd) เริ่มบริการจนถึงขั้นตอนล็อกอิน
- ไฟล์ที่ขาดไม่ได้คือตัวเคอร์เนลใน /boot, initramfs ที่บรรจุดรายเวอร์ที่จำเป็นต่อการเมานต์ระบบไฟล์ราก, fstab, โมดูลเคอร์เนล, BCD, พาร์ทิชัน EFI และฐานข้อมูลของ Secure Boot รวมถึงกุญแจกู้คืนของการเข้ารหัสดิสก์
- การกู้คืนไฟล์ระบบจากเครื่องอื่น หรือจากเคอร์เนลต่างรุ่น มักจบด้วยการบูตไม่ขึ้น หรือเกิดข้อความว่าเมานต์ระบบไฟล์รากไม่ได้ เพราะ initramfs ไม่มีดรายเวอร์ของตัวควบคุมดิสก์รุ่นที่ติดตั้งอยู่จริง
- เมื่อเคอร์เนลหยุดทำงาน ข้อมูลที่เหลืออยู่เพื่อการวิเคราะห์คือข้อมูลหน่วยความจำขณะเกิดเหตุและบันทึกของเคอร์เนล ซึ่งมีข้อมูลอ่อนไหวปนอยู่ จึงต้องกำหนดสิทธิ์การเข้าถึงและการเก็บรักษาอย่างเข้มงวด
4. จุดอ่อนตรงรอยต่อระหว่างฮาร์ดแวร์กับเคอร์เนล
นี่คือพื้นที่ที่ความผิดพลาดเงียบที่สุด และเป็นเหตุผลว่าทำไม “สำรองสำเร็จ” ไม่เท่ากับ “กู้คืนได้”
- ข้อมูลเสียหายแบบเงียบ: สื่อบันทึก สายสัญญาณ หรือตัวควบคุมอาจคืนค่าที่ผิดโดยไม่แจ้งข้อผิดพลาด ระบบที่ไม่มี checksum ตั้งแต่ต้นทางถึงปลายทางจึงไม่มีทางรู้ หน่วยความจำที่ไม่มีกลไกแก้ไขข้อผิดพลาดก็ทำให้ข้อมูลที่กำลังจะถูกสำรองเพี้ยนได้ก่อนถึงปลายทาง
- แคชเขียนและลำดับการบันทึก: ดิสก์ ตัวควบคุม RAID และ SSD มีแคชที่ยอมรับว่าเขียนสำเร็จก่อนข้อมูลลงถึงสื่อจริง หากกระบวนการสำรองไม่ให้ความสำคัญกับการบังคับบันทึกลงสื่อและการจัดลำดับการเขียน ไฟล์สำเนาอาจดูสมบูรณ์แต่ไม่ตรงกับสิ่งที่ระบบยืนยันกับแอปพลิเคชันไปแล้ว
- ราคาของ RAID แบบ parity: ระหว่างการสร้างข้อมูลคืนบนอาเรย์ขนาดใหญ่ ระบบต้องอ่านทุกภาคส่วน ซึ่งเพิ่มโอกาสเจอภาคส่วนที่อ่านไม่ได้จริง จนกู้คืนล้มเหลวกลางทาง การตรวจสอบสื่อเชิงรับด้วยการอ่านทดสอบและเฝ้าดูสัญญาณสุขภาพของดิสก์จึงเป็นงานประจำที่ไม่ควรมองข้าม
- ชื่ออุปกรณ์ไม่คงที่: การอ้างอิงอุปกรณ์ด้วยชื่อที่ระบบกำหนดตามลำดับการตรวจพบ ทำให้หลังเปลี่ยนฮาร์ดแวร์หรือย้ายพอร์ต ระบบอาจไม่ยอมบูต การอ้างด้วยตัวระบุถาวรจึงเป็นแนวปฏิบัติพื้นฐาน
- เฟิร์มแวร์และไดรเวอร์: ข้อบกพร่องในไดรเวอร์อาจทำให้เกิดข้อผิดพลาดระดับ I/O ที่ระบบไฟล์ตีความเป็นความเสียหายของอุปกรณ์ และนำไปสู่การตัดอุปกรณ์ออกจากระบบโดยไม่จำเป็น
5. ความสัมพันธ์ระหว่างแอปพลิเคชันกับระบบปฏิบัติการ
ข้อมูลของแอปพลิเคชันไม่ได้อยู่ที่ไฟล์เพียงจุดเดียว แต่กระจายเป็นชั้น ตั้งแต่บัฟเฟอร์ในหน่วยความจำของโปรเซส ไปยังบันทึกธุรกรรมของฐานข้อมูล ไฟล์ข้อมูลหลัก ลงสู่แคชของระบบปฏิบัติการ แล้วจึงถึงสื่อบันทึก การสำรองที่อ่านไฟล์ดิบโดยไม่หยุดหรือประสานกับแอปพลิเคชัน จะได้ภาพที่ “อาจต้องซ่อม” หรือในกรณีที่เลวร้ายกว่านั้นคือได้ชุดไฟล์ที่ไม่ครบชุดการทำงาน
- การสร้างจุดที่สอดคล้องกัน: ฝั่ง Windows ใช้กลไก shadow copy ที่ประสานกับตัวเขียนข้อมูลของแอปพลิเคชัน ฝั่ง Linux ใช้การหยุดเขียนชั่วคราวในระดับระบบไฟล์ หรือใช้เครื่องมือสำรองเฉพาะของฐานข้อมูลนั้น ฝั่งเครื่องเสมือนใช้กลไกประสานผ่าน Guest Agent ก่อนสร้าง snapshot
- การพึ่งพาระบบปฏิบัติการ: แอปพลิเคชันผูกกับรุ่นของไลบรารีระบบ ไดรเวอร์ที่ทำงานกับเคอร์เนลรุ่นที่ติดตั้ง ไฟล์กำหนดบริการของระบบ การผูกใบอนุญาตกับฮาร์ดแวร์ และเวลาของระบบที่ต้องตรงกันสำหรับการยืนยันตัวตน
- ตัวชี้วัดของแอปพลิเคชันกับของระบบไม่เท่ากัน: ระยะข้อมูลที่ยอมรับการสูญหายและระยะเวลาที่ระบบกลับมาใช้งานได้ของระบบปฏิบัติการ ไม่ใช่ค่าเดียวกับของแอปพลิเคชัน การออกแบบจึงต้องยึดค่าที่เข้มงวดกว่าของแต่ละชั้น
สรุปตอนที่ 1: รายการตรวจก่อนออกแบบแผนสำรอง
- ระบุให้ครบว่าสถานะของระบบอยู่ที่ใด ทั้งเมทาดาทาของระบบไฟล์ สิทธิ์ คอนฟิก รีจิสทรี และข้อมูลของแอปพลิเคชัน
- แยกให้ชัดระหว่างสถานะที่ทำให้บูตได้กับสถานะที่ทำให้ใช้งานได้ และทดสอบกู้คืนทั้งสองส่วนแยกกัน
- บันทึกห่วงโซ่การบูตให้ครบ รวมถึง initramfs และไดรเวอร์ของตัวควบคุมดิสก์ที่ใช้จริง
- ยอมรับว่าฮาร์ดแวร์ผิดพลาดได้ และกำหนดวิธีตรวจจับความเสียหายที่ปลายทาง ไม่ใช่ตรวจเฉพาะว่ากระบวนการสำรองจบโดยไม่มีข้อผิดพลาด
- กำหนดจุดที่สอดคล้องกันของแอปพลิเคชันให้ชัด และบันทึกวิธีทดสอบว่ากู้คืนแล้วระบบใช้งานได้จริง
ตอนที่ 2 จะพาไปดูปลายทางของการกู้คืน ได้แก่ องค์ประกอบของหน่วยประมวลผลแบบเครื่องเสมือน คอนเทนเนอร์ และบริการแบบไม่ต้องดูแลเซิร์ฟเวอร์ เปรียบเทียบกับเครื่องแม่ข่ายจริง ทั้งในสถาปัตยกรรม x86 และ Arm รวมถึงการจัดเก็บข้อมูลและโครงข่ายที่การกู้คืนต้องพึ่งพา
คำถามที่พบบ่อยในตอนนี้
ถาม: snapshot ของระบบไฟล์ใช้แทนการสำรองข้อมูลได้หรือไม่
ตอบ: ใช้แทนไม่ได้ เพราะ snapshot อยู่บนอุปกรณ์ชุดเดียวกับข้อมูลจริง หากอุปกรณ์เสียหายหรือระบบไฟล์เสียหายจากกัน snapshot ก็เสียหายด้วย การใช้ snapshot ที่ถูกต้องคือใช้เป็นจุดอ้างอิงเวลาสำหรับสร้างสำเนาไปยังอุปกรณ์หรือสถานที่อื่น
ถาม: ทำไมสำรองข้อมูลแบบคัดลอกไฟล์จึงกู้คืนระบบที่บูตไม่ขึ้นไม่ได้
ตอบ: เพราะการบูตต้องอาศัยเมทาดาทา สิทธิ์ กลไกบูต และไดรเวอร์ที่ผูกกับฮาร์ดแวร์จริง ซึ่งการคัดลอกระดับไฟล์ทั่วไปไม่ได้เก็บไว้ครบทั้งหมด
ถาม: ควรตรวจอะไรเป็นอันดับแรกเมื่อสงสัยว่าข้อมูลสำรองใช้ไม่ได้
ตอบ: ตรวจว่าสามารถกู้คืนและเปิดใช้งานได้จริงบนสภาพแวดล้อมทดสอบ โดยวัดทั้งความครบของข้อมูลและความสามารถในการกลับมาให้บริการ ไม่ใช่เพียงสถานะสำเร็จของงานสำรอง