Hôm qua một anh dev trong team mình vừa lên update kernel trên server production, và sau đó… hệ thống boot lỗi. Không có snapshot, không có boot entry dự phòng, phải ngồi rescue mode mất 3 tiếng. Câu chuyện quen thuộc mà ai làm sysadmin lâu năm đều đã gặp ít nhất một lần.
Đó là lý do mình bắt đầu dùng Boom Boot Manager — công cụ cho phép tạo và quản lý boot entries trong GRUB2, kết hợp với LVM Snapshot để tạo điểm khôi phục hệ thống thực sự dùng được. Công ty mình vẫn còn vài con server chạy CentOS 7, và việc migrate sang AlmaLinux là bài toán mình đã xử lý. Nhưng với CentOS Stream 9, Boom chính là thứ giúp mình ngủ ngon hơn trước mỗi lần update.
Làm ngay trong 5 phút: Tạo boot entry đầu tiên
Trước khi giải thích dài dòng, thử làm luôn để thấy nó hoạt động thế nào.
Bước 1: Cài đặt Boom
dnf install boom-boot -yBước 2: Tạo OS Profile
Boom cần biết thông tin về hệ điều hành của bạn để generate boot entries đúng cú pháp:
# Xem profile đã có chưa
boom profile list
# Nếu chưa có, tạo tự động từ host hiện tại
boom profile create --from-hostBước 3: Tạo boot entry thử nghiệm
# Lấy profile ID vừa tạo
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
# Tạo boot entry từ kernel hiện tại
boom entry create \
--profile ${PROFILE_ID} \
--title "CentOS Stream 9 - Test Entry" \
--root-device /dev/mapper/cs-root
# Kiểm tra entry đã được tạo
boom entry listSau khi reboot, bạn sẽ thấy entry mới xuất hiện trong GRUB menu. Đơn giản vậy thôi.
Hiểu rõ hơn: Boom giải quyết vấn đề gì?
GRUB2 có file cấu hình tại /boot/grub2/grub.cfg, nhưng file này được generate tự động bởi grub2-mkconfig. Mỗi lần cài kernel mới, file này bị ghi đè. Mọi thay đổi thủ công đều mất theo.
Boom giải quyết bằng cách tạo các Boot Entries — file riêng biệt trong /boot/loader/entries/ — theo chuẩn Boot Loader Specification (BLS). Những file này không bị ghi đè khi cài kernel mới, tồn tại độc lập với grub.cfg.
# Xem các boot entry files
ls /boot/loader/entries/
# Đọc nội dung một entry
cat /boot/loader/entries/*.confMột entry file trông như thế này:
title CentOS Stream 9 - Restore Point 20240115
version 5.14.0-362.el9.x86_64
machine-id abc123def456
options root=/dev/mapper/cs-snap-20240115 ro crashkernel=1G-4G:192M
linux /vmlinuz-5.14.0-362.el9.x86_64
initrd /initramfs-5.14.0-362.el9.x86_64.imgChú ý dòng root= — đây là nơi bạn trỏ vào bất kỳ LVM volume nào, kể cả snapshot.
Nâng cao: Kết hợp Boom với LVM Snapshot tạo restore point
Đây mới là phần quan trọng. Boom được thiết kế để làm việc với LVM Snapshot — tức là chụp lại trạng thái hệ thống tại một thời điểm, tạo boot entry trỏ vào snapshot đó, và khi cần thì boot vào đó để khôi phục.
Kiểm tra cấu hình LVM hiện tại
# Xem volume groups
vgs
# Xem logical volumes chi tiết
lvs
# Ví dụ output:
# LV VG Attr LSize
# home cs -wi-ao---- 5.00g
# root cs -wi-ao---- 35.00g
# swap cs -wi-ao---- 4.00gTạo LVM Snapshot trước khi update
# Tạo snapshot của root volume (10GB dung lượng cho changes)
lvcreate -L10G -s -n root-snap-$(date +%Y%m%d) /dev/cs/root
# Kiểm tra snapshot
lvs | grep snapMình thường để snapshot size bằng 20-30% volume gốc. Server nhiều write thì cần nhiều hơn — nếu snapshot đầy 100% thì nó tự hủy, lúc đó boot entry trỏ vào đó sẽ không dùng được.
Tạo Boom Boot Entry trỏ vào snapshot
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
SNAP_DATE=$(date +%Y%m%d)
SNAP_DEV="/dev/cs/root-snap-${SNAP_DATE}"
boom entry create \
--profile ${PROFILE_ID} \
--title "Restore Point ${SNAP_DATE}" \
--root-device ${SNAP_DEV} \
--root-opts "ro"
boom entry listScript tự động hóa toàn bộ quy trình
Làm thủ công mãi thì mệt, mình viết luôn cái script này và đặt vào trước mỗi lần update:
#!/bin/bash
# /usr/local/bin/create-restore-point.sh
SNAP_DATE=$(date +%Y%m%d_%H%M)
VG_NAME="cs"
LV_NAME="root"
SNAP_SIZE="10G"
SNAP_NAME="${LV_NAME}-snap-${SNAP_DATE}"
echo "=== Tạo restore point: ${SNAP_DATE} ==="
# 1. Tạo LVM snapshot
echo "Đang tạo LVM snapshot..."
lvcreate -L${SNAP_SIZE} -s -n ${SNAP_NAME} /dev/${VG_NAME}/${LV_NAME}
if [ $? -ne 0 ]; then
echo "FAILED: Không thể tạo snapshot"
exit 1
fi
# 2. Tạo boom entry
echo "Đang tạo boot entry..."
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
boom entry create \
--profile ${PROFILE_ID} \
--title "Restore Point ${SNAP_DATE}" \
--root-device /dev/${VG_NAME}/${SNAP_NAME} \
--root-opts "ro"
echo "=== Xong! Restore point ${SNAP_DATE} đã sẵn sàng ==="
boom entry listchmod +x /usr/local/bin/create-restore-point.sh
# Chạy trước khi update
create-restore-point.sh
# Update thoải mái
dnf update -yTips thực tế
Dọn dẹp restore points cũ
Snapshot tốn dung lượng, đừng để chồng chất quá nhiều:
# Xem danh sách entries với Entry ID
boom entry list
# Xóa entry không cần nữa (thay abc123 bằng Entry ID thực)
boom entry delete abc123
# Xóa LVM snapshot tương ứng
lvremove /dev/cs/root-snap-20240110_0930Giám sát mức dùng snapshot
# Xem usage — nếu Data% gần 100% thì cần chú ý
lvs -o lv_name,lv_size,data_percent /dev/csMình đặt cron job check hàng ngày để cảnh báo sớm:
#!/bin/bash
# /etc/cron.daily/check-snapshots
lvs --noheadings -o lv_name,data_percent | while read lv pct; do
pct_int=${pct%%.*}
if [ -n "${pct_int}" ] && [ "${pct_int}" -gt 80 ] 2>/dev/null; then
echo "WARNING: LVM Snapshot ${lv} đã dùng ${pct}%" | \
logger -t lvm-snapshot-alert
fi
doneBoot vào restore point khi cần khôi phục
- Reboot server
- Ở màn hình GRUB, nhấn phím bất kỳ để dừng đếm ngược
- Chọn entry “Restore Point YYYYMMDD”
- Hệ thống boot vào trạng thái tại thời điểm tạo snapshot
- Kiểm tra mọi thứ ổn không, rồi quyết định rollback hay giữ lại update
Nếu quyết định rollback hoàn toàn, merge snapshot vào volume gốc (thao tác này không thể hoàn tác — cần làm từ rescue mode hoặc live environment):
# Thực hiện từ rescue mode hoặc live CD
lvconvert --merge /dev/cs/root-snap-20240115_0900Boom vs grubby — khi nào dùng cái nào?
Nhiều người quen dùng grubby để quản lý boot entries. Sự khác biệt thực tế: grubby chỉnh trực tiếp vào grub.cfg và dễ bị ghi đè, còn Boom tạo file BLS entries độc lập — an toàn hơn và quản lý theo snapshot tốt hơn nhiều. Nếu bạn đang làm việc với LVM Snapshot workflow, Boom là lựa chọn tự nhiên.
Từ khi áp dụng workflow này, team mình không còn lo lắng khi update kernel hay package lớn nữa. Chạy create-restore-point.sh trước, update xong kiểm tra ổn rồi xóa snapshot. Chưa bao giờ phải dùng đến restore point thật sự — nhưng biết rằng nó ở đó, mọi người làm việc tự tin hơn nhiều.
