Hệ điều hành · 16/10/2026

Btrfs Snapshot và Send/Receive: Backup Linux đúng cách

Btrfs snapshot giúp quay lại trạng thái cũ rất nhanh, nhưng snapshot nằm cùng filesystem vẫn có thể biến mất khi thiết bị hỏng, filesystem bị phá hủy hoặc tài khoản quản trị bị chiếm quyền. Một chiến lược backup đúng cần tạo snapshot chỉ đọc, chuyển nó sang một fault domain khác bằng btrfs send/receive, kiểm soát chuỗi incremental và thường xuyên diễn tập khôi phục.

Btrfs snapshot giúp quay lại trạng thái cũ rất nhanh, nhưng snapshot nằm cùng filesystem vẫn có thể biến mất khi thiết bị hỏng, filesystem bị phá hủy hoặc tài khoản quản trị bị chiếm quyền. Một chiến lược backup đúng cần tạo snapshot chỉ đọc, chuyển nó sang một fault domain khác bằng btrfs send/receive, kiểm soát chuỗi incremental và thường xuyên diễn tập khôi phục.

Bài viết bám theo tài liệu chính thức về subvolume và snapshot, btrfs send và btrfs receive. Hãy kiểm tra phiên bản kernel và btrfs-progs đang chạy trước khi áp dụng option mới.

1. Snapshot nhanh, nhưng chưa phải backup

Cơ chế	Bảo vệ tốt trước	Không tự bảo vệ trước
Snapshot cục bộ	Xóa nhầm, cập nhật lỗi, cần rollback nhanh	Hỏng thiết bị/filesystem, mất máy, phá hoại cùng quyền quản trị
RAID/replica	Một số lỗi thiết bị, tăng availability	Xóa nhầm được nhân bản, ransomware, lỗi logic
Send/receive sang hệ độc lập	Mất nguồn, rollback và khôi phục dữ liệu	Không hữu ích nếu không kiểm tra, không có retention hoặc cùng credential bị chiếm

Copy-on-write cho phép snapshot dùng chung extent chưa thay đổi với subvolume nguồn, nên tạo nhanh và ban đầu tốn ít dung lượng. Chính việc dùng chung storage là lý do snapshot cục bộ không thay thế bản sao độc lập. Mục tiêu thực tế nên được mô tả bằng RPO, RTO, số fault domain và thời gian lưu giữ thay vì chỉ ghi “có snapshot”.

2. Hiểu subvolume trước khi lập lịch

Subvolume là một cây file riêng trong Btrfs, không phải block device như logical volume của LVM. Snapshot là một subvolume mới chia sẻ dữ liệu CoW tại thời điểm tạo. Điểm rất dễ bỏ sót: snapshot không đệ quy; subvolume lồng bên trong trở thành một stub rỗng trong snapshot cha.

btrfs subvolume list /srv
btrfs subvolume show /srv/app
findmnt -t btrfs

Trước khi backup, lập inventory mọi subvolume, mount point và dữ liệu thuộc ứng dụng nào. Nếu /srv/app/database là subvolume riêng nằm trong /srv/app, snapshot của /srv/app không mang dữ liệu database theo. Cần snapshot và gửi từng subvolume theo một manifest có kiểm soát.

3. Filesystem-consistent chưa chắc application-consistent

Snapshot chụp một trạng thái nhất quán của filesystem, nhưng dữ liệu ứng dụng có thể còn trong RAM hoặc một giao dịch đang trải qua nhiều file. Database, VM image và message broker cần cơ chế riêng:

gọi pre-hook để flush/checkpoint hoặc đưa ứng dụng vào backup mode;
tạm dừng ghi trong khoảng ngắn nhất cần thiết;
tạo snapshot chỉ đọc;
gọi post-hook để tiếp tục dịch vụ;
sau đó mới send snapshot ở nền.

fsfreeze chỉ là một công cụ và không thay thế hướng dẫn backup của database. Không giữ filesystem bị freeze trong suốt thời gian truyền nhiều giờ. Với nhiều subvolume phụ thuộc nhau, cần thiết kế consistency group ở tầng ứng dụng hoặc chấp nhận và tài liệu hóa điểm khôi phục không nguyên tử.

4. Tạo snapshot chỉ đọc và đặt tên bất biến

install -d -m 0700 /srv/.snapshots/app
btrfs subvolume snapshot -r \
  /srv/app \
  /srv/.snapshots/app/app-2026-10-16T110000+0700

btrfs property get \
  /srv/.snapshots/app/app-2026-10-16T110000+0700 ro
btrfs subvolume show \
  /srv/.snapshots/app/app-2026-10-16T110000+0700

btrfs send yêu cầu các snapshot tham gia phải thật sự có cờ read-only; chỉ mount read-only là chưa đủ vì cùng subvolume có thể còn một mount ghi khác. Lưu UUID, parent UUID, generation, thời điểm, application checkpoint và trạng thái job trong catalog. Tên file giúp con người đọc, nhưng không đủ để chứng minh quan hệ cha-con.

5. Full send đầu tiên

Ví dụ dưới ghi stream ra file tạm để có thể kiểm tra exit code và checksum rõ ràng trước khi vận chuyển. Phân vùng tạm phải đủ chỗ và được bảo vệ vì stream chứa nội dung backup ở dạng không mã hóa mặc định.

umask 077
btrfs send \
  -f /var/tmp/app-2026-10-16.full.btrfs \
  /srv/.snapshots/app/app-2026-10-16T110000+0700
sha256sum /var/tmp/app-2026-10-16.full.btrfs \
  > /var/tmp/app-2026-10-16.full.btrfs.sha256

Chuyển stream và checksum qua kênh được mã hóa tới máy backup. Tại đích, xác minh checksum rồi receive vào filesystem Btrfs dành riêng:

sha256sum -c app-2026-10-16.full.btrfs.sha256
install -d -m 0700 /backup/received/app
btrfs receive -f app-2026-10-16.full.btrfs \
  /backup/received/app

Chỉ đánh dấu job thành công khi cả send, vận chuyển, checksum và receive đều thành công. Xóa stream tạm theo retention dành cho staging, không để nó âm thầm lấp đầy filesystem nguồn.

6. Incremental send và hợp đồng về parent

Sau full base, snapshot mới có thể gửi phần thay đổi so với parent đã tồn tại giống hệt ở cả hai đầu:

btrfs subvolume snapshot -r \
  /srv/app \
  /srv/.snapshots/app/app-2026-10-17T110000+0700

btrfs send \
  -p /srv/.snapshots/app/app-2026-10-16T110000+0700 \
  -f /var/tmp/app-2026-10-17.incremental.btrfs \
  /srv/.snapshots/app/app-2026-10-17T110000+0700

Snapshot parent phải chưa bị sửa và phải tương ứng với bản nhận ở đích. Không chuyển bản received sang read-write, không “sửa nhanh” file trong đó và không xóa parent trước khi incremental kế tiếp đã nhận xong. Tài liệu Btrfs cảnh báo thay đổi cờ read-only của received snapshot có thể phá giả định dựa trên received_uuid.

7. Retention không được làm đứt chuỗi

Một chính sách đơn giản có thể giữ 7 daily, 5 weekly và 12 monthly, nhưng thứ tự xóa mới là phần nguy hiểm. Mỗi job cần xác định “parent kế tiếp” đang tồn tại và hợp lệ ở cả source lẫn destination. Chỉ sau khi snapshot con đã receive, kiểm tra và trở thành base mới, parent cũ mới đủ điều kiện xóa.

Giữ retention nguồn và đích độc lập; đích thường giữ lâu hơn.
Định kỳ tạo full mới để giới hạn phụ thuộc lịch sử và thời gian khôi phục.
Khi mất parent, tạo full base mới thay vì cố ép incremental.
Dùng lock để hai job retention và send không chạy đua.
Theo dõi exclusive/referenced space; số snapshot không phản ánh dung lượng thực.

8. Bảo vệ receive và đường truyền

Tài liệu chính thức lưu ý btrfs receive không xác thực đầy đủ tính hợp lý của incremental stream; stream được chế tạo độc hại có thể tạo reflink tới file tùy ý trong cùng filesystem. Vì vậy:

không receive stream từ nguồn không tin cậy;
bảo vệ stream bằng kênh xác thực và mã hóa khi đi qua mạng không tin cậy;
receive vào filesystem/path chuyên dụng, không cùng nơi chứa dữ liệu nhạy cảm khác;
không cho user ghi vào đường dẫn nhận trong lúc receive đang chạy;
tách credential backup khỏi credential quản trị nguồn và hạn chế lệnh phía đích;
cân nhắc bản sao immutable/offline để giảm blast radius của ransomware.

Checksum trong send stream giúp phát hiện lỗi truyền của command, không cung cấp bí mật dữ liệu hay xác thực người gửi. Mã hóa đường truyền, mã hóa storage, quản lý khóa và access log là các lớp riêng.

9. Scrub, SMART và backup giải quyết các bài toán khác nhau

btrfs scrub đọc dữ liệu/metadata, kiểm tra checksum và có thể sửa từ bản sao tốt khi profile có redundancy. Nó hữu ích để phát hiện silent corruption nhưng không khôi phục file đã bị xóa đúng logic. SMART cảnh báo một số dấu hiệu phần cứng; RAID giữ dịch vụ qua một số lỗi đĩa; send/receive tạo điểm khôi phục. Production cần các lớp này cùng nhau, không chọn một để thay tất cả.

10. Monitoring phải đo khả năng khôi phục

Tín hiệu	Cảnh báo khi
Tuổi snapshot thành công gần nhất	Vượt RPO
Full/incremental send và receive	Exit code khác 0, timeout hoặc thiếu end marker
Parent UUID/catalog	Không khớp hoặc bị thiếu ở một đầu
Bytes và thời lượng	Tăng/giảm bất thường so với baseline
Dung lượng source, staging, destination	Không đủ cho snapshot/stream kế tiếp
Tuổi lần restore test gần nhất	Vượt lịch diễn tập

Dashboard màu xanh vì command cuối trả 0 chưa đủ. Catalog nên liên kết snapshot nguồn, received snapshot, checksum, application checkpoint và kết quả restore test.

11. Restore drill từ đầu đến cuối

Chọn ngẫu nhiên một recovery point theo catalog.
Khôi phục vào host/filesystem cô lập, không ghi đè production.
Nếu cần ghi, tạo snapshot read-write từ bản received chỉ đọc thay vì sửa base.
Mount và kiểm tra owner, mode, xattr, ACL, symlink và dữ liệu ứng dụng.
Chạy kiểm tra logic: database recovery, checksum nghiệp vụ, mở file mẫu, khởi động service.
Đo RTO, ghi lại bước thủ công, cập nhật runbook và xóa môi trường test có kiểm soát.

btrfs subvolume snapshot \
  /backup/received/app/app-2026-10-17T110000+0700 \
  /restore-test/app-writable

Không tuyên bố backup “đã kiểm chứng” nếu chỉ list được snapshot. Bằng chứng là một lần restore sạch, application đọc được dữ liệu và thời gian hoàn tất nằm trong RTO.

Checklist production

Inventory bao phủ mọi subvolume lồng nhau; không giả định snapshot đệ quy.
Pre/post-hook tạo được application-consistent point.
Snapshot dùng cho send luôn read-only và có catalog UUID/generation.
Bản sao nằm ở fault domain khác với credential và retention riêng.
Stream chỉ đến từ nguồn tin cậy, được bảo vệ khi truyền và không nhận vào path dùng chung.
Retention không xóa parent đang cần cho incremental tiếp theo.
Capacity, job age, duration, bytes, checksum và receive result đều có alert.
Có full base mới định kỳ và phương án khi mất parent.
Scrub và health monitoring chạy riêng, không bị hiểu nhầm là backup.
Restore drill diễn ra định kỳ và chứng minh cả RPO lẫn RTO.

Kết luận

Btrfs biến snapshot và sao chép incremental thành thao tác hiệu quả, nhưng độ tin cậy đến từ quy trình xung quanh: hiểu ranh giới subvolume, quiesce ứng dụng, giữ snapshot bất biến, vận chuyển sang fault domain độc lập, bảo vệ receiver, quản lý parent và diễn tập restore. Snapshot giúp quay lại nhanh; chỉ một bản sao đã được khôi phục thử mới chứng minh bạn có backup.