Read-only File System: แก้ดิสก์ที่อ่านได้อย่างเดียวบน Linux
คำตอบสั้น ๆ: แก้ Read-only file system บน Linux แยกจากดิสก์เต็มและ Inode เต็ม อ่านสาเหตุจาก Log ของ kernel สำรองข้อมูลก่อน แก้ fstab และซ่อมด้วย fsck อย่างถูกขั้นตอน
คู่มือนี้อธิบาย Read-only ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย
Read-only file system คือข้อความ Error ที่ Linux แสดงเมื่อโปรแกรมพยายามเขียนไฟล์ลงระบบไฟล์ที่ถูก mount แบบอ่านอย่างเดียว อาการที่เห็นคือเว็บอัปโหลดไฟล์ไม่ได้ ฐานข้อมูลหยุด Log ไม่เดิน หรือ apt ติดตั้งอะไรไม่ได้ ส่วนใหญ่ไม่ได้เกิดจากใครตั้งค่า แต่ kernel สลับระบบไฟล์เป็น Read-only เองเมื่อพบความผิดพลาด เพื่อกันไม่ให้ข้อมูลเสียหายมากขึ้น ระบบไฟล์ ext4 ที่ mount ด้วยตัวเลือก errors=remount-ro (ค่าที่ Ubuntu และ Debian ใส่ให้ดิสก์ระบบใน /etc/fstab) จะทำแบบนี้ ส่วน XFS จะหยุดระบบไฟล์ทั้งหมดแทน
คู่มือนี้เหมาะกับผู้ดูแล Linux Server บนคลาวด์ที่เจอข้อความนี้กะทันหัน เมื่อทำครบ คุณจะแยกได้ว่าเป็นดิสก์ Read-only จริง ดิสก์เต็ม หรือ Inode เต็ม รู้สาเหตุจาก Log ของ kernel สำรองข้อมูลออกก่อนแตะอะไร แก้ /etc/fstab ที่ผิด ตรวจซ่อมระบบไฟล์ด้วย fsck อย่างถูกขั้นตอนทั้งดิสก์ข้อมูลและดิสก์ระบบ และรู้ว่าเมื่อไรต้องแจ้งผู้ให้บริการคลาวด์
สิ่งที่ต้องเตรียม
- สิทธิ์ root หรือ sudo และช่องทางเข้า Console ของเครื่องผ่านพอร์ทัล เพราะบางขั้นตอนต้องรีบูต และ SSH อาจใช้ไม่ได้ ดูวิธีใน คู่มือ Remote เข้า Console ผ่าน Web UI
- ที่สำหรับคัดลอกข้อมูลออก เช่น เซิร์ฟเวอร์อีกเครื่องในเครือข่ายเดียวกัน หรือ Object Storage
- Backup หรือ Snapshot ล่าสุดของเครื่อง และรู้วิธีกู้ ถ้าใช้ THAI DATA CLOUD ดู คู่มือการ Backup Server บน Cloud ของ TDC
- ช่วงเวลาหยุดระบบ เพราะการซ่อมระบบไฟล์ต้อง unmount หรือรีบูต
สำรองข้อมูลออกก่อนซ่อมเสมอ เพราะ fsck อาจย้ายหรือลบไฟล์ที่เสียหาย
ขั้นตอนที่ 1: ยืนยันว่าเป็น Read-only จริง ไม่ใช่ดิสก์เต็ม
สามอาการนี้มักถูกเหมาเป็นเรื่องเดียวกัน แต่แก้คนละทาง ให้ทดสอบเขียนไฟล์แล้วดูข้อความให้ชัด
touch /var/tmp/rw-test
findmnt -no SOURCE,FSTYPE,OPTIONS /
df -h /
df -i /
Read-only file system และ findmnt แสดง ro นำหน้า: ระบบไฟล์ถูก mount แบบ Read-only ทำต่อตามคู่มือนี้No space left on device และ df -h แสดง 100%: ดิสก์เต็ม แก้ตาม คู่มือดิสก์เต็มNo space left on device แต่ df -h ยังว่าง และ df -i แสดง IUse% 100%: Inode เต็ม ต้องลบไฟล์เล็กจำนวนมาก ไม่ใช่ซ่อมระบบไฟล์
ตรวจดิสก์อื่นด้วย findmnt -no TARGET,OPTIONS -t ext4,xfs เพราะบางครั้งดิสก์ระบบปกติ แต่ดิสก์ข้อมูลที่ mount ไว้ที่ /data เป็น Read-only
ขั้นตอนที่ 2: หาสาเหตุจาก Log ของ kernel
kernel บันทึกเหตุผลก่อนสลับเป็น Read-only เสมอ ข้อความที่พบตอนต้นเหตุเกิดสำคัญกว่าข้อความท้าย ๆ
sudo journalctl -k -b -o cat | grep -iE 'i/o error|ext4-fs|xfs|jbd2|journal'
sudo dmesg -T | grep -iE 'error|read-only' | head -n 40
sudo journalctl -k -b -1 --no-pager | tail -n 100 # Log ของการบูตครั้งก่อน ถ้ารีบูตไปแล้ว
ข้อความแรกสุดใน Log บอกต้นเหตุ ในตัวอย่างนี้ I/O error มาก่อน จึงต้องแจ้งผู้ให้บริการก่อนซ่อม
อ่านผลแบบนี้
- มี
I/O error หรือ Buffer I/O error ก่อน: ต้นเหตุอยู่ที่ดิสก์หรือระบบจัดเก็บด้านล่าง บนคลาวด์อาจเป็นการสะดุดของ Storage ของผู้ให้บริการ ให้จดเวลาและข้อความ แล้วแจ้งผู้ให้บริการก่อนซ่อม อย่ารัน fsck ซ้ำหลายรอบบนดิสก์ที่ยังมี I/O error
- มี
EXT4-fs error โดยไม่มี I/O error: โครงสร้างระบบไฟล์เสียหาย เช่น หลังเครื่องดับกะทันหัน ซ่อมด้วย fsck ตามขั้นตอนที่ 5
- XFS แสดงข้อความว่าระบบไฟล์ถูก shut down: XFS ไม่สลับเป็น Read-only แต่หยุดทั้งระบบไฟล์ อาการคือ
Input/output error ทุกครั้งที่อ่านเขียน ต้อง unmount แล้วซ่อมด้วย xfs_repair
- หน้า Console ขึ้น You are in emergency mode หลังรีบูต: มักเกิดจาก /etc/fstab อ้างดิสก์ที่ไม่มีอยู่ ข้ามไปขั้นตอนที่ 4
ความหมายของตัวเลือก errors= ของ ext4 ดูได้ใน เอกสาร ext4 ของ Linux kernel
ขั้นตอนที่ 3: สำรองข้อมูลออกก่อนซ่อม
ระบบไฟล์ที่เป็น Read-only ส่วนใหญ่ยังอ่านได้ ช่วงนี้คือโอกาสดีที่สุดในการดึงข้อมูลสำคัญออก เพราะ fsck อาจย้ายไฟล์ที่เสียหายไปไว้ใน lost+found หรือลบโครงสร้างที่ซ่อมไม่ได้ทิ้ง
# คัดลอกไฟล์เว็บ ค่าตั้งระบบ และไฟล์ Dump ไปเครื่องอื่น
rsync -aR /var/www /etc /var/backups [email protected]:/srv/rescue/web-01/
# ฐานข้อมูลหยุดไปแล้วเพราะเขียนไม่ได้ คัดลอกโฟลเดอร์ข้อมูลทั้งโฟลเดอร์ได้เมื่อบริการหยุดสนิท
sudo systemctl stop mariadb
sudo rsync -a /var/lib/mysql/ [email protected]:/srv/rescue/web-01-mysql/
ถ้าแพลตฟอร์มมี Snapshot หรือ Backup ของดิสก์ ให้สร้างอีกชุดก่อนซ่อมด้วย ถ้าการซ่อมทำให้แย่ลง จะกลับมาที่จุดนี้ได้ ถ้าการคัดลอกเจอ Input/output error ให้ข้ามไฟล์นั้นและจดชื่อไว้ อย่าวนอ่านไฟล์เดิมซ้ำ
ขั้นตอนที่ 4: แก้ /etc/fstab เมื่อเครื่องเข้า emergency mode
ถ้า /etc/fstab มี UUID ผิด หรืออ้างดิสก์ที่ถูกถอดไปแล้ว systemd จะเข้า emergency mode โดยที่ดิสก์ระบบยังเป็น Read-only กรณีนี้ระบบไฟล์ไม่ได้เสีย แก้ที่ไฟล์ได้เลยจาก Console
mount -o remount,rw /
blkid # ดู UUID จริงของทุกดิสก์
cp /etc/fstab /etc/fstab.bak
nano /etc/fstab # แก้ UUID หรือใส่ nofail ให้ดิสก์ข้อมูล
systemctl daemon-reload
findmnt --verify
mount -a
สำหรับดิสก์ข้อมูลที่ไม่ใช่ดิสก์ระบบ ใส่ตัวเลือก nofail ไว้ เช่น UUID=… /data ext4 defaults,nofail 0 2 ถ้าดิสก์หายไปเครื่องยังบูตได้ รายละเอียดอยู่ใน คู่มือ Mount ดิสก์ถาวรด้วย fstab และ UUID เมื่อ findmnt --verify ไม่มีข้อผิดพลาดแล้ว ให้รีบูตหนึ่งครั้งเพื่อยืนยัน
ข้อควรระวัง: mount -o remount,rw / ใช้ได้กับกรณี fstab เท่านั้น ถ้า kernel สลับเป็น Read-only เพราะพบ Error การสั่งกลับเป็นเขียนได้ทั้งที่ยังไม่ซ่อม เสี่ยงทำให้ข้อมูลเสียหายมากขึ้น
ขั้นตอนที่ 5: ซ่อมระบบไฟล์ที่เป็น Read-only ด้วย fsck
fsck ต้องรันกับระบบไฟล์ที่ไม่ได้ mount อยู่ การรันกับระบบไฟล์ที่ใช้งานอยู่ทำให้เสียหายเพิ่ม วิธีขึ้นกับว่าเป็นดิสก์ข้อมูลหรือดิสก์ระบบ
ดิสก์ข้อมูล เช่น /data
sudo systemctl stop nginx php8.3-fpm mariadb # หยุดบริการที่ใช้ดิสก์นี้
sudo umount /data
sudo e2fsck -fn /dev/vdb1 # ตรวจอย่างเดียว ไม่แก้อะไร ดูขนาดความเสียหายก่อน
sudo e2fsck -fp /dev/vdb1 # ซ่อมเฉพาะปัญหาที่แก้ได้อย่างปลอดภัย
sudo mount /data
ถ้า -p หยุดพร้อมข้อความ UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY ให้รัน sudo e2fsck -f /dev/vdb1 แล้วตอบคำถามทีละข้อ ความหมายของตัวเลือกทั้งหมดดูใน คู่มือคำสั่ง e2fsck สำหรับ XFS ใช้ sudo xfs_repair -n /dev/vdb1 เพื่อตรวจก่อน แล้วจึง sudo xfs_repair /dev/vdb1 ถ้าระบบบอกว่าต้องเล่น Log ก่อน ให้ mount แล้ว umount หนึ่งครั้ง ตัวเลือก -L ที่ล้าง Log ใช้เป็นทางสุดท้ายเท่านั้น เพราะทำให้ข้อมูลที่ยังไม่ถูกเขียนหายได้
ดิสก์ระบบ (/)
ดิสก์ระบบ unmount ขณะเครื่องทำงานไม่ได้ ทางที่ง่ายที่สุดบน Ubuntu และ Debian คือสั่งให้ systemd ตรวจและซ่อมตอนบูต ผ่านหน้า Console
- สั่ง
sudo reboot แล้วดูหน้า Console เมื่อเมนู GRUB ขึ้น ให้กด e ที่รายการแรก (ถ้าเมนูไม่ขึ้น ให้กด Shift ค้างระหว่างบูตสำหรับเครื่องแบบ BIOS หรือกด Esc สำหรับเครื่องแบบ UEFI)
- เลื่อนไปท้ายบรรทัดที่ขึ้นต้นด้วย
linux เพิ่ม fsck.mode=force fsck.repair=yes
- กด Ctrl+X เพื่อบูตครั้งเดียวด้วยค่านี้ ระบบจะตรวจดิสก์ระบบก่อน mount แบบเขียนได้ และตอบ yes ให้การซ่อมทุกข้อ
ดิสก์ระบบต้องมีเลขช่องสุดท้ายใน /etc/fstab เป็น 1 (ค่าเริ่มต้นของ Ubuntu) จึงจะถูกตรวจตอนบูต ค่าที่ใส่ใน GRUB ด้วยวิธีนี้ใช้ครั้งเดียวและไม่ติดไปรอบถัดไป ถ้าเครื่องบูตไม่ขึ้นเลย อีกทางคือบูตจาก ISO กู้ระบบหรือนำดิสก์ไปต่อกับเครื่องอื่นแล้วซ่อมแบบดิสก์ข้อมูล วิธีนี้ขึ้นกับว่าแพลตฟอร์มรองรับหรือไม่ ให้เปิด Ticket ถามผู้ให้บริการ
ข้อความคล้ายกันแต่แก้คนละทาง อ่านข้อความและผล df ให้ชัดก่อนลงมือ
ขั้นตอนที่ 6: ตรวจหลังซ่อมและเฝ้าดูว่าไม่กลับมา Read-only อีก
findmnt -no OPTIONS / # ต้องขึ้นต้นด้วย rw
touch /var/tmp/rw-test && rm /var/tmp/rw-test
ls -la /lost+found /data/lost+found 2>/dev/null
systemctl --failed
sudo journalctl -k -b -p err --no-pager
ถ้า lost+found มีไฟล์ใหม่ แปลว่า fsck กู้ไฟล์ที่หลุดจากโฟลเดอร์มาไว้ด้วยชื่อเป็นตัวเลข ให้เทียบกับข้อมูลที่สำรองไว้ในขั้นตอนที่ 3 เปิดบริการทีละตัว ตรวจฐานข้อมูลด้วยเครื่องมือของฐานข้อมูลนั้น แล้วเฝ้าดู Log ของ kernel อีก 2–3 วัน ถ้า Read-only กลับมาอีก หรือยังเห็น I/O error ให้ถือว่าดิสก์หรือระบบจัดเก็บมีปัญหา ย้ายข้อมูลไปดิสก์ใหม่และแจ้งผู้ให้บริการ
ข้อสีแดงทำให้ความเสียหายลามจากระบบไฟล์ไปถึงข้อมูลที่ยังอ่านได้
ปัญหาที่พบบ่อยเกี่ยวกับ Read-only file system
สั่ง mount -o remount,rw / แล้วใช้ต่อไปเลยได้ไหม?
ถ้าสาเหตุคือ kernel พบ Error ไม่ควร ระบบไฟล์ที่มีปัญหาแต่ถูกบังคับให้เขียนต่อ อาจทำให้ข้อมูลเสียหายเพิ่มจนกู้ยาก ให้สำรองข้อมูล หาสาเหตุ และซ่อมด้วย fsck ก่อน คำสั่งนี้เหมาะกับกรณี emergency mode จาก fstab ในขั้นตอนที่ 4 เท่านั้น
ทำไมเครื่องกลายเป็น Read-only ทั้งที่ไม่มีใครแก้อะไร?
ext4 ที่ตั้ง errors=remount-ro จะสลับเป็น Read-only เองเมื่อเขียนลงดิสก์ไม่สำเร็จหรือพบโครงสร้างเสียหาย เหตุที่พบบ่อยบนคลาวด์คือระบบจัดเก็บสะดุดชั่วคราว เครื่องถูกปิดกะทันหัน หรือดิสก์ที่ต่อเพิ่มถูกถอดขณะใช้งาน
Docker หรือ Snap ขึ้น Read-only file system แต่ดิสก์หลักปกติ เกิดจากอะไร?
บางส่วนถูกออกแบบให้เป็น Read-only โดยตั้งใจ เช่น อิมเมจของ Snap ที่ mount แบบ squashfs หรือคอนเทนเนอร์ที่รันด้วย --read-only หรือโฟลเดอร์ที่ mount เข้าไปด้วย :ro ให้ตรวจตัวเลือก mount ของคอนเทนเนอร์ก่อน ไม่ต้องซ่อมระบบไฟล์ของเครื่อง
รัน fsck แล้วไฟล์หายไปบางส่วน กู้คืนได้ไหม?
ดูใน lost+found ของระบบไฟล์นั้นก่อน ถ้าไม่พบ ให้กู้จาก Backup หรือข้อมูลที่คัดลอกออกไว้ในขั้นตอนที่ 3 นี่คือเหตุผลที่ต้องสำรองข้อมูลก่อนซ่อมทุกครั้ง
ถ้าเครื่องกลายเป็น Read-only ซ้ำ หรือต้องการให้ทีมช่วยตรวจ Log และกู้ข้อมูล ติดต่อทีมงาน THAI DATA CLOUD หรือดูรายละเอียดบริการ Cloud Linux Server
อ่านเพิ่มเติมเกี่ยวกับ Read-only
