Cài Proxmox Backup Server trên VPS làm đích offsite

Proxmox Backup Server trên VPS thực sự cung cấp gì

Proxmox Backup Server (PBS) trên VPS là một đích backup offsite sử dụng cùng giao thức với cluster Proxmox VE (virtual environment) hiện có của bạn. Vì vậy, sau lần backup đầu tiên, mọi backup tiếp theo đều là incremental, được deduplicate giữa các guest, được mã hóa trước khi rời khỏi mạng của bạn và có thể kiểm tra lại sau đó. Bạn thuê một VPS có block volume, cài PBS trên Debian 13, tạo một datastore trên volume đó và thêm datastore này vào Proxmox VE dưới dạng storage kiểu pbs. Việc cài đặt mất mười phút. Nhưng những yếu tố quyết định backup còn có giá trị sau một năm là namespace, garbage collection, việc quản lý key và một lần restore mà bạn đã thực sự chạy thử.

Lý do dùng PBS thay vì sao chép các file vzdump vào một disk thuê là chunk store. Client chia disk của từng guest thành các chunk có kích thước khoảng 4 MiB, hash chúng rồi chỉ upload những chunk mà datastore chưa có. Với một virtual machine đang chạy, sau lần backup đầu tiên QEMU theo dõi các block đã thay đổi bằng dirty bitmap. Vì vậy, lần chạy tiếp theo chỉ đọc những block đó từ local disk. Một guest 200 GB thay đổi 3 GB mỗi ngày sẽ gửi khoảng 3 GB mỗi ngày. Cơ chế này giúp uplink tại nhà và volume thuê có thể hoạt động cùng nhau. Đây cũng là lý do VPS làm đích backup offsite tốt hơn một drive dự phòng đặt ở nhà bạn bè. Nếu bạn vẫn đang quyết định nên đặt hypervisor ở đâu, Proxmox tại nhà so với VPS thuê sẽ trình bày riêng câu hỏi đó.

Tính dung lượng volume trước khi thuê

Tính dung lượng là phép tính dựa trên số liệu thực tế của bạn. Lấy dung lượng mà mỗi guest thực sự sử dụng, không lấy kích thước virtual disk, rồi cộng phần thay đổi mỗi ngày nhân với số ngày lưu giữ. Compression và deduplication đều giúp giảm con số này, vì vậy hãy xem kết quả là mức trần, không phải mục tiêu.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Các dòng trên là ví dụ minh họa, không phải số liệu đo thực tế. Đọc dung lượng đã sử dụng từ df -h bên trong từng guest, và đọc phần thay đổi mỗi ngày từ kích thước của bản backup thứ hai và thứ ba trong log của PBS task sau khi các bản backup đó đã tồn tại.

Mail guest trong ví dụ sử dụng 120 GB và thay đổi khoảng 3.0 GB mỗi ngày, vì vậy 30 snapshot hằng ngày cần khoảng 210 GB: một bản đầy đủ cộng với phần thay đổi của 30 ngày. Cộng cột cuối cùng của tất cả 3 guest thì tổng dung lượng khoảng 619 GB. Cộng thêm 1/5 cho index, metadata và khoảng trống cần thiết để garbage collection hoạt động. Mức này tương ứng với volume 1 TB.

Phần còn lại của kế hoạch khá nhỏ. PBS hoạt động tốt với 2 GB RAM và chạy thoải mái với 4 GB, vì phần xử lý nặng diễn ra ở phía cluster: node Proxmox VE đọc các guest disk rồi thực hiện chunking và hashing. VPS chỉ ghi các chunk và chạy 2 job nặng là garbage collection và verification. Hãy thuê datastore dưới dạng block volume riêng thay vì dùng một root disk lớn, vì sau này bạn có thể tăng dung lượng volume mà không phải dựng lại server.

Cài đặt Proxmox Backup Server trên Debian 13

Tính đến tháng 8 năm 2026, phiên bản kết hợp hiện tại là Proxmox Backup Server 4 trên Debian 13, codename trixie. Các hướng dẫn cũ ghép PBS 2 với Debian 11. Codename là một phần của định nghĩa repository, nên nếu sao chép tên suite cũ, apt sẽ báo lỗi thiếu release file. Hãy bắt đầu với một image Debian 13 tối giản. Chạy toàn bộ các lệnh dưới đây bằng root hoặc dùng sudo như đã viết.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Checksum phải là 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Nếu không đúng, hãy dừng lại. Keyring sai có nghĩa là bạn sắp cài các package được ký bởi một nguồn mà bạn chưa kiểm tra.

Ghi /etc/apt/sources.list.d/pbs.sources với repository không có subscription. Đây là repository phù hợp cho server không có hợp đồng hỗ trợ:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

Web interface hoạt động trên HTTPS port 8007. Đăng nhập bằng root@pam và mật khẩu root của hệ thống, vì PBS xác thực user này thông qua PAM (pluggable authentication modules), tức các tài khoản mà operating system sử dụng. Certificate là self-signed nên trình duyệt sẽ cảnh báo. Fingerprint của certificate đó là giá trị mà Proxmox VE sẽ pin về sau, vì vậy cảnh báo này là bình thường và không cần xử lý như một lỗi.

Port 8007 là form đăng nhập trên Internet công cộng, nên không được để mở cho mọi nguồn. Một file nftables là đủ để quản lý port này. Việc ghi /etc/nftables.conf sẽ flush ruleset hiện tại, nên bỏ qua bước này nếu trên máy đã có thành phần khác quản lý firewall.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Áp dụng cấu hình bằng sudo systemctl enable --now nftables và giữ một phiên SSH thứ hai mở trong lúc thực hiện: policy drop cộng với chỉ một lỗi gõ trong rule SSH có thể khóa bạn khỏi chính server của mình. Thay 203.0.113.7 bằng địa chỉ mà cluster của bạn kết nối từ đó. Nếu địa chỉ này là dynamic, hãy mở rộng rule đến range của nhà cung cấp hoặc kết thúc kết nối trong một tunnel. Đồng thời lưu ý rằng hầu hết VPS panel có một network firewall riêng ở phía trước máy, và firewall đó cũng phải cho phép cùng port.

Đặt datastore trên volume riêng

Datastore không được nằm trên filesystem root. Khi datastore làm đầy filesystem root dùng chung, backup sẽ thất bại và mọi thứ khác trên máy cũng dừng, kể cả việc ghi log cần thiết để tìm nguyên nhân. Gắn block volume, format, mount volume, rồi mới tạo datastore bên trong mount point.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Lấy tên device từ lsblk. Trên hầu hết KVM image, device là /dev/vdb; trên các image khác, device là /dev/sdb. Không được mặc định tên device. Thêm mount vào /etc/fstab theo label để việc đổi tên device sau reboot không trỏ datastore vào nhầm disk:

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt phải in ra device, path và các tùy chọn, trong đó có rw,relatime. Một dòng này có thể che giấu hai lỗi. Nếu mount chưa tồn tại mà bạn vẫn tạo datastore, PBS sẽ ghi vào filesystem root bên dưới mount point. Lần mount thành công tiếp theo sẽ che khuất dữ liệu đó nhưng không xóa nó: datastore khi đó trông như rỗng, còn filesystem root vẫn đầy. Nếu các tùy chọn cho biết noatime, PBS sẽ từ chối hoạt động vì nó kiểm tra an toàn access time khi tạo datastore và trong mỗi lần garbage collection.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Lệnh này tạo một thư mục .chunks chứa 65536 thư mục con, được đặt tên từ 0000 đến ffff. Datastore gồm hàng trăm nghìn file nhỏ, không phải vài file lớn. Có hai hệ quả. Sao chép datastore bằng công cụ file-level thông thường sẽ chậm đến mức không thể sử dụng. Snapshot của provider volume được tạo trong khi backup đang chạy cũng không phải là bản sao nhất quán của datastore. Đây cũng là lý do snapshot không thay thế backup ở các phần khác.

Namespace giúp hai host không xung đột

Theo mặc định, datastore có cấu trúc phẳng. Các bản backup được đặt tên là vm/100, ct/101 và host/<name>. Hai cluster cùng có một guest với ID 100 sẽ ghi vào cùng một group, snapshot của chúng bị trộn lẫn, và retention rule viết cho một cluster sẽ tính cả snapshot của cluster kia. Namespace tạo một cây riêng cho từng nguồn bên trong cùng một datastore.

Tạo namespace trên host PBS. Đối số --repository có dạng [[auth-id@]server[:port]:]datastore, vì vậy namespace cục bộ dùng root@pam@localhost:store1, và lệnh sẽ yêu cầu root password.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

Deduplication không bị ảnh hưởng bởi việc tách này. Chunk được dùng chung trên toàn datastore, nên 10 guest Debian trải trên 3 namespace vẫn chỉ lưu một bản của hệ thống cơ sở. Đây là lý do nên dùng một datastore có namespace thay vì mỗi host một datastore: các datastore riêng có các chunk pool riêng, và các chunk pool riêng đồng nghĩa với việc phải lưu cùng một bản cài Debian nhiều lần.

Cấp cho mỗi nguồn một account riêng và giới hạn account đó trong namespace tương ứng. API (application programming interface) token là credential thuộc về một user và có permission riêng. Đây là lựa chọn phù hợp trên một máy có thể bị đánh cắp.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Lệnh tạo token in secret đúng một lần:

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Sao chép secret ngay lúc này, vì PBS không lưu bất kỳ dạng nào có thể hiển thị lại cho bạn. Kiểm tra lệnh access control thật kỹ. Lệnh này chỉ định token, backup@pbs!pve-home, chứ không chỉ định user, vì permission của token chỉ được tính từ các entry chỉ rõ chính token đó. Chỉ có entry cho backup@pbs sẽ khiến token hoàn toàn không có quyền truy cập, và bản backup đầu tiên sẽ fail do permission thay vì do một lỗi có thể nhìn thấy trên network. Path cũng quan trọng tương tự: token bị giới hạn trong /datastore/store1/pve-home không thể đọc hoặc xóa dữ liệu trong namespace office, nên một cluster bị breach không thể xóa lịch sử của site khác.

Thêm VPS làm storage backup trong Proxmox VE

Trước tiên, đọc certificate fingerprint trên PBS host.

sudo proxmox-backup-manager cert info | grep Fingerprint

Sau đó, chạy trên bất kỳ node nào trong cluster:

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Dán giá trị cert info được in ra vào vị trí placeholder ở dòng thứ ba. Truyền --password mà không kèm giá trị sẽ khiến pvesm prompt để nhập giá trị đó, nên token secret không xuất hiện trong shell history. Secret được lưu tại /etc/pve/priv/storage/pbs-offsite.pw, còn storage definition được ghi vào /etc/pve/storage.cfg. File này được replicate đến mọi node trong cluster, vì vậy bạn chỉ cần cấu hình một lần cho toàn bộ cluster.

--prune-backups keep-all=1 yêu cầu Proxmox VE không xóa gì cả. Retention được cấu hình ở phía PBS, sẽ nói ở phần dưới. Lý do rất rõ ràng: token khi đó không cần permission để xóa. Nếu cluster bị ransomware mã hóa, ransomware sẽ không thể truy cập và prune lịch sử backup offsite vốn dùng để khôi phục hệ thống.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status in active trong cột status, cùng với tổng dung lượng và dung lượng đã dùng của datastore. inactive nghĩa là node không thể hoàn tất phiên TLS (transport layer security) đến port 8007. Đây là vấn đề về firewall hoặc fingerprint, không phải vấn đề về credential.

Backup đầu tiên sẽ upload toàn bộ dữ liệu, vì vậy hãy tính thời gian trước khi bắt đầu. 200 GB tương đương 1600 gigabit, còn uplink 100 Mbit truyền được 0.1 gigabit mỗi giây. Thời gian tối thiểu là khoảng bốn tiếng rưỡi, và thực tế sẽ lâu hơn. Hãy chạy backup khi bạn không cần dùng băng thông. Các lần chạy sau chỉ gửi những chunk mới.

Mã hóa phía client và nơi lưu key

VPS là một máy tính không thuộc quyền sở hữu của bạn. Hãy mã hóa trên client để datastore chỉ lưu các chunk mà nhà cung cấp không thể đọc.

sudo pvesm set pbs-offsite --encryption-key autogen

Lệnh này ghi một key mới vào /etc/pve/priv/storage/pbs-offsite.enc. Chỉ root mới có thể đọc key này. Key được sao chép cùng với phần còn lại của /etc/pve. Từ lần backup tiếp theo, client sẽ mã hóa từng chunk trước khi gửi đi. Server vẫn có thể liệt kê các snapshot và dung lượng của chúng, nhưng không thể đọc nội dung.

Đây là phần biến cơ chế này thành backup thay vì một rủi ro. Key được tạo không có passphrase và chỉ tồn tại trên cluster mà nó bảo vệ. Nếu cluster đó bị đánh cắp hoặc bị người khác mã hóa, VPS sẽ chứa dữ liệu mà không ai có thể mở. Hãy sao chép key ra khỏi cluster ngay trong ngày tạo key.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey in key dưới dạng tài liệu để in ra giấy và cất ở nơi khác. Hãy coi chính file này là secret, vì bất kỳ ai giữ file đều có thể giải mã mọi backup được tạo bằng key đó. Với hệ thống lớn hơn, PBS cũng hỗ trợ master key. Đây là một cặp key RSA (Rivest Shamir Adleman) được tạo bằng proxmox-backup-client key create-master-key. Mỗi backup sẽ lưu key mã hóa riêng của nó, được mã hóa bằng public key, còn private key được giữ offline để khôi phục.

Bạn nên biết một hệ quả của thiết kế này trước khi bắt đầu, thay vì chỉ biết sau đó. Với backup được mã hóa, digest của chunk được tính từ nội dung plain text kết hợp với encryption key. Vì vậy, hai chunk giống hệt nhau nhưng được mã hóa bằng các key khác nhau sẽ tạo ra digest khác nhau và không bao giờ deduplicate với nhau. Khi thay đổi key, lần backup tiếp theo sẽ upload lại toàn bộ dữ liệu. Các chunk cũ vẫn tồn tại cho đến khi snapshot của chúng bị prune và được thu gom. Hãy quyết định về việc mã hóa trước lần upload đầu tiên.

Prune chỉ đánh dấu, garbage collection mới thu hồi

Đây là phần thường bị bỏ qua, nhưng lại là phần làm đầy volume. Prune một snapshot sẽ xóa metadata của snapshot đó: manifest, index, log và ghi chú. Nó không xóa bất kỳ chunk nào. Các snapshot dùng chung chunk, nên không thể biết một chunk không còn được dùng cho đến khi đọc hết mọi index còn lại. Garbage collection thực hiện việc đó. Datastore có lịch prune nhưng không có lịch garbage collection sẽ chỉ tiếp tục tăng dung lượng.

Hãy cấu hình cả hai. Cấu hình retention trước, mỗi namespace một job:

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Sau đó cấu hình lịch collection trên datastore, chạy sau prune vài giờ và ngoài khung thời gian backup:

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Hãy tự kiểm chứng sự khác biệt này một lần trên PBS host:

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Chạy prune job, rồi chạy df; số dung lượng đã dùng không thay đổi. Chạy garbage collection, rồi chạy lại df; lúc này số liệu sẽ thay đổi.

Garbage collection chạy qua 2 phase. Phase 1 duyệt mọi index trong datastore và cập nhật access time của mọi chunk được các index đó tham chiếu. Phase 2 xóa các chunk có access time cũ hơn mốc giới hạn. Mốc này là 24 giờ và 5 phút trước thời điểm bắt đầu chạy, hoặc thời điểm bắt đầu của backup cũ nhất vẫn đang ghi, tùy thời điểm nào sớm hơn. Khoảng đệm này cần thiết vì Linux mount filesystem với relatime theo mặc định. Thiết lập này chỉ cập nhật access time khoảng 1 lần mỗi ngày thay vì sau mỗi lần đọc. Vì vậy, chunk được ghi cách đây 1 giờ sẽ không bao giờ bị xóa, ngay cả khi hiện chưa có gì tham chiếu đến nó. Dung lượng được giải phóng sau khi prune sẽ xuất hiện trong lần collection đầu tiên chạy sau hơn 1 ngày kể từ lần cuối chunk được truy cập. Nếu datastore có vẻ không thu hồi được dung lượng nào, nguyên nhân thường là nó vẫn đang trong khoảng thời gian chờ này.

Trên VPS nhỏ, đây là job nặng nhất mà máy chạy vì nó phải lấy metadata của mọi file chunk trên volume. Cuối task log có phần tóm tắt những gì đã bị xóa và những gì vẫn đang chờ do grace period. Nếu còn nhiều mục đang chờ, hãy chạy lại vào ngày hôm sau. PBS cung cấp gc-atime-safety-check và gc-atime-cutoff dưới dạng các tùy chọn tinh chỉnh datastore. Nên giữ nguyên cả hai tùy chọn này. Chúng dành cho storage không thể ghi access time. Tắt kiểm tra an toàn trên filesystem được mount với noatime là cách khiến bạn mất các chunk mà những snapshot còn tồn tại vẫn đang tham chiếu.

Xác minh để đảm bảo các chunk vẫn có thể đọc được

Một bản backup đã upload thành công vẫn có thể không đọc được sau một năm. Quá trình xác minh đọc lại các chunk và so sánh chúng với checksum được lưu trong index. Nhờ đó, lỗi được phát hiện theo lịch thay vì chỉ được phát hiện khi restore.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Giữ số lượng thread ở mức thấp trên VPS nhỏ. Xác minh bị giới hạn bởi disk và CPU, nếu không sẽ tranh chấp tài nguyên với các tác vụ khác đang chạy trên máy. Để lên lịch, hãy dùng tab Verify Jobs của datastore trong web interface. Một job chạy hàng tuần, bỏ qua các snapshot đã xác minh và xác minh lại mọi snapshot cũ hơn 30 ngày, sẽ kiểm tra toàn bộ datastore theo thời gian mà không lặp lại công việc.

Snapshot không vượt qua bước xác minh sẽ được đánh dấu là failed trong giao diện datastore. Không được bỏ qua lỗi này. Các chunk được dùng chung, nên một chunk bị hỏng trong base image thường khiến mọi snapshot tham chiếu đến chunk đó đều xác minh thất bại. Cách sửa là forget các snapshot bị lỗi rồi chạy một backup mới để upload lại các chunk bị thiếu. Nếu lỗi tiếp tục xuất hiện, hãy nghi ngờ storage bên dưới datastore và thiết lập giám sát tình trạng disk trên VPS để drive báo cho bạn trước khi verify job phát hiện lỗi.

Kiểm tra khôi phục, sau đó kiểm tra trên máy không thuộc cluster

Bạn chưa thể biết backup hoạt động cho đến khi khôi phục thử một bản. Hai bài kiểm tra này xác minh hai phần khác nhau.

Toàn bộ guest trên cluster:

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

Cột đầu tiên của pvesm list là volume ID. Timestamp là một phần của ID này, vì vậy hãy sao chép giá trị của bạn thay vì nhập ví dụ. Khôi phục vào một guest ID chưa sử dụng và trên storage khác, sau đó khởi động guest với network interface đã ngắt kết nối. Không bao giờ khôi phục đè lên một guest đang chạy chỉ để kiểm tra backup, vì nếu quá trình khôi phục fail giữa chừng, bạn cũng sẽ mất bản đang hoạt động.

Bài kiểm tra thứ hai thường bị bỏ qua. Hãy giả định tòa nhà chứa cluster đã bị mất và khôi phục từ một máy chưa từng thuộc cluster đó. Trên bất kỳ máy Debian 13 nào, hãy thêm repository chỉ dành cho client bằng /etc/apt/sources.list.d/pbs-client.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Điền ba placeholder được đặt trong dấu ngoặc kép bằng các giá trị của bạn. Lấy tên archive ở dòng cuối từ output mà snapshot files đã in ra. Bài kiểm tra này xác minh điều mà bài kiểm tra đầu tiên không thể: bản sao key file của bạn có thể giải mã dữ liệu thực và bạn có thể điều khiển client từ một máy chưa từng chứa cấu hình của cluster. Hãy ghi lại 4 giá trị mà nó cần: chuỗi repository, token secret, fingerprint và key file. Giữ chúng cùng nhau tại vị trí được disaster plan của bạn chỉ định.

Deduplication ảnh hưởng thế nào đến chi phí lưu trữ trên disk, và không ảnh hưởng đến những gì

Deduplication là cơ chế có thật và hoạt động trên toàn bộ datastore. 10 guest Debian dùng chung một bản sao của hệ thống cơ sở, nên guest thứ hai giống hệt guest đầu tiên gần như không tốn thêm dung lượng lưu trữ. Deduplication cũng tiết kiệm bandwidth upload, vì client chỉ gửi checksum thay vì dữ liệu đối với mỗi chunk mà server đã có.

Những việc deduplication không làm được cần được nói rõ.

• Nó không làm nhỏ dữ liệu thay đổi. Một database ghi lại phần lớn file mỗi đêm sẽ tạo ra các chunk mới mỗi đêm, và retention sẽ nhân số chunk đó lên.
• Nó không vượt qua ranh giới encryption key, như đã nêu ở trên.
• Nó không vượt qua ranh giới datastore. Đây chính là lý do cần dùng namespace.
• Nó không ngăn volume đầy. Khi datastore đầy, backup sẽ fail. Khi đó chỉ có 2 cách xử lý: tăng dung lượng volume hoặc rút ngắn retention.

Không nên đặt thêm một lớp deduplication bên dưới nó. Client đã deduplicate và compress chunk trước khi gửi, nên ZFS deduplication bên dưới datastore chỉ tốn RAM để tìm những bản trùng đã bị loại bỏ trước khi được ghi. Dùng ext4 hoặc xfs thông thường trên volume là lựa chọn phù hợp trong trường hợp này.

Web interface hiển thị deduplication factor của datastore. Con số này mô tả dữ liệu guest của bạn và là con số duy nhất đáng dùng để lập kế hoạch, vì các tỷ lệ được công bố mô tả dữ liệu của người khác. Nếu cũng cần backup ở cấp file cho các máy không phải Proxmox guest, hãy chạy các backup đó song song trên cùng VPS: PBS là target nhận backup có nhận biết hypervisor cho toàn bộ guest, còn restic và BorgBackup trỏ đến các thư mục; backup bằng restic lên VPS phù hợp với laptop và standalone server mà PBS vốn không được thiết kế để hỗ trợ.

Các lỗi thường gặp và dấu hiệu nhận biết

Storage hiển thị trạng thái inactive. pvesm status --storage pbs-offsite hiển thị inactive khi node không thể hoàn tất phiên TLS đến port 8007. Kiểm tra firewall trên VPS, sau đó kiểm tra firewall mạng riêng của nhà cung cấp, rồi kiểm tra fingerprint. Fingerprint không còn khớp với certificate sẽ gây ra cùng dấu hiệu bên ngoài như port bị chặn và sẽ thay đổi mỗi khi certificate đó được thay thế.

Backup đầu tiên thất bại do quyền. Access control entry phải chỉ rõ token thay vì user và phải bao phủ namespace mà storage trỏ đến. Kiểm tra cả hai mục trong tab permissions của datastore trên web interface trước khi kiểm tra nơi khác.

Garbage collection không khởi động. Kiểm tra an toàn về access time đã thất bại. Nguyên nhân gần như luôn là filesystem của datastore được mount với tùy chọn noatime. Chạy findmnt -no OPTIONS /mnt/datastore/store1 để xác nhận, sửa tùy chọn trong /etc/fstab rồi mount lại. Không vô hiệu hóa kiểm tra này để bỏ qua lỗi.

Datastore chỉ tăng dung lượng. Các job prune vẫn chạy nhưng không thu hồi được dung lượng. Nguyên nhân có thể là chưa có lịch garbage collection, hoặc mọi lần collection đều chạy trong khoảng thời gian chờ 24 giờ vì được thực hiện ngay sau backup. Kiểm tra lịch bằng proxmox-backup-manager datastore show store1.

Một backup trước đây chạy nhanh nay mất hàng giờ. Một guest bị stop, migrate hoặc restore sẽ mất dirty bitmap. Vì vậy, lần chạy tiếp theo phải đọc toàn bộ disk ở phía cluster, dù chỉ upload một lượng dữ liệu rất nhỏ. Task log hiển thị thời lượng dài với con số upload nhỏ, còn lần chạy sau đó lại nhanh. Nếu mọi job trên VPS đều chậm, nguyên nhân thường nằm ngoài datastore. CPU steal time do một máy lân cận gây tải là chỉ số đầu tiên cần đo.

FAQ

Vì sao datastore của Proxmox Backup Server vẫn tiếp tục tăng dung lượng khi job prune chạy?

Vì prune chỉ xóa metadata của snapshot: manifest, index, log và note. Các chunk vẫn nằm trên disk cho đến khi garbage collection xóa những chunk không còn index nào tham chiếu. Đặt lịch cho datastore bằng proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27', rồi xác minh bằng cách chạy df -h trên đường dẫn datastore trước và sau proxmox-backup-manager garbage-collection start store1. Hãy chờ ít nhất một ngày, vì phase two chỉ xóa các chunk có access time cũ hơn 24 giờ 5 phút.

VPS chạy Proxmox Backup Server cần bao nhiêu disk?

Cộng dung lượng thực tế mỗi guest đang dùng, sau đó cộng thêm lượng thay đổi hằng ngày của từng guest nhân với số ngày bạn lưu backup. Đây là mức trần, vì compression và deduplication đều giúp giảm dung lượng. Cộng thêm khoảng một phần năm cho index và dung lượng làm việc, rồi làm tròn lên thành dung lượng volume bạn có thể mua. Kiểm tra lại sau hai tuần dựa trên mức sử dụng thực tế trong datastore view, vì mọi ước tính trước backup đầu tiên đều sẽ sai theo cách này hay cách khác.

Nên lưu encryption key của backup ở đâu?

Ở bất kỳ đâu, nhưng không được chỉ lưu trên cluster mà key đó bảo vệ. Proxmox VE lưu key tại /etc/pve/priv/storage/<storage>.enc. File này được replicate đến mọi node, nên sẽ mất cùng cluster. Hãy copy key ra ngoài ngay từ ngày đầu, in key bằng proxmox-backup-client key paperkey và giữ bản sao đó ở một tòa nhà khác. Cũng cần lưu ý rằng key tham gia vào chunk digest, nên nếu thay key sau này, backup tiếp theo sẽ upload lại toàn bộ dữ liệu.

Tôi cần một datastore cho mỗi Proxmox host hay nên dùng namespace?

Dùng một datastore và một namespace cho mỗi source host hoặc cluster. Deduplication hoạt động trong một datastore, không hoạt động giữa các datastore, nên chia theo host sẽ lưu cùng một base image nhiều lần. Namespace tách riêng các backup group, vì vậy hai host cùng có guest ID 100 sẽ không bị xung đột. access control path có dạng /datastore/store1/pve-home sẽ giới hạn API token của mỗi host vào namespace riêng của host đó.

VPS nhỏ có đáp ứng được vai trò Proxmox backup server không?

Thông thường là có, với homelab, vì việc chia chunk và hashing diễn ra trên Proxmox VE node thay vì backup server. VPS chỉ ghi các chunk và chạy hai job nặng là garbage collection và verification. Cấp cho VPS 4 GB RAM và giữ số lượng verification thread ở mức thấp. Đặt lịch cho cả hai job ngoài thời gian chạy backup. Nếu chúng vẫn mất nhiều thời gian hơn mức disk cần, hãy đo steal time trước khi mua plan lớn hơn.