1. Snapshot là gì?
Snapshot là một bản chụp (copy) trạng thái của dữ liệu tại một thời điểm cụ thể, thường được dùng để:
- Restore dữ liệu khi có lỗi
- Làm cơ sở cho backup incremental/differential
- So sánh trạng thái dữ liệu giữa các thời điểm
2. Phân loại Snapshot
Snapshot COW (Copy-On-Write) và ROW (Redirect-On-Write) là hai cơ chế phổ biến được sử dụng khi tạo snapshot trong các hệ thống lưu trữ hoặc file system.
2.1. Snapshot COW – Copy-On-Write.
Nguyên lý hoạt động
- Khi bạn tạo snapshot, dữ liệu gốc không bị sao chép ngay.
- Khi có thay đổi (ghi mới), hệ thống sẽ:
- Ghi bản gốc (của block bị thay đổi) vào snapshot.
- Sau đó, ghi dữ liệu mới đè lên block cũ trong vùng chính.
Diễn giải:
Trước ghi:
[block A] (data = X)
Tạo snapshot → snapshot giữ trạng thái hiện tại (X)
Khi ghi mới:
- Copy block A (X) → snapshot
- Ghi block A = Y → volume
=> Snapshot vẫn giữ block A = X
Ưu điểm:
- Tạo snapshot nhanh (vì không sao chép gì cả ban đầu).
- Tiết kiệm tài nguyên nếu không có thay đổi nhiều.
Nhược điểm:
- Ghi chậm lại: vì mỗi lần ghi mới cần thao tác ghi thêm dữ liệu vào vùng snapshot.
- Snapshot kéo dài → hệ thống có thể bị phân mảnh, chậm.
Ví dụ hệ thống dùng COW:
- LVM snapshot (truyền thống).
- Một số triển khai ZFS khi không có khả năng redirect.
- Các hệ thống backup dạng block-copy.
2.2. Snapshot ROW – Redirect-On-Write
Nguyên lý hoạt động:
- Khi tạo snapshot, không sao chép gì cả.
- Khi có thay đổi, hệ thống sẽ:
- Ghi dữ liệu mới vào block mới khác chỗ
- Giữ nguyên block cũ để snapshot tham chiếu.
Diễn giải:
Tạo snapshot
Khi ghi mới:
- Dữ liệu mới ghi vào block mới (vị trí khác)
- Block cũ vẫn được giữ nguyên cho snapshot
=> Không cần copy trước khi ghi
Ưu điểm:
- Hiệu suất tốt hơn COW trong nhiều trường hợp vì không cần ghi 2 lần.
- Snapshot giữ nguyên block cũ, không phải copy.
Nhược điểm:
- Yêu cầu hệ thống quản lý vị trí ghi linh hoạt hơn.
- Cần hệ thống hỗ trợ quản lý metadata tốt.
Ví dụ hệ thống dùng ROW:
- ZFS snapshot (native sử dụng ROW).
- Btrfs (filesystem với snapshot + send/receive).
- Một số hệ thống lưu trữ enterprise.
2.3. So sánh COW vs ROW
Tiêu chí | COW (Copy-on-Write) | ROW (Redirect-on-Write) |
---|---|---|
Khi ghi dữ liệu mới | Ghi dữ liệu gốc vào snapshot → ghi mới | Ghi mới vào chỗ khác luôn |
Tác động hiệu suất | Có thể chậm hơn | Nhanh hơn vì không cần copy |
Phức tạp triển khai | Đơn giản hơn | Phức tạp hơn (phải quản lý block mới) |
Dễ bị phân mảnh | Cao nếu snapshot lâu | Thấp hơn |
Dùng phổ biến trong | LVM, một số block snapshot | ZFS, Btrfs, advanced FS |
Gợi ý lựa chọn
Nhu cầu | Gợi ý snapshot |
---|---|
Hệ thống nhỏ, ít snapshot | COW |
Backup ngắn hạn, tạm thời | COW |
Nhiều snapshot, hiệu năng ổn định | ROW |
Muốn clone hoặc rollback nhanh | ROW |
2.4. Clone (Full Copy Snapshot)
Nó tạo một bản sao hoàn chỉnh tại thời điểm đó. Tốn thời gian và dung lượng. Không phụ thuộc dữ liệu gốc, thích hợp để tạo môi trường test/dev.
3. Cách snapshot hoạt động (mô tả logic)
Thời gian →
┌────────────┬────────────┬────────────┬────────────┐
│ Snapshot 1 │ Snapshot 2 │ Snapshot 3 │ Snapshot 4 │
│ (20GiB) │ (+0GiB) │ (+2GiB) │ (+5GiB) │
└────────────┴────────────┴────────────┴────────────┘
Dữ liệu gốc → Dữ liệu thay đổi tại từng thời điểm được lưu vào snapshot tương ứng
- Mỗi snapshot lưu phần dữ liệu khác biệt với trạng thái trước đó.
- Phục hồi snapshot sẽ khôi phục trạng thái gốc tại thời điểm đó.
4. Snapshot vật lý vs logic
4.1. Snapshot vật lý:
- Snapshot thực hiện ở tầng block-level.
- Thường tích hợp ở hệ thống lưu trữ (SAN/NAS, LVM, iSCSI, v.v.).
- Ví dụ: LVM snapshot, Ceph RBD snapshot, VMware snapshot.
4.2. Snapshot logic:
- Snapshot thực hiện ở tầng file-level hoặc ứng dụng.
- Thường dùng trong database hoặc VM guest-level backup.
- Ví dụ: Snapshot trong PostgreSQL, snapshot database trong Azure.
5. Ứng dụng của snapshot
- Tạo điểm khôi phục nhanh (Recovery Point)
- Tạo môi trường test (dev/test)
- Backup thông minh (incremental, differential)
- DR (Disaster Recovery) trong môi trường production
- Bảo vệ dữ liệu chống ransomware (Immutable snapshots)
6. Một số công nghệ snapshot phổ biến
Giải pháp | Mô hình | License | Ghi chú |
---|---|---|---|
ZFS | Filesystem | OpenSource | ROW-based, cực kỳ ổn định |
Btrfs | Filesystem | OpenSource | Tích hợp snapshot, send/receive |
LVM | Block-level | OpenSource | COW, có thể dùng với Thin Pool |
Ceph RBD | Block-level | OpenSource | Snapshot & clone VM cực nhanh |
VMware vSphere | VM-level | License | Tạo snapshot hệ điều hành, RAM |
Proxmox VE | VM-level | OpenSource | Tích hợp snapshot ZFS, LVM |
NetApp ONTAP | Storage-level | License | Enterprise snapshot volume |
AWS EBS Snapshot | Block-level | Pay-as-you-go | Tích hợp incremental tự động |
7. Snapshot và Backup – khác nhau thế nào?
Snapshot | Backup |
---|---|
Nhanh, gần như tức thời | Tốn thời gian xử lý |
Lưu trạng thái tại chỗ | Lưu bản sao ở nơi khác |
Phụ thuộc vào volume/storage | Có thể phục hồi ở nơi khác |
Dễ bị mất nếu storage lỗi | An toàn hơn nếu lưu offsite |
Phù hợp rollback ngắn hạn | Phù hợp bảo vệ lâu dài |
8. Lời khuyên khi sử dụng snapshot
- Không dùng snapshot thay cho backup dài hạn.
- Nên xóa snapshot cũ định kỳ để tránh chiếm dung lượng và ảnh hưởng hiệu suất.
- Khi dùng LVM hoặc ZFS: snapshot quá nhiều → có thể làm chậm IO.
- Tránh để snapshot kéo dài quá lâu (nhất là trong môi trường production).
- Nếu dùng trong VM (VD: VMware, KVM), snapshot ảnh hưởng hiệu năng disk I/O nếu giữ lâu.
9. Một vài ví dụ thực tế
- LVM Snapshot cho backup nóng:
- Tạo snapshot → mount snapshot → backup → remove snapshot.
- ZFS send/receive để replicate giữa 2 server:
zfs snapshot tank/data@daily
zfs send -i yesterday today | ssh backup zfs receive backup/data
- AWS EBS Snapshot incremental tự động:
- Tích hợp với lifecycle policies → snapshot hàng ngày → chỉ trả tiền phần thay đổi.
10. Ví dụ về luồng snapshot và backup .
Đây là một câu hỏi về bài thực hành kiến thức cơ bản nhưng rất thực tế liên quan đến snapshot và backup trong môi trường sử dụng volume ảo (VDI, cloud storage như OpenStack Cinder, AWS EBS, v.v).
10.1. Bối cảnh.
- Có một VM dùng volume 100 GiB.
- Ban đầu, VM đã chiếm 20 GiB để cài hệ điều hành.
- Các snapshot và backup được thực hiện theo thứ tự sau.
10.2. Câu hỏi.
Câu 1 – Trong hệ thống backup, có mấy loại backup full? Giải thích sự khác biệt giữa chúng.
Câu 2 – Tạo snapshot snap1:
- Ngay sau khi tạo snapshot, dung lượng snapshot là bao nhiêu?
- Nếu thực hiện backup tại thời điểm này → đây là backup full hay diff? Vì sao?
- Ước tính dung lượng bản backup sẽ thu được.
Câu 3 – Tạo snapshot snap2, nhưng không có thay đổi dữ liệu so với snap1:
- Dung lượng snapshot snap2 là bao nhiêu?
- Nếu thực hiện backup incremental, dung lượng backup sẽ khoảng bao nhiêu? Giải thích.
Câu 4 – Người dùng ghi thêm 2 GiB dữ liệu mới → tạo snapshot snap3:
- Dung lượng snapshot snap3 là bao nhiêu?
- Nếu thực hiện backup incremental, dung lượng backup sẽ khoảng bao nhiêu? Giải thích.
Câu 5 – Người dùng xóa 5 GiB dữ liệu → tạo snapshot snap4:
- Dung lượng snapshot snap4 là bao nhiêu?
- Nếu thực hiện backup incremental, dung lượng backup sẽ khoảng bao nhiêu? Giải thích.
Sơ đồ minh họa
Volume size: 100 GiB
Ban đầu: 20 GiB (HĐH)
Thời gian →
[ snap1 ] ----[ snap2 ] ----[ snap3 ] ----[ snap4 ]
| | | |
| | | |
| | | |
20 GiB 20 GiB 22 GiB 17 GiB
(full) (no change) (+2 GiB new) (-5 GiB deleted)
10.3. Trả lời.
Backup full có bao nhiêu loại trong hệ thống? Nêu sự khác biệt giữa chúng.
Có 2 loại backup full phổ biến:
- Backup full truyền thống (Full physical backup):
- Sao lưu toàn bộ dữ liệu tại thời điểm backup.
- Dung lượng lớn vì không quan tâm dữ liệu có thay đổi hay không.
- Ví dụ: clone toàn bộ ổ đĩa dù chỉ 20 GiB đang sử dụng.
- Backup full theo block/used-block (Used-block full backup):
- Chỉ sao lưu các block đang được sử dụng.
- Nếu volume 100 GiB nhưng chỉ dùng 20 GiB thì backup chỉ ~20 GiB.
- Thường thấy trong hệ thống backup thông minh hoặc khi tích hợp với snapshot.
Khác biệt chính.
Truyền thống là backup tất cả block (kể cả chưa dùng), còn used-block chỉ backup phần đang sử dụng.
Tạo snapshot thứ nhất (snap1) và kiểm tra ngay dung lượng sau khi snap xong.
Nó sẽ có dung lượng là bao nhiêu?
- Snap1 là snapshot đầu tiên → không có thay đổi nào so với volume gốc.
- Dung lượng snapshot: 0 GiB
Vì snapshot chỉ lưu sự khác biệt sau thời điểm chụp, mà chưa có sự thay đổi gì.
+ Nếu thực hiện backup tại thời điểm này, đây là bản full hay diff? Tại sao?
- Là bản full.
- Vì đây là lần backup đầu tiên → không có bản gốc nào để so sánh sự khác biệt.
+ Ước tính dung lượng bản backup thu được là bao nhiêu?
- Dữ liệu sử dụng là 20 GiB (cài hệ điều hành).
- Nếu backup theo kiểu used-block full → dung lượng backup ~ 20 GiB.
Tạo snapshot thứ hai (snap2) nhưng KHÔNG có thay đổi dữ liệu.
+ Dung lượng snapshot snap2 là bao nhiêu?
- Không có sự thay đổi giữa snap1 và snap2.
- → Dung lượng snapshot snap2 là 0 GiB.
+ Nếu thực hiện backup incremental, dung lượng backup sẽ khoảng bao nhiêu? Giải thích vì sao lại như vậy.
- Dung lượng backup incremental: ~0 GiB
- Vì incremental chỉ sao lưu phần khác biệt so với bản backup trước (snap1 → snap2 không có sự khác biệt).
Người dùng ghi thêm 2 GiB dữ liệu mới → tạo snapshot snap3
+ Dung lượng snapshot snap3 là bao nhiêu?
- Snapshot ghi nhận thay đổi so với snap2.
- Dữ liệu mới ghi thêm là 2 GiB.
- → Dung lượng snapshot snap3: ~2 GiB
+ Nếu thực hiện backup incremental, dung lượng bản backup sẽ khoảng bao nhiêu?
- ~2 GiB
- Vì chỉ có 2 GiB block mới được ghi và snapshot giúp xác định chính xác các block đó.
Giải thích:
- Incremental backup dựa vào sự thay đổi so với lần backup trước (snap2).
- Chỉ phần mới ghi (2 GiB) cần sao lưu.
Người dùng xóa 5 GiB dữ liệu → tạo snapshot snap4:
+ Dung lượng snapshot snap4 là bao nhiêu?
- Xóa dữ liệu = các block trước đó được đánh dấu đã xóa, nhưng vẫn tồn tại nếu chưa được GC.
- Snapshot lưu lại các block bị ghi đè/xóa (để phục hồi).
- → Dung lượng snapshot snap4: ~5 GiB
+ Nếu thực hiện backup incremental, bản backup sẽ chiếm bao nhiêu dung lượng?
- ~5 GiB
- Vì incremental phải sao lưu block bị xóa để đảm bảo khả năng khôi phục dữ liệu về đúng thời điểm trước khi xóa.
Giải thích:
- Trong backup dạng block-level, khi dữ liệu bị xóa, hệ thống vẫn cần lưu lại thông tin block đã bị xóa để đảm bảo tính toàn vẹn dữ liệu nếu cần khôi phục lại trạng thái trước đó.
Tổng kết nhanh:
Snapshot | Dung lượng Snap | Incremental Backup (ước tính) |
---|---|---|
snap1 | 0 GiB | Full ~20 GiB |
snap2 | 0 GiB | ~0 GiB |
snap3 | ~2 GiB | ~2 GiB |
snap4 | ~5 GiB | ~5 GiB |
Dưới đây là sơ đồ mô tả chuỗi backup + snapshot giúp bạn dễ hình dung mối quan hệ giữa các snapshot và các bản backup.
Diễn tiến sự kiện (snapshot và backup):
Thời gian →
┌────────────────────────────────────────────────────────────────────────────────┐
│ │
│ [snap1] [snap2] [snap3] [snap4] │
│ ↓ ↓ ↓ ↓ │
│ +------+ +------+ +------+ +------+ │
│ | 20G |─────► | 20G |──────► | 22G |───────►| 17G | │
│ +------+ +------+ +------+ +------+ │
│ full no change +2G write -5G delete │
│ backup (0G diff) (2G diff) (5G diff) │
│ ~20G ~0G ~2G ~5G │
│ (used blk) │
└────────────────────────────────────────────────────────────────────────────────┘
Tóm tắt từng giai đoạn:
Thời điểm | Snapshot | Thao tác người dùng | Dung lượng snapshot | Backup loại gì | Dung lượng backup |
---|---|---|---|---|---|
T0 | – | Cài OS (20 GiB) | – | – | – |
T1 | snap1 | Không thay đổi | 0 GiB | Full | ~20 GiB |
T2 | snap2 | Không thay đổi | 0 GiB | Incremental | ~0 GiB |
T3 | snap3 | Ghi thêm 2 GiB | 2 GiB | Incremental | ~2 GiB |
T4 | snap4 | Xoá 5 GiB dữ liệu | 5 GiB | Incremental | ~5 GiB |
10. Tài liệu tham khảo
- ZFS Snapshots – OpenZFS Docs
- Understanding LVM Snapshots
- Btrfs Snapshot How-To
- AWS EBS Snapshots
- Proxmox Snapshot Docs
Nếu bạn đang triển khai hệ thống backup hoặc DR (disaster recovery), snapshot là một công cụ rất mạnh, nhưng nó phải được phối hợp chặt chẽ với hệ thống backup truyền thống để đạt hiệu quả và an toàn dữ liệu tối ưu.