Khi Phân Vùng Không Mount Được và Hệ Thống Báo Lỗi
Năm ngoái, một trong những máy chủ VPS của tôi không khởi động lại được sau khi cập nhật kernel. Quá trình boot bị treo với lỗi kernel panic, báo rằng filesystem ext4 trên /dev/sda2 bị hỏng. Sau 3 năm quản lý hơn 10 máy chủ VPS Linux, tôi học được rằng phải luôn kiểm tra kỹ các quy trình khôi phục trước khi áp dụng lên môi trường production — và sự chuẩn bị đó đã cứu tôi ngày hôm đó.
Filesystem bị hỏng không phải là trường hợp hiếm gặp. Mất điện đột ngột, cập nhật kernel thất bại, lỗi ghi phần cứng, hoặc thậm chí lệnh shutdown -r now trong khi đang thực hiện disk I/O đều có thể khiến phân vùng ext4 rơi vào trạng thái không nhất quán. Linux đi kèm với các công cụ được xây dựng đặc biệt để phát hiện và sửa những vấn đề này.
Hướng dẫn này phân tích hai công cụ chính — fsck và e2fsck — so sánh khi nào nên dùng cái nào, và chỉ cho bạn cách khôi phục phân vùng bị hỏng mà không làm tình hình tệ hơn.
Nguyên Nhân Gốc Rễ: Tại Sao Filesystem Bị Hỏng?
Trước khi dùng công cụ sửa chữa, hiểu rõ bạn đang sửa gì sẽ rất hữu ích:
- Dirty unmount — mất điện hoặc kernel crash trong khi đang có ghi dữ liệu. Journal không được flush sạch sẽ.
- Bad sector — ổ đĩa bị xuống cấp vật lý gây ra các thao tác ghi chỉ hoàn thành một phần, để lại block ở trạng thái không xác định.
- Bitmap không khớp — bitmap sử dụng inode hoặc block không còn khớp với trạng thái phân bổ thực tế.
- Superblock bị hỏng — superblock chính (metadata filesystem) bị ghi đè hoặc bị xóa trắng.
- Inode mồ côi — file bị xóa trong khi đang mở, để lại các inode không có directory entry nào trỏ đến.
Mỗi nguyên nhân đòi hỏi chiến lược sửa chữa hơi khác nhau, đó là lý do tại sao hiểu sự khác biệt giữa fsck và e2fsck lại quan trọng.
So Sánh Các Phương Pháp: fsck vs e2fsck vs debugfs
Ba công cụ xử lý khôi phục filesystem ext2/ext3/ext4. Mỗi công cụ phục vụ một vai trò riêng — chọn nhầm công cụ đầu tiên có thể tốn thời gian và khiến việc khôi phục khó hơn.
fsck (Kiểm tra tính nhất quán Filesystem)
fsck là bộ điều phối giao diện. Khi bạn chạy fsck /dev/sda2, nó phát hiện loại filesystem và ủy quyền cho backend phù hợp — với ext4 đó là e2fsck. Đây là điểm khởi đầu phù hợp khi viết script kiểm tra nhiều phân vùng với các loại filesystem khác nhau.
e2fsck (Dành riêng cho ext2/ext3/ext4)
e2fsck là công cụ làm việc thực sự cho dòng ext. Nó làm việc trực tiếp trên cấu trúc filesystem và chạy năm pass kiểm tra: inode/block/kích thước, cấu trúc directory, kết nối directory, số tham chiếu và thông tin tổng hợp nhóm. Chạy e2fsck trực tiếp — thay vì qua wrapper fsck — cho bạn output chi tiết theo từng pass và kiểm soát tốt hơn đối với hành vi sửa chữa.
debugfs (Khôi phục tương tác)
debugfs không phải công cụ sửa chữa — đây là trình debug filesystem cấp thấp. Dùng nó khi e2fsck bất lực: lỗi hỏng quá nghiêm trọng để sửa tự động. Lúc đó, bạn có thể tái tạo cây directory thủ công hoặc kéo các file cụ thể ra trước khi phân vùng hoàn toàn không đọc được.
Ưu và Nhược Điểm của Từng Phương Pháp
fsck
- Ưu điểm: Cú pháp đơn giản, tự động phát hiện loại filesystem, tiện lợi cho shell script
- Nhược điểm: Ẩn chi tiết e2fsck, ít kiểm soát hành vi sửa chữa, thông báo lỗi chung chung
e2fsck
- Ưu điểm: Kiểm soát toàn diện, output chi tiết theo từng pass, hỗ trợ khôi phục backup superblock, xử lý journal replay
- Nhược điểm: Chỉ dành cho dòng ext, cần biết loại filesystem trước
debugfs
- Ưu điểm: Có thể trích xuất file từ filesystem hỏng nặng, có chế độ read-only
- Nhược điểm: Thủ công và phức tạp, dễ làm tình hình tệ hơn nếu không hiểu những gì đang xem
Khôi phục hàng ngày: dùng e2fsck trực tiếp. Chỉ dùng debugfs khi e2fsck một mình không giải quyết được vấn đề.
Chuẩn Bị Trước Khi Bắt Đầu
Chạy fsck trên filesystem đang được mount rất nguy hiểm và sẽ làm hỏng thêm dữ liệu. Ba điều cần xác nhận trước khi bắt đầu:
- Tạo ảnh đĩa trước tiên — nếu dữ liệu quan trọng, hãy sao chép phân vùng trước khi thử sửa chữa.
- Unmount filesystem — fsck yêu cầu phân vùng phải được unmount. Với phân vùng root, hãy boot từ USB live hoặc sử dụng môi trường rescue.
- Ghi lại vị trí backup superblock — ext4 lưu backup superblock tại các offset đã biết. Bạn sẽ cần chúng nếu superblock chính bị hỏng.
Để tạo ảnh phân vùng trước khi thực hiện bất kỳ thao tác nào:
# Sao chép phân vùng sang nơi an toàn (ổ đĩa ngoài, NFS, v.v.)
dd if=/dev/sda2 of=/mnt/backup/sda2.img bs=4M status=progress
# Với ổ đĩa có bad sector, dùng ddrescue (xử lý lỗi tốt hơn)
apt install gddrescue
ddrescue -d -r3 /dev/sda2 /mnt/backup/sda2.img /mnt/backup/sda2.logTìm vị trí backup superblock cho phân vùng của bạn trước khi có sự cố:
dumpe2fs /dev/sda2 | grep -i "superblock"
# Kết quả: Backup superblock at 32768, 98304, 163840 ...Hướng Dẫn Thực Hiện
Bước 1: Xác định Filesystem và Kiểm tra Trạng thái
# Liệt kê tất cả phân vùng với loại filesystem
lsblk -f
# Kiểm tra trạng thái mount hiện tại
mount | grep sda2
# Lấy thông tin chi tiết về filesystem
dumpe2fs -h /dev/sda2 | head -40Tìm Filesystem state: not clean trong output của dumpe2fs — điều này xác nhận filesystem không được unmount sạch và cần kiểm tra.
Bước 2: Unmount Filesystem
# Unmount phân vùng không phải root
umount /dev/sda2
# Nếu đang bận, tìm tiến trình đang sử dụng
fuser -km /dev/sda2
lsof | grep sda2Phân vùng root không thể unmount khi hệ thống đang chạy. Hãy boot từ USB live Ubuntu hoặc Debian. Nếu bạn vẫn còn truy cập được shell qua single-user mode:
# Remount root ở chế độ read-only trước khi chạy fsck
mount -o remount,ro /Bước 3: Chạy e2fsck
# Kiểm tra cơ bản với tự động sửa (trả lời yes cho tất cả)
e2fsck -y /dev/sda2
# Hiển thị chi tiết từng pass
e2fsck -v -y /dev/sda2
# Buộc kiểm tra dù filesystem có vẻ sạch
e2fsck -f /dev/sda2
# Kiểm tra và hiển thị thanh tiến trình
e2fsck -C 0 /dev/sda2Cờ -y tiện lợi cho quá trình khôi phục không cần giám sát — nhưng hãy xem lại output sau đó. Nó tự động chấp nhận mọi đề xuất sửa chữa. Thường thì ổn, nhưng trên filesystem bị hỏng nặng, nó có thể xóa dữ liệu vốn có thể khôi phục được bằng cách can thiệp thủ công.
Bước 4: Khôi phục từ Superblock bị Hỏng
Nếu e2fsck báo bad magic number in super-block, superblock chính đã mất. Hãy dùng backup:
# Hiển thị vị trí superblock sẽ được tạo (KHÔNG format)
mke2fs -n /dev/sda2
# Chạy e2fsck với backup superblock cụ thể
e2fsck -b 32768 /dev/sda2
# Nếu 32768 không hoạt động, thử vị trí backup tiếp theo
e2fsck -b 98304 /dev/sda2
# Bạn cũng có thể khôi phục superblock chính từ backup
e2fsck -b 32768 -B 4096 /dev/sda2Bước 5: Trích xuất File từ Phân vùng Bị Hỏng Nặng
Khi e2fsck không thể sửa phân vùng tự động, debugfs cho phép bạn kéo file ra trước khi dữ liệu mất vĩnh viễn. Luôn mở ở chế độ read-only trước:
# Mở phân vùng ở chế độ read-only
debugfs -c /dev/sda2
# Trong shell tương tác của debugfs:
debugfs> ls /home/user
debugfs> dump /home/user/important.db /tmp/important.db
debugfs> stat /home/user/important.db
debugfs> quitRiêng với file đã xóa? extundelete xử lý tốt hơn debugfs — nhưng hãy chạy trước e2fsck. Khi fsck đã sửa đổi bảng inode, cơ hội khôi phục file đã xóa giảm đáng kể.
# Cài đặt và khôi phục file đã xóa trước khi chạy fsck
apt install extundelete
extundelete /dev/sda2 --restore-all --output-dir /mnt/recoveredBước 6: Xác minh Kết quả Sửa chữa
# Chạy lại e2fsck — phải ra kết quả sạch
e2fsck -f /dev/sda2
# Xác nhận trạng thái filesystem
dumpe2fs -h /dev/sda2 | grep "Filesystem state"
# Sẽ hiện: Filesystem state: clean
# Remount và kiểm tra
mount /dev/sda2 /mnt/test
ls /mnt/test
dmesg | tail -20 # Tìm các lỗi mới sau khi mountNgăn Chặn Lỗi Hỏng trong Tương lai
Sau khi trải qua quá trình này trên server production lúc 2 giờ sáng — trải nghiệm mà tôi không khuyến nghị ai — tôi đã thêm những thứ này vào thiết lập VPS tiêu chuẩn của mình:
# Đặt chu kỳ kiểm tra filesystem (mỗi 30 lần mount hoặc 3 tháng)
tune2fs -c 30 -i 3m /dev/sda2
# Thêm noatime vào fstab để giảm tần suất ghi không cần thiết
# /dev/sda2 /data ext4 defaults,noatime 0 2
# Theo dõi sức khỏe ổ đĩa hàng tuần
apt install smartmontools
systemctl enable smartd
smartctl -a /dev/sda # Báo cáo SMART đầy đủ
smartctl -t short /dev/sda # Kiểm tra sức khỏe nhanhMục tiêu không phải là trở thành chuyên gia khôi phục filesystem — mà là không bao giờ cần đến những công cụ này với dữ liệu quan trọng. Snapshot định kỳ, RAID hoặc replication cho dữ liệu quan trọng, và theo dõi SMART ổ đĩa sẽ giúp bạn tránh khỏi tình huống khôi phục lúc 2 giờ sáng. Điều đó hữu ích hơn nhiều so với việc thuộc lòng danh sách lệnh sửa chữa.
Dù vậy, khi filesystem thực sự bị hỏng, e2fsck -b 32768 với backup superblock đã cứu dữ liệu của tôi nhiều lần. Hãy giữ các lệnh đó trong tầm tay và luôn tạo ảnh phân vùng trước khi làm bất cứ điều gì.
