Snapshot Internals & Cross-Region Backup
Snapshot là gì về mặt kỹ thuật
Snapshot của Persistent Disk không phải copy-on-write (CoW) theo nghĩa truyền thống của storage snapshot. Hiểu sai điều này dẫn đến expectations sai về performance impact khi tạo snapshot và về behavior khi xóa snapshot.
Theo Google Cloud documentation, snapshot đầu tiên của một disk là full snapshot — chứa tất cả data trên disk tại thời điểm đó. Các snapshot sau là incremental — chỉ chứa các blocks đã thay đổi kể từ snapshot trước đó thành công cuối cùng.
Điểm quan trọng: "incremental" ở đây là changed block tracking ở tầng block storage (Colossus), không phải ở tầng filesystem. Điều này có nghĩa:
- Snapshot không cần biết filesystem là gì (ext4, xfs, hay raw)
- File bị xóa ở tầng filesystem nhưng blocks chưa được overwrite vẫn xuất hiện trong snapshot
- Defragmentation hoặc filesystem operations có thể làm snapshot size tăng vì blocks bị move
Cơ chế changed block tracking
Khi Colossus nhận write request vào một Persistent Disk, nó track những blocks nào đã thay đổi kể từ last snapshot. Khi snapshot mới được khởi tạo, chỉ những changed blocks này được đọc và lưu vào snapshot storage. Unchanged blocks được tham chiếu từ snapshot cũ, không được copy.
Về mặt implementation, snapshot chain trông như sau:
Snapshot 1 (Full) ← chứa blocks: A, B, C, D, E, F, G, H
│
└─ Snapshot 2 (Incremental) ← chứa: C', E' (đã thay đổi)
← tham chiếu từ S1: A, B, D, F, G, H
│
└─ Snapshot 3 (Incremental) ← chứa: A', D', G'
← tham chiếu từ S2: C', E'
← tham chiếu từ S1: B, F, HKhi restore từ Snapshot 3, hệ thống reconstruct data bằng cách lấy:
- A', D', G' từ Snapshot 3
- C', E' từ Snapshot 2
- B, F, H từ Snapshot 1
Snapshot deletion behavior: counter-intuitive
Điều mà nhiều engineers ngạc nhiên: xóa một snapshot không nhất thiết giảm storage consumption.
Khi xóa một snapshot giữa chain, bất kỳ block nào cần thiết để restore các snapshot sau đó phải được move vào snapshot tiếp theo. Kết quả: snapshot bị xóa biến mất, nhưng snapshot kế tiếp tăng size.
Trước khi xóa Snapshot 2:
S1 (100 GB) → S2 (20 GB changed) → S3 (15 GB changed)
Total: 135 GB
Sau khi xóa Snapshot 2:
S1 (100 GB) → S3 (35 GB = 20 GB merged + 15 GB)
Total: 135 GB (unchanged)Storage giảm thực sự chỉ khi xóa snapshot không cần thiết để reconstruct bất kỳ snapshot nào khác — thường là xóa snapshot cũ nhất trong chain không còn references.
Implication thực tế cho retention policy: đừng nghĩ "xóa snapshot cũ để tiết kiệm dung lượng ngay lập tức". Tính toán storage cost cần dựa trên tổng chuỗi snapshot, không phải từng snapshot riêng lẻ.
Snapshot scope: global vs regional
Persistent Disk snapshots có thể là global scope hoặc regional scope:
Global snapshots:
- Lưu trữ ở Cloud Storage multi-regional locations (ví dụ:
us,asia,eu) - Tự động replicated across multiple locations với checksums
- Accessible từ mọi region trong GCP
- Higher durability (Cloud Storage multi-regional: 11 nines)
Regional snapshots:
- Lưu trữ trong một specific region
- Chi phí thấp hơn global snapshots
- Chỉ accessible trong region đó
- Tốt hơn cho compliance requirements về data residency
Mặc định khi tạo snapshot không chỉ định location: snapshot là global. Để data residency compliance (GDPR, healthcare), cần explicit chỉ định regional snapshot.
Cross-region snapshot copy
Copy snapshot sang region khác là cơ chế phổ biến cho disaster recovery:
# Copy snapshot sang region khác
gcloud compute snapshots create us-central1-backup \
--source-snapshot=original-snapshot \
--storage-location=us-central1Về mặt kỹ thuật, cross-region copy tạo ra một snapshot độc lập tại destination region. Sau khi copy hoàn tất, snapshot mới không còn liên kết chain với snapshot gốc. Nếu tiếp tục tạo incremental snapshots từ disk gốc, chúng sẽ increment trên chain gốc tại source region — không ảnh hưởng đến snapshot đã copy tại destination.
Implication cho DR strategy: Nếu muốn incremental cross-region backup, cần setup snapshot creation tại destination region, không chỉ copy từ source. Copy là one-time operation; incremental chain cần được duy trì riêng tại mỗi location.
Snapshot chains: tạo chain độc lập
Kể từ phiên bản API mới, có thể tạo snapshot chains độc lập bằng cách chỉ định chain name khi tạo snapshot:
gcloud compute snapshots create snapshot-prod-v1 \
--source-disk=my-disk \
--chain-name=production-chain
gcloud compute snapshots create snapshot-dr-v1 \
--source-disk=my-disk \
--chain-name=dr-chainHai chains này độc lập về mặt incremental tracking. Điều này cho phép:
- Một chain cho production backup (frequent, kept 7 days)
- Một chain cho DR (ít frequent hơn, kept 30 days)
- Không ảnh hưởng lẫn nhau về incremental behavior
Snapshot và application consistency
Snapshot của PD là crash-consistent theo mặc định — giống như một power failure xảy ra đúng lúc snapshot được tạo. Data trong kernel write buffer có thể không được flush vào disk.
Điều này đủ cho nhiều workloads, nhưng không đủ cho databases đang ghi active:
- Database có thể đang trong giữa một transaction
- WAL (Write-Ahead Log) có thể chưa được fsynced
- Recovery sau restore cần replay WAL → mất một ít data hoặc cần recovery time
Để application-consistent snapshot với PostgreSQL:
-- Lock tables và flush
SELECT pg_start_backup('snapshot-label');
-- Tạo snapshot ở đây
SELECT pg_stop_backup();Hoặc dùng fsfreeze để freeze filesystem trước khi snapshot:
fsfreeze -f /data
gcloud compute disks snapshot my-disk --snapshot-names=consistent-snapshot
fsfreeze -u /dataLưu ý: Với GKE workloads sử dụng Backup for GKE, có built-in mechanism để coordinate application quiescing trước khi tạo volume snapshot.
Performance impact của snapshot creation
Một câu hỏi thực tế: tạo snapshot có ảnh hưởng performance của disk không?
Theo documentation và kinh nghiệm production, snapshot creation có minimal impact trên performance của disk đang được snapshot. Colossus đọc blocks để tạo snapshot qua background path, không block I/O path của application.
Tuy nhiên, có một edge case: snapshot của disk rất lớn (TB range) với high write rate có thể tạo ra background I/O contention tại tầng Colossus. Trong practice, điều này ít xảy ra nhưng cần monitor trong environment có SLA strict về latency.
Snapshot scheduling: best practices
Thay vì tạo snapshot manually, nên dùng snapshot schedules (resource policies):
gcloud compute resource-policies create snapshot-schedule \
daily-backup \
--start-time=04:00 \
--hourly-schedule=24 \
--max-retention-days=7 \
--storage-location=us-central1 \
--on-source-disk-delete=keep-auto-snapshotsQuan trọng: --on-source-disk-delete=keep-auto-snapshots đảm bảo snapshots không bị xóa khi disk bị xóa (quan trọng cho accidental deletion protection).
Retention và cost: Với incremental snapshots, retention 7 ngày không có nghĩa là bạn trả tiền cho 7 × full-disk-size. Cost thực tế = full snapshot + 6 × incremental size. Trong thực tế incremental snapshot thường chỉ 5–20% disk size mỗi ngày cho typical workloads.