Dùng VPS làm nơi lưu backup off-site

Bản chất của backup target off-site

Backup target off-site là một máy thứ hai lưu bản sao dữ liệu của bạn và gặp lỗi độc lập với máy gốc. VPS tại một nhà cung cấp khác là lựa chọn rẻ nhất mà phần lớn người đọc có thể dùng. Có 3 mô hình thực tế: chạy Proxmox Backup Server trên VPS, dùng repository của restic qua SSH hoặc S3, hoặc dùng một rsync mirror do backup host chủ động pull. Lựa chọn phù hợp tùy vào loại dữ liệu bạn cần restore và tốc độ cần khôi phục. Ai có quyền xóa bản sao sẽ quyết định các phần còn lại.

Off-site nghĩa là nằm trong một failure domain khác. Điều đó có nghĩa là dùng nhà cung cấp khác và một account không dùng chung thông tin đăng nhập với account đang chạy server của bạn. Một server thứ hai ở region khác của cùng nhà cung cấp vẫn tồn tại nếu xảy ra hỏa hoạn tại một tòa nhà. Nhưng nó không bảo vệ được bạn trước việc control panel login bị compromise, vì một account kiểm soát cả 2 bản sao.

Snapshot tại nhà cung cấp không phải là bản sao thứ hai như vậy. Snapshot nằm sau cùng một mật khẩu panel, nên ai lấy được mật khẩu đó có thể xóa server và toàn bộ snapshot trong cùng một session. Dịch vụ snapshot cũng tính phí theo gigabyte mỗi tháng với mức cao hơn nhiều so với disk thông thường, khiến việc giữ chúng trong 90 ngày trở nên đắt đỏ. Nên đọc Sự khác nhau giữa VPS snapshot và backup trước khi dựa vào một trong hai loại này.

Bạn phù hợp với mô hình nào trong ba mô hình

• Proxmox Backup Server (PBS): nguồn là Proxmox VE (môi trường ảo hóa), còn đối tượng được khôi phục là toàn bộ máy ảo. PBS sao lưu ở cấp disk image và các verify job sẽ đọc lại dữ liệu đang nằm trên target.
• Một repository restic: nguồn là một hoặc nhiều Linux host, còn đối tượng được khôi phục là một thư mục hoặc database dump. restic mã hóa dữ liệu trên client, hỗ trợ SSH và S3, đồng thời có REST protocol riêng.
• rsync over SSH, do backup host pull: bạn muốn các file trên target ở dạng file thông thường, có thể đọc bằng ls và cat, không cần cài client software để khôi phục dữ liệu.

Nếu chưa quyết định được, hãy dùng restic. restic mã hóa dữ liệu trước khi dữ liệu rời khỏi máy và trên target chỉ cần có một SSH account cùng disk. Thiết lập backup restic trên VPS trình bày sâu hơn về phía client, còn So sánh restic và BorgBackup giúp bạn chọn nếu đã chạy Borg.

Tính quy mô: chi phí lưu giữ một tháng

Deduplication là lý do các con số nhỏ hơn nhiều so với dự đoán. restic và PBS đều chia file thành các chunk có kích thước thay đổi, rồi hash từng chunk. Mỗi chunk duy nhất chỉ được lưu một lần. Lần backup thứ hai của dataset 500 GB không làm tăng thêm 500 GB. Nó chỉ thêm các chunk đã thay đổi.

Vì vậy, kích thước repository phụ thuộc vào tuổi của snapshot cũ nhất, không phụ thuộc vào số lượng snapshot. Giả sử có 500 GB dữ liệu và mỗi ngày phát sinh 5 GB dữ liệu duy nhất mới. Repository sẽ chứa 500 GB dữ liệu gốc, cộng khoảng 5 GB cho mỗi ngày tính ngược đến snapshot cũ nhất mà policy còn giữ.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Cột dollar tính chi phí repository ở mức 10 US dollars cho mỗi TB mỗi tháng. Đây chỉ là giá trị tạm để thực hiện phép tính, không phải báo giá của provider nào. Hãy thay bằng giá thực tế trên mỗi TB của plan bạn đang cân nhắc. Một tuần backup hằng ngày chứa khoảng 535 GB. Lưu lịch sử đủ một năm chứa 2,325 GB, tương đương $23.25 mỗi tháng, so với $5.35 cho một tuần. Lưu lịch sử có chi phí thấp. Phần bản sao dữ liệu gốc mới là phần bạn phải trả tiền.

Deduplication không giúp ích cho dữ liệu vốn đã được nén hoặc mã hóa. Một database dump đã gzip sẽ thay đổi hoàn toàn sau mỗi lần chạy. Vì vậy, mỗi dump được ghi thành các chunk mới và repository tăng thêm toàn bộ kích thước dump mỗi đêm. Hãy ghi dump ở dạng chưa nén và để công cụ backup nén nó. restic đã hỗ trợ repository được nén từ phiên bản 0.14, còn phiên bản 0.19 bổ sung các mode zstd fastest và better. Photo và video library cũng dedupe kém vì cùng lý do. Hãy tính dung lượng dựa trên tốc độ tăng trưởng thực tế của chúng, không dựa trên các dòng ở trên.

Ở đây, bạn đang mua disk nhàn rỗi thay vì CPU. Đây chính là trường hợp storage VPS phù hợp hơn regular VPS.

Vì sao bandwidth và thời gian restore quyết định phương án

Disk là phần rẻ. Lần upload đầu tiên và lần restore khi cần mới tốn thời gian. 500 GB tương đương 4 nghìn tỷ bit, nên chia cho tốc độ đường truyền sẽ cho thời gian tối thiểu để restore toàn bộ.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Đây là các con số theo tốc độ đường truyền, chưa tính overhead của protocol, nên hãy xem là trường hợp lý tưởng. Ở 100 Mbit/s, một lần restore đầy đủ cần 11.1 giờ trước khi có thể thao tác với dữ liệu. Với tốc độ upload tại nhà là 40 Mbit/s, cần 27.8 giờ. Trên một port 1 Gbit/s, lần restore tương tự cần 1.1 giờ. Nhiều file nhỏ thường chạy chậm hơn phép tính lý thuyết, vì overhead trên từng file chiếm ưu thế khi file nhỏ hơn vài trăm kilobyte.

Có 2 hệ quả. Nếu recovery time objective (RTO) của bạn, tức thời gian gián đoạn tối đa có thể chấp nhận, là 4 giờ, thì restore 500 GB qua đường truyền 100 Mbit/s đã không đạt mục tiêu này, và dùng disk rẻ hơn cũng không giúp được. Ngoài ra, hầu hết gói VPS đều tính phí hoặc giới hạn outbound transfer, nên một lần restore đầy đủ sẽ tiêu tốn 0.5 TB trong hạn mức hàng tháng của backup host. Hãy kiểm tra hạn mức đó và kiểm tra provider xử lý thế nào khi bạn vượt hạn mức, trước khi cần đến dữ liệu.

Backup đầu tiên chứa toàn bộ dataset và là lần chạy chậm nhất bạn từng thực hiện. Hãy bắt đầu vào thứ Sáu và giới hạn tốc độ để không làm bão hòa uplink của nguồn: restic nhận --limit-upload theo KiB mỗi giây, còn rsync nhận --bwlimit.

Mô hình 1: Proxmox Backup Server làm datastore từ xa

PBS phù hợp khi nguồn là Proxmox VE và đơn vị cần restore là một virtual machine. VPS không thể boot Proxmox ISO, vì vậy hãy cài PBS trên Debian. Version 4.2 là bản hiện tại tính đến tháng 8 năm 2026 và được xây dựng trên Debian 13 (trixie).

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

Đối chiếu checksum đó với giá trị được công bố trên trang repository package của Proxmox. Một apt repository chỉ đáng tin cậy ngang với key mà bạn đã xác minh. Sau đó ghi /etc/apt/sources.list.d/proxmox.sources:

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
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Cấp cho datastore một filesystem riêng hoặc một volume riêng. Datastore đầy sẽ dừng backup, còn datastore dùng chung root filesystem sẽ làm toàn bộ server dừng hoạt động khi hết dung lượng.

Tiếp theo, tạo account mà nguồn sẽ sử dụng và cấp cho account đó một token thay vì password.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Token secret chỉ được in ra một lần và không thể đọc lại, vì vậy hãy lưu nó ngay khi xuất hiện. Role quan trọng không kém token. DatastoreBackup có thể tạo và restore các backup của chính nó, đồng thời không có privilege Datastore.Prune, nên token đó không thể xóa snapshot mà nó đã ghi.

Retention trên PBS gồm 2 phần, và phần thứ hai thường bị bỏ qua. Prune xóa snapshot. Garbage collection xóa các chunk không còn được snapshot nào còn tồn tại tham chiếu. Dung lượng trống xuất hiện sau garbage collection, không phải sau prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Chạy --dry-run sau khi danh sách snapshot mà lệnh dự định xóa trông đúng. Garbage collection chạy qua 2 giai đoạn: cập nhật access time của mọi chunk vẫn còn được tham chiếu, sau đó xóa các chunk có access time cũ hơn thời điểm cutoff, tức là 24 giờ và 5 phút trước khi lần chạy bắt đầu. Khoảng thời gian chờ này ngăn một chunk đang được backup ghi dở bị xóa khi tiến trình vẫn đang sử dụng nó. Lên lịch chạy prune hằng ngày và garbage collection hằng tuần trên datastore, đồng thời thêm một verify job để target đọc lại các chunk của chính nó và phát hiện corruption trên disk trước khi restore.

Nếu nguồn cũng là một PBS instance, máy off-site có thể chủ động pull dữ liệu thay vì nhận dữ liệu được push đến.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Chạy sync job đó trên VPS theo hướng pull mặc định. VPS truy cập vào datastore tại nhà, nên máy ở nhà không giữ credential nào có thể tác động đến bản sao off-site.

Dạng 2: repository restic qua SSH hoặc S3

Debian và Ubuntu đều có package restic, nhưng thường chậm hơn upstream. Tính đến tháng 8 năm 2026, phiên bản hiện tại là 0.19.1. Hãy cài binary chính thức trên host nguồn.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version in phiên bản và trình biên dịch Go dùng để build binary đó. Các lần nâng cấp sau này dùng sudo restic self-update. Lệnh này hoạt động với binary chính thức, không hoạt động với bản cài từ apt.

Trên backup VPS, hãy tạo một account không sở hữu tài nguyên nào khác, rồi chép public key của host nguồn vào /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Khởi tạo repository từ host nguồn qua SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Lưu password ở một nơi không phải server này và cũng không phải backup target. Nếu mất password, repository sẽ không thể đọc được và hoàn toàn không có cách khôi phục. Đó là cái giá của client-side encryption.

Thiết lập retention chỉ cần một lệnh. Phần thứ hai của lệnh là phần giải phóng disk.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget xóa snapshot. prune xóa các pack file chỉ được những snapshot đó tham chiếu, còn --prune tự động chạy thao tác này khi thực sự có dữ liệu bị xóa. Nếu thiếu --prune, repository sẽ không bao giờ thu nhỏ. restic check kiểm tra cấu trúc repository, còn --read-data-subset=10% đọc lại và tính lại hash của một phần mười số pack file. Việc này phát hiện corruption trên target mà không phải đọc toàn bộ repository. Dạng còn lại, --read-data-subset=1/10, kiểm tra một phần mười cố định. Vì vậy, mỗi tuần tăng số đầu tiên lên 1 sẽ kiểm tra toàn bộ repository trong 10 tuần.

Nếu một lần chạy bị kill, lần chạy tiếp theo sẽ dừng với repository is already locked exclusively by PID. Hãy xác nhận hiện không có backup nào đang chạy, rồi xóa trạng thái này bằng restic unlock.

Với object storage, chuỗi repository trở thành s3:https://s3.example.net/web1, còn credential nằm trong AWS_ACCESS_KEY_ID và AWS_SECRET_ACCESS_KEY. Mọi thứ khác giữ nguyên. Đây là cách restic kết nối đến object store MinIO tự host chạy trên cùng VPS.

Hình thức 3: rsync qua SSH với key chỉ dùng để pull

Đặc tính bảo mật của hình thức này là hướng kết nối. Backup VPS kết nối đến máy nguồn và chỉ đọc dữ liệu. Máy nguồn không giữ key và cũng không có route đến backup host, nên nếu máy nguồn bị breach thì kẻ tấn công hoàn toàn không thể truy cập các bản backup.

Tạo một cặp key trên backup VPS, rồi cài public key lên máy nguồn bằng forced command.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync được đóng gói trong rsync tại /usr/bin/rrsync trên Debian 13 và Ubuntu 24.04. -ro chỉ cho phép đọc và bao hàm -no-del, nên key này không thể ghi vào máy nguồn hoặc xóa bất kỳ dữ liệu nào trên đó. restrict tắt các tính năng SSH không cần thiết ở đây, gồm port forwarding và pty, nên key không thể được dùng để đăng nhập tương tác. Sau đó, các path được tính tương đối so với thư mục bạn đã chỉ định, vì vậy remote path / tương ứng với /srv trên máy nguồn.

Quá trình pull giữ lại lịch sử bằng hardlink. Các file không thay đổi trong tree mới là hardlink trỏ đến tree trước đó, nên chỉ tốn thêm một directory entry thay vì một bản sao thứ hai.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

Lệnh rename ở cuối là yếu tố giúp một directory có ngày tháng trở nên đáng tin cậy: tên chỉ xuất hiện sau khi rsync thoát với mã 0, vì vậy một lần truyền bị gián đoạn sẽ không bị hiểu nhầm là snapshot đã hoàn tất. Xóa các tree cũ bằng một dòng lệnh và giữ lại 30 tree.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Cần nói rõ chi phí của hình thức này. Hardlink chỉ loại bỏ bản sao ở cấp độ toàn bộ file, nên nếu thay đổi một byte trong disk image 4 GB thì toàn bộ 4 GB sẽ được sao chép. Trong trường hợp đó, restic và PBS chỉ lưu một vài chunk đã thay đổi. Target cũng lưu các file của bạn dưới dạng plaintext, nên bất kỳ ai có root trên backup VPS đều có thể đọc chúng.

Mã hóa phía client, để target không bao giờ thấy plaintext

Hãy xem backup VPS là một máy bạn không hoàn toàn kiểm soát. Máy này do một nhà cung cấp vận hành, và nhà cung cấp đó có nhân viên cũng như các ổ đĩa hỏng được đưa ra khỏi tòa nhà.

restic mã hóa từng chunk trên máy nguồn trước khi gửi đi. Vì vậy, repository chỉ chứa ciphertext cùng metadata về kích thước và thời điểm. PBS yêu cầu bật mã hóa một cách rõ ràng: tạo một key, sau đó truyền key đó trong mỗi lần backup.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Hãy in key trên giấy và cất ở một nơi thực tế an toàn. Tài liệu Proxmox nói rõ mức độ quan trọng: không có key tương ứng, các file đã backup sẽ không thể truy cập. Không lưu key trên target backup, vì key nằm cạnh ciphertext thì không bảo vệ được gì.

rsync mirror không có cơ chế tương đương. Các file được ghi xuống dưới dạng file. Nếu dữ liệu nhạy cảm, bạn phải chấp nhận target có thể đọc dữ liệu đó hoặc dùng một trong hai mô hình còn lại.

Ngăn source bị xâm nhập xóa các bản backup của chính nó

Kẻ tấn công chiếm được source sẽ tiếp tục tìm các bản backup, và credential dùng để upload chúng đang nằm ngay trên máy đó. Nếu credential này cũng có quyền xóa, kẻ tấn công sẽ sử dụng nó.

PBS giải quyết việc này bằng role. Token chỉ có DatastoreBackup có thể ghi snapshot mới và restore snapshot của chính nó, nhưng không thể prune, vì xóa snapshot cần privilege Datastore.Prune riêng. Chạy retention từ phía PBS để source không bao giờ giữ credential có thể xóa bất kỳ thứ gì.

restic qua SFTP không có cơ chế tách quyền như vậy, vì SSH key dùng để ghi vào repository cũng có thể xóa dữ liệu trong đó. Cách khắc phục là dùng REST backend. Chạy rest-server trên backup VPS với --append-only. Tùy chọn này cho phép tạo backup mới nhưng chặn việc xóa và sửa các backup hiện có. Sau đó trỏ client đến rest:https://backup.example.net:8000/web1 bằng RESTIC_REST_USERNAME và RESTIC_REST_PASSWORD. Khi đó lệnh restic forget --prune từ source sẽ fail. Đây là kết quả mong muốn, vì retention sẽ chạy từ một máy thứ hai với credential riêng. Manual của restic cũng khuyến nghị --keep-within thay cho policy dựa trên số lượng trên các repository append-only, vì nếu không, kẻ tấn công có thể tạo nhiều snapshot rác để đẩy các snapshot thật của bạn ra ngoài cửa sổ --keep-last.

rsync giải quyết cùng vấn đề này về mặt kiến trúc bằng cơ chế pull, vì source không giữ credential để truy cập target.

Một nguyên tắc áp dụng cho cả ba mô hình: credential có quyền xóa backup phải nằm trên một máy khác với máy được backup.

Đưa bài kiểm tra khôi phục vào lịch

Một bản backup chưa từng được khôi phục chỉ là giả định. Hãy đặt lịch một giờ mỗi quý và kiểm tra nó.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r không in gì nghĩa là cây thư mục đã khôi phục khớp với cây thư mục đang hoạt động. Trên PBS, bài kiểm tra tương tự là proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, kèm theo một verify job đã lập lịch để đọc lại các chunk trên đích và báo lỗi checksum.

Bài kiểm tra phải chứng minh nhiều hơn việc các byte còn nguyên vẹn.

• Khôi phục từ máy thứ ba, không khôi phục từ máy nguồn, vì máy nguồn chính là thứ bạn đang giả định đã mất. Điều đó có nghĩa là repository password hoặc PBS key phải có thể truy cập mà không cần máy nguồn.
• Đo thời gian khôi phục và ghi lại con số đó, sau đó so sánh với RTO bạn đã cam kết. Biểu đồ ở trên cho biết thời gian truyền tối thiểu. Con số thực tế còn bao gồm thời gian giải mã và ghi vào disk, cùng thời gian xác định snapshot cần dùng.
• Khôi phục dữ liệu có state, chẳng hạn database dump rồi load vào một scratch instance. Một file tar giải nén được không chứng minh application có thể khởi động.

Disk rẻ nhất thế giới cũng không có giá trị cho đến khi bạn khôi phục từ đó ít nhất một lần.

FAQ

Snapshot tại nhà cung cấp VPS có phải là bản sao lưu ngoại vi không?

Không. Snapshot của nhà cung cấp nằm trong cùng account, phía sau cùng thông tin đăng nhập vào panel và trên cùng hóa đơn với server được sao chép. Ai lấy được thông tin đăng nhập đó đều có thể xóa server và mọi snapshot của server trong cùng một phiên. Snapshot hữu ích để rollback nhanh trước một lần nâng cấp có rủi ro, nhưng không phải là bản sao ở vị trí thứ hai. Bản sao ngoại vi nằm dưới một account khác, lý tưởng nhất là tại một nhà cung cấp khác, với thông tin xác thực mà máy nguồn không giữ.

Tôi cần bao nhiêu dung lượng đĩa cho các bản sao lưu được giữ trong một tháng?

Hãy tính theo tuổi của snapshot cũ nhất thay vì số lượng snapshot. Công cụ deduplication chỉ lưu mỗi chunk duy nhất một lần, nên repository có kích thước xấp xỉ dữ liệu nguồn cộng với lượng dữ liệu mới duy nhất mỗi ngày nhân với số ngày lưu giữ. Với 500 GB dữ liệu thay đổi 5 GB mỗi ngày, một tuần bản sao lưu hằng ngày chiếm khoảng 535 GB và toàn bộ lịch sử trong một năm chiếm 2,325 GB. Hãy chừa thêm dung lượng dự phòng, vì đầy đĩa sẽ khiến lần sao lưu tiếp theo thất bại, còn prune của restic cần dung lượng trống để đóng gói lại các pack file trước khi trả lại dung lượng.

Server bị breach có thể tự xóa các bản sao lưu ngoại vi không?

Có, trừ khi bạn thiết kế hệ thống để ngăn việc đó. Với repository SSH hoặc SFTP thông thường, key có quyền ghi cũng có thể xóa. Hãy cấp cho máy nguồn một thông tin xác thực không thể xóa dữ liệu: PBS API token chỉ có role DatastoreBackup, không có privilege Datastore.Prune, hoặc restic kết nối đến rest-server được khởi động với --append-only, chế độ từ chối xóa và sửa các bản sao lưu hiện có. Thiết kế pull còn an toàn hơn, vì máy nguồn hoàn toàn không giữ thông tin xác thực của backup host. Chạy chính sách retention từ phía không phải máy nguồn.

Tôi nên chạy Proxmox Backup Server hay restic trên backup VPS?

Hãy chọn công cụ theo đơn vị cần restore. Nếu nguồn là Proxmox VE và bạn muốn khôi phục toàn bộ virtual machine, hãy chạy PBS, vì PBS sao lưu ở cấp disk image và restore VM trong một bước. Nếu nguồn là Linux host và bạn muốn khôi phục file cùng database dump, hãy chạy restic. Công cụ này chỉ cần một SSH account trên máy đích và mã hóa dữ liệu trước khi gửi. Chạy cả hai là cách làm bình thường: dùng PBS cho hypervisor và restic cho các server không chạy trên hypervisor đó.

Restore từ bản sao lưu VPS mất bao lâu?

Chia kích thước dữ liệu cho tốc độ đường truyền để tính thời gian tối thiểu, sau đó cộng thêm thời gian giải mã và ghi dữ liệu. 500 GB qua đường truyền 100 Mbit/s mất 11.1 giờ ở tốc độ tối đa của đường truyền; cùng bản restore đó qua cổng 1 Gbit/s mất 1.1 giờ. Nhiều file nhỏ thường chạy chậm hơn phép tính này do overhead trên từng file. Hãy đo thời gian của một lần restore thực tế và dùng con số đã đo, vì đó là con số duy nhất mà kế hoạch khôi phục của bạn có thể dựa vào.