โดย Matt Connor 2026-08-15

วิธีติดตั้ง Proxmox Backup Server บน VPS เพื่อสำรองข้อมูล

เรียนรู้วิธีตั้งค่า Proxmox Backup Server บน VPS สำหรับเก็บข้อมูลนอกสถานที่ ครอบคลุมการสร้าง Datastore การจัดการ Namespaces การทำ Garbage Collection และการทดสอบกู้คืนข้อมูลจริง

สิ่งที่ Proxmox Backup Server บน VPS มอบให้คุณจริงๆ

Proxmox Backup Server (PBS) บน VPS คือปลายทางสำรองข้อมูลนอกสถานที่ที่ใช้โปรโตคอลเดียวกับที่คลัสเตอร์ Proxmox VE (virtual environment) ของคุณใช้งานอยู่ ดังนั้นการสำรองข้อมูลทุกครั้งหลังจากครั้งแรกจะเป็นแบบ incremental, มีการทำ deduplication ข้าม guest, ถูกเข้ารหัสก่อนออกจากอาคารของคุณ และสามารถตรวจสอบความถูกต้องได้ในภายหลัง คุณเพียงเช่า VPS พร้อม block volume, ติดตั้ง PBS บน Debian 13, สร้าง datastore หนึ่งรายการบน volume นั้น และเพิ่มเข้าไปใน Proxmox VE ในฐานะ storage ประเภท pbs การติดตั้งใช้เวลาเพียงสิบนาที สิ่งที่ตามมาหลังจากนั้น ไม่ว่าจะเป็น namespaces, garbage collection, การเก็บรักษา key และการกู้คืนข้อมูลที่คุณได้ทดสอบจริง คือสิ่งที่ตัดสินว่าการสำรองข้อมูลนั้นจะมีค่าหรือไม่ในอีกหนึ่งปีข้างหน้า

เหตุผลที่ควรใช้ PBS แทนการคัดลอกไฟล์ vzdump ไปยังดิสก์ที่เช่ามาคือระบบ chunk store ตัว client จะแบ่งดิสก์ของ guest แต่ละตัวออกเป็น chunk ขนาดประมาณ 4 MiB, ทำการ hash ข้อมูล และอัปโหลดเฉพาะ chunk ที่ datastore ยังไม่มีเท่านั้น สำหรับ virtual machine ที่กำลังทำงานอยู่ QEMU จะติดตามบล็อกที่มีการเปลี่ยนแปลงใน dirty bitmap หลังจากทำการสำรองข้อมูลครั้งแรก ดังนั้นการทำงานครั้งถัดไปจะอ่านเฉพาะบล็อกเหล่านั้นจากดิสก์ภายในเครื่อง guest ขนาด 200 GB ที่มีการเปลี่ยนแปลง 3 GB ต่อวัน จะส่งข้อมูลจริงเพียงประมาณ 3 GB ต่อวันเท่านั้น นี่คือสิ่งที่ทำให้การเชื่อมต่ออินเทอร์เน็ตที่บ้านและ volume ที่เช่ามาทำงานร่วมกันได้ และเป็นเหตุผลว่าทำไม การใช้ VPS เป็นปลายทางสำรองข้อมูลนอกสถานที่ จึงเหนือกว่าการใช้ไดรฟ์สำรองที่บ้านเพื่อน หากคุณยังตัดสินใจไม่ได้ว่าตัว hypervisor ควรจะอยู่ที่ไหน Proxmox ที่บ้านเทียบกับการเช่า VPS ได้ครอบคลุมคำถามนั้นไว้แยกต่างหากแล้ว

การคำนวณขนาดพื้นที่จัดเก็บก่อนเช่าใช้งาน

การคำนวณขนาดพื้นที่คือการคำนวณทางคณิตศาสตร์ที่คุณต้องทำด้วยตัวเลขของคุณเอง ให้ใช้พื้นที่ที่ guest แต่ละตัวใช้งานจริง ไม่ใช่ขนาดของ virtual disk จากนั้นบวกด้วยปริมาณข้อมูลที่เปลี่ยนแปลงต่อวันคูณด้วยจำนวนวันที่คุณต้องการเก็บรักษา การบีบอัดข้อมูล (compression) และการขจัดข้อมูลซ้ำซ้อน (deduplication) จะช่วยให้ตัวเลขนี้ดีขึ้น ดังนั้นให้ถือว่าผลลัพธ์ที่ได้เป็นเพดานสูงสุดไม่ใช่เป้าหมายที่ต้องทำให้ถึง

ChartWorked sizing example: three guests, thirty daily snapshots kept

label

used_gb

daily_change_gb

store_gb

web VM

0.8

mail VM

120

3.0

210

file server container

300

1.5

345

The data behind this chart

[
  {
    "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
  }
]

แถวเหล่านั้นเป็นเพียงตัวอย่างการคำนวณ ไม่ใช่การวัดค่าจริง ให้ตรวจสอบพื้นที่ที่ใช้งานจาก df -h ภายใน guest แต่ละตัว และตรวจสอบการเปลี่ยนแปลงรายวันจากขนาดของ backup ครั้งที่สองและสามใน log ของงาน PBS เมื่อมีข้อมูลดังกล่าวแล้ว

ตัวอย่าง guest ที่เป็น mail server ใช้งานพื้นที่ 120 GB และมีการเปลี่ยนแปลงประมาณ 3.0 GB ต่อวัน ดังนั้นการเก็บ snapshot รายวันจำนวน 30 วันจะต้องการพื้นที่ประมาณ 210 GB ซึ่งประกอบด้วยข้อมูลฉบับเต็มหนึ่งชุดบวกกับข้อมูลที่เปลี่ยนแปลงใน 30 วัน ให้รวมค่าในคอลัมน์สุดท้ายของ guest ทั้งหมด 3 ตัว จะได้ผลรวมประมาณ 619 GB จากนั้นให้บวกเพิ่มอีกหนึ่งในห้าสำหรับดัชนี, ข้อมูล metadata และพื้นที่ว่างที่จำเป็นสำหรับการทำงานของ garbage collection ซึ่งจะทำให้ได้ขนาด volume ที่เหมาะสมคือ 1 TB

ส่วนประกอบที่เหลือของแผนการนี้มีขนาดเล็ก PBS สามารถทำงานได้ดีด้วย RAM ขนาด 2 GB และทำงานได้อย่างสบายที่ 4 GB เนื่องจากงานหนักจะเกิดขึ้นที่ฝั่ง cluster: โหนด Proxmox VE จะเป็นผู้ทำหน้าที่อ่าน disk ของ guest และดำเนินการแบ่งส่วนข้อมูล (chunking) รวมถึงการทำ hashing สิ่งที่ VPS ทำคือการเขียน chunk และรันงานหนักสองอย่าง ได้แก่ garbage collection และการตรวจสอบความถูกต้อง (verification) ควรเช่า datastore เป็น block volume แยกต่างหากแทนที่จะใช้ root disk ขนาดใหญ่เพียงลูกเดียว เพราะคุณสามารถขยายขนาด volume ในภายหลังได้โดยไม่ต้องสร้างเซิร์ฟเวอร์ใหม่

การติดตั้ง Proxmox Backup Server บน Debian 13

ณ เดือนสิงหาคม 2026 รุ่นที่ใช้งานร่วมกันในปัจจุบันคือ Proxmox Backup Server 4 บน Debian 13 ซึ่งมีชื่อรหัสว่า trixie คู่มือรุ่นเก่าจะจับคู่ PBS 2 กับ Debian 11 และชื่อรหัสเป็นส่วนหนึ่งของคำจำกัดความ repository ดังนั้นการคัดลอกชื่อ suite รุ่นเก่าจะทำให้เกิดข้อผิดพลาด apt เกี่ยวกับไฟล์ release ที่หายไป ให้เริ่มต้นจากอิมเมจ Debian 13 แบบมาตรฐาน ดำเนินการทุกขั้นตอนด้านล่างในฐานะ root หรือใช้ sudo ตามที่ระบุไว้

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

ผลรวมต้องอ่านได้เป็น 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 หากไม่ตรงกันให้หยุดทันที การใช้ keyring ที่ผิดหมายความว่าคุณกำลังจะติดตั้งแพ็กเกจที่ลงนามโดยสิ่งที่ไม่ได้ตรวจสอบ

เขียน /etc/apt/sources.list.d/pbs.sources ด้วย repository แบบ no-subscription ซึ่งเป็นตัวเลือกที่เหมาะสมสำหรับเซิร์ฟเวอร์ที่ไม่มีสัญญาบริการสนับสนุน:

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

อินเทอร์เฟซเว็บจะตอบสนองผ่าน HTTPS พอร์ต 8007 ให้เข้าสู่ระบบด้วย root@pam โดยใช้รหัสผ่าน root ของระบบ เนื่องจาก PBS ตรวจสอบสิทธิ์ผู้ใช้รายนั้นเทียบกับ PAM (pluggable authentication modules) ซึ่งเป็นบัญชีเดียวกับที่ระบบปฏิบัติการใช้งาน ใบรับรองเป็นแบบ self-signed และเบราว์เซอร์ของคุณจะแจ้งเตือนเรื่องนี้ ลายนิ้วมือของใบรับรองนั้นคือค่าที่ Proxmox VE จะใช้ระบุตัวตนในภายหลัง ดังนั้นคำเตือนนี้ถือเป็นเรื่องปกติไม่ใช่ปัญหาที่ต้องแก้ไข

พอร์ต 8007 เป็นแบบฟอร์มเข้าสู่ระบบบนอินเทอร์เน็ตสาธารณะ ดังนั้นอย่าเปิดทิ้งไว้ให้ทุกคนเข้าถึงได้ ไฟล์ nftables หนึ่งไฟล์สามารถจัดการเรื่องนี้ได้ การเขียน /etc/nftables.conf จะเป็นการ ล้าง กฎที่มีอยู่ทั้งหมด ดังนั้นให้ข้ามขั้นตอนนี้หากมีระบบอื่นจัดการไฟร์วอลล์บนเครื่องนี้อยู่แล้ว

#!/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
  }
}

ใช้กฎด้วย sudo systemctl enable --now nftables และควรเปิด SSH session ที่สองทิ้งไว้ในขณะที่ดำเนินการ: policy drop รวมกับการพิมพ์ผิดเพียงจุดเดียวในกฎ SSH จะทำให้คุณถูกล็อกออกจากเซิร์ฟเวอร์ของตัวเอง ให้แทนที่ 203.0.113.7 ด้วยที่อยู่ IP ที่คลัสเตอร์ของคุณใช้ติดต่อ หากที่อยู่นั้นเป็นแบบไดนามิก ให้ขยายขอบเขตของกฎให้ครอบคลุมช่วง IP ของผู้ให้บริการของคุณ หรือยุติการเชื่อมต่อผ่าน tunnel และโปรดจำไว้ว่าแผงควบคุม VPS ส่วนใหญ่จะมีไฟร์วอลล์เครือข่ายแยกต่างหากที่อยู่หน้าเครื่อง ซึ่งต้องอนุญาตพอร์ตเดียวกันนี้ด้วย

แยก Datastore ไปไว้บน Volume ของตัวเอง

ห้ามเก็บ Datastore ไว้บน Root Filesystem หาก Datastore เต็มจนกินพื้นที่ Root Filesystem ที่ใช้ร่วมกัน จะส่งผลให้การสำรองข้อมูลล้มเหลวและบริการทุกอย่างบนเครื่องหยุดทำงาน รวมถึง Logging ที่คุณจำเป็นต้องใช้เพื่อหาสาเหตุด้วย ให้ทำการเชื่อมต่อ Block Volume, ฟอร์แมต, Mount และสร้าง Datastore ไว้ภายในจุด Mount นั้นเท่านั้น

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

ให้ใช้ชื่ออุปกรณ์จาก lsblk โดยปกติจะเป็น /dev/vdb ใน KVM Image ส่วนใหญ่ และเป็น /dev/sdb ใน Image อื่นๆ ซึ่งไม่ควรคาดเดาชื่ออุปกรณ์โดยเด็ดขาด ให้เพิ่มการ Mount ลงใน /etc/fstab โดยใช้ Label เพื่อป้องกันไม่ให้ Datastore ชี้ไปยังดิสก์ผิดลูกหากชื่ออุปกรณ์เปลี่ยนไปหลังการ Reboot:

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 ควรแสดงผลอุปกรณ์, Path และตัวเลือกต่างๆ รวมถึง rw,relatime ในบรรทัดนั้นมีความผิดพลาดซ่อนอยู่ 2 ประการ หากจุด Mount ยังไม่พร้อมใช้งานแล้วคุณสร้าง Datastore ไปก่อน PBS จะเขียนข้อมูลลงใน Root Filesystem ที่อยู่ใต้จุด Mount นั้น และเมื่อ Mount สำเร็จในภายหลัง ข้อมูลดังกล่าวจะถูกซ่อนไว้โดยไม่ถูกลบ ทำให้ Datastore ดูเหมือนว่างเปล่าในขณะที่ Root Filesystem ยังคงเต็มอยู่ หากตัวเลือกกำหนดเป็น noatime ตัว PBS จะปฏิเสธการทำงาน เนื่องจากมีการตรวจสอบความปลอดภัยของ Access Time ในขณะสร้าง Datastore และทุกครั้งที่มีการทำ Garbage Collection

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

คำสั่งดังกล่าวจะสร้างไดเรกทอรี .chunks ซึ่งบรรจุไดเรกทอรีย่อย 65536 แห่ง ตั้งแต่ 0000 ถึง ffff Datastore ประกอบด้วยไฟล์ขนาดเล็กจำนวนหลายแสนไฟล์ ไม่ใช่ไฟล์ขนาดใหญ่เพียงไม่กี่ไฟล์ ซึ่งนำไปสู่ข้อสรุป 2 ประการคือ การคัดลอก Datastore ด้วยเครื่องมือจัดการไฟล์ทั่วไปนั้นช้าจนใช้งานไม่ได้ และการทำ Snapshot ของ Volume จากผู้ให้บริการในขณะที่กำลังสำรองข้อมูลอยู่ จะไม่ได้สำเนาที่สอดคล้องกัน (Consistent Copy) ซึ่งเป็นเหตุผลเดียวกับที่ Snapshot ไม่สามารถทดแทนการสำรองข้อมูลได้ ในทุกกรณี

Namespaces ช่วยป้องกันไม่ให้ข้อมูลจากสองโฮสต์ทับซ้อนกัน

โดยปกติแล้ว datastore จะมีโครงสร้างแบบแบน ข้อมูลสำรองจะมีชื่อเป็น vm/100, ct/101 และ host/<name> หากมีสองคลัสเตอร์ที่ต่างก็มี guest ID 100 เขียนข้อมูลลงในกลุ่มเดียวกัน snapshot ของทั้งสองจะปะปนกัน และกฎการเก็บรักษาที่ตั้งไว้สำหรับชุดหนึ่งจะไปนับรวม snapshot ของอีกชุดหนึ่งด้วย Namespaces จะช่วยแยกพื้นที่ของแต่ละแหล่งข้อมูลให้เป็นโครงสร้างต้นไม้ของตัวเองภายใน datastore เดียวกัน

ให้สร้าง Namespaces บนโฮสต์ PBS โดยอาร์กิวเมนต์ --repository จะอยู่ในรูปแบบ [[auth-id@]server[:port]:]datastore ดังนั้นหากเป็น namespace ในเครื่องจะใช้รูปแบบ root@pam@localhost:store1 และคำสั่งจะเรียกขอรหัสผ่าน root

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 จะไม่ได้รับผลกระทบจากการแยกนี้ ข้อมูลส่วนย่อย (chunks) จะถูกแชร์ร่วมกันทั้ง datastore ดังนั้นแม้จะมี guest ระบบ Debian 10 รายการกระจายอยู่ใน 3 namespaces ข้อมูลพื้นฐานของระบบก็จะถูกจัดเก็บเพียงชุดเดียว นี่คือเหตุผลที่ควรใช้ datastore เดียวร่วมกับ namespaces แทนการแยก datastore ต่อโฮสต์ เพราะการแยก datastore หมายถึงการแยก chunk pool ซึ่งจะทำให้ต้องเสียพื้นที่จัดเก็บข้อมูล Debian ชุดเดียวกันซ้ำหลายครั้ง

กำหนดบัญชีผู้ใช้แยกสำหรับแต่ละแหล่งข้อมูล โดยจำกัดขอบเขตไว้เฉพาะ namespace ของตนเอง API (application programming interface) token คือข้อมูลรับรองที่ผูกกับผู้ใช้และมีสิทธิ์การเข้าถึงเฉพาะตัว ซึ่งเป็นสิ่งที่จำเป็นสำหรับเครื่องที่อาจถูกขโมยได้

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'

คำสั่งสร้าง token จะแสดงค่า secret ออกมาเพียงครั้งเดียวเท่านั้น:

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

ให้คัดลอกค่านี้ไว้ทันที เพราะ PBS จะไม่เก็บข้อมูลส่วนนี้ในรูปแบบที่สามารถแสดงให้คุณดูได้อีก ตรวจสอบคำสั่งควบคุมการเข้าถึงให้ถี่ถ้วน คำสั่งจะระบุชื่อ token คือ backup@pbs!pve-home ไม่ใช่ชื่อผู้ใช้ เพราะสิทธิ์ของ token จะคำนวณจากรายการที่ระบุชื่อ token นั้นโดยตรงเท่านั้น หากระบุเพียง backup@pbs จะทำให้ token ไม่มีสิทธิ์เข้าถึงใดๆ เลย และการสำรองข้อมูลครั้งแรกจะล้มเหลวด้วยปัญหาเรื่องสิทธิ์ แทนที่จะเป็นปัญหาที่มองเห็นได้ในเครือข่าย นอกจากนี้ path ยังมีความสำคัญมาก: token ที่ถูกจำกัดขอบเขตไว้ที่ /datastore/store1/pve-home จะไม่สามารถอ่านหรือลบข้อมูลใดๆ ใน namespace ของสำนักงานได้ ดังนั้นหากคลัสเตอร์หนึ่งถูกบุกรุก ก็จะไม่สามารถทำลายประวัติการสำรองข้อมูลของไซต์อื่นได้

การเพิ่ม VPS เป็นพื้นที่จัดเก็บข้อมูลสำรองใน Proxmox VE

ขั้นแรกให้ตรวจสอบ fingerprint ของใบรับรองบนโฮสต์ PBS

sudo proxmox-backup-manager cert info | grep Fingerprint

จากนั้นบนโหนดใดก็ได้ในคลัสเตอร์:

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

ให้วางค่า cert info ที่แสดงผลแทนที่ตัวยึดตำแหน่งในบรรทัดที่สาม การส่งค่า --password โดยไม่ระบุค่าจะทำให้ pvesm แจ้งให้คุณกรอกข้อมูล เพื่อป้องกันไม่ให้ token secret ถูกบันทึกไว้ในประวัติการใช้งาน shell ของคุณ ข้อมูลนี้จะถูกจัดเก็บไว้ที่ /etc/pve/priv/storage/pbs-offsite.pw และการตั้งค่า storage จะถูกบันทึกไว้ใน /etc/pve/storage.cfg ซึ่งจะถูกทำสำเนาไปยังทุกโหนดในคลัสเตอร์ ดังนั้นคุณจึงตั้งค่าเพียงครั้งเดียวสำหรับทั้งคลัสเตอร์

--prune-backups keep-all=1 เป็นการสั่งให้ Proxmox VE ไม่ต้องลบข้อมูลใดๆ การกำหนดนโยบายการเก็บรักษา (retention) ควรทำที่ฝั่ง PBS ซึ่งจะอธิบายในหัวข้อถัดไป โดยมีเหตุผลที่ชัดเจนคือ token จะไม่จำเป็นต้องได้รับสิทธิ์ในการลบข้อมูล ดังนั้นหากคลัสเตอร์ถูกโจมตีด้วย ransomware ก็จะไม่สามารถเข้าถึงและลบประวัติการสำรองข้อมูลนอกสถานที่ที่ใช้สำหรับกู้คืนระบบได้

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

pvesm status จะแสดงสถานะ active ในคอลัมน์สถานะ พร้อมกับพื้นที่ทั้งหมดและพื้นที่ที่ใช้งานของ datastore หากขึ้นสถานะ inactive หมายความว่าโหนดไม่สามารถสร้างเซสชัน TLS (transport layer security) ไปยังพอร์ต 8007 ได้ ซึ่งมักเกิดจากปัญหา firewall หรือ fingerprint ไม่ตรงกัน ไม่ใช่ปัญหาเรื่องข้อมูลรับรอง (credential)

การสำรองข้อมูลครั้งแรกจะอัปโหลดข้อมูลทั้งหมด ดังนั้นควรคำนวณปริมาณข้อมูลก่อนเริ่มดำเนินการ ข้อมูลขนาด 200 GB เท่ากับ 1600 gigabits หาก uplink มีความเร็ว 100 Mbit จะส่งข้อมูลได้ 0.1 gigabit ต่อวินาที ดังนั้นเวลาขั้นต่ำจะอยู่ที่ประมาณสี่ชั่วโมงครึ่งและในความเป็นจริงจะใช้เวลานานกว่านั้น ควรเริ่มการสำรองข้อมูลในช่วงเวลาที่คุณไม่จำเป็นต้องใช้แบนด์วิดท์ การสำรองข้อมูลในรอบถัดไปจะส่งเฉพาะส่วนของข้อมูลที่เปลี่ยนแปลงใหม่เท่านั้น

การเข้ารหัสฝั่งไคลเอนต์และตำแหน่งที่เก็บคีย์

VPS คือคอมพิวเตอร์ที่คุณไม่ได้เป็นเจ้าของ การเข้ารหัสที่ฝั่งไคลเอนต์จะทำให้ที่เก็บข้อมูลมีเพียงข้อมูลส่วนย่อยที่ผู้ให้บริการไม่สามารถอ่านได้

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

คำสั่งดังกล่าวจะเขียนคีย์ใหม่ลงใน /etc/pve/priv/storage/pbs-offsite.enc ซึ่งอ่านได้เฉพาะ root เท่านั้น และจะถูกสำเนาไปพร้อมกับส่วนที่เหลือของ /etc/pve นับตั้งแต่การสำรองข้อมูลครั้งถัดไป ไคลเอนต์จะเข้ารหัสข้อมูลแต่ละส่วนก่อนส่งออกไป เซิร์ฟเวอร์ยังคงสามารถแสดงรายการ snapshot และขนาดของไฟล์ได้ แต่ไม่สามารถอ่านเนื้อหาภายในได้

ส่วนนี้คือสิ่งที่ทำให้การสำรองข้อมูลของคุณปลอดภัยและไม่กลายเป็นภาระ คีย์ที่สร้างขึ้นจะไม่มีรหัสผ่านและมีอยู่เฉพาะในคลัสเตอร์ที่มันปกป้องเท่านั้น หากคลัสเตอร์นั้นถูกขโมยหรือถูกเข้ารหัสโดยผู้อื่น VPS จะถือครองข้อมูลที่ไม่มีใครสามารถเปิดได้ ดังนั้นให้คัดลอกคีย์ออกจากคลัสเตอร์ในวันที่คุณสร้างมันขึ้นมา

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 จะแสดงคีย์ออกมาในรูปแบบเอกสารที่ออกแบบมาเพื่อพิมพ์ลงบนกระดาษและเก็บไว้ในที่อื่น โปรดจัดการไฟล์นี้เสมือนเป็นความลับ เพราะใครก็ตามที่ถือครองไฟล์นี้จะสามารถถอดรหัสการสำรองข้อมูลทุกชุดที่สร้างด้วยคีย์ดังกล่าวได้ สำหรับการตั้งค่าขนาดใหญ่ PBS ยังรองรับ master key ซึ่งเป็นคู่กุญแจ RSA (Rivest Shamir Adleman) ที่สร้างด้วย proxmox-backup-client key create-master-key โดยการสำรองข้อมูลแต่ละชุดจะเก็บคีย์การเข้ารหัสของตัวเองที่ถูกเข้ารหัสด้วย public key ในขณะที่ private key จะถูกเก็บไว้แบบออฟไลน์เพื่อใช้ในการกู้คืน

ผลลัพธ์ประการหนึ่งของการออกแบบนี้เป็นสิ่งที่ควรทราบก่อนเริ่มใช้งานจริง สำหรับการสำรองข้อมูลแบบเข้ารหัส ค่า digest ของข้อมูลส่วนย่อยจะถูกคำนวณจากเนื้อหาที่เป็น plain text รวมกับคีย์การเข้ารหัส ดังนั้นข้อมูลส่วนย่อยที่เหมือนกันสองชุดหากถูกเข้ารหัสด้วยคีย์ที่ต่างกันจะให้ค่า digest ที่ต่างกันและไม่สามารถทำ deduplicate ต่อกันได้ การเปลี่ยนคีย์หมายความว่าการสำรองข้อมูลครั้งถัดไปจะต้องอัปโหลดข้อมูลทั้งหมดใหม่อีกครั้ง และข้อมูลส่วนย่อยเดิมจะยังคงค้างอยู่จนกว่า snapshot ของมันจะถูกลบและจัดเก็บใหม่ ดังนั้นควรตัดสินใจเรื่องการเข้ารหัสให้เรียบร้อยก่อนการอัปโหลดครั้งแรก

การลบข้อมูลสำรองและการเรียกคืนพื้นที่ด้วย Garbage Collection

ส่วนนี้คือส่วนที่มักถูกข้ามไป และเป็นสาเหตุที่ทำให้พื้นที่จัดเก็บข้อมูลเต็ม การลบข้อมูลสำรอง (Pruning) จะลบเพียง metadata เท่านั้น ได้แก่ manifest, index, log และบันทึกต่างๆ โดยจะไม่มีการลบ chunk ใดๆ ออกเลย เนื่องจาก chunk ถูกใช้งานร่วมกันระหว่าง snapshot ระบบจึงไม่สามารถทราบได้ว่า chunk ใดไม่ได้ถูกใช้งานแล้วจนกว่าจะมีการอ่าน index ที่เหลืออยู่ทั้งหมด ซึ่งงาน Garbage Collection คือกระบวนการที่ทำหน้าที่อ่านข้อมูลเหล่านั้น ดังนั้น datastore ที่มีการตั้งตารางเวลา Pruning แต่ไม่มีการตั้งตารางเวลา Garbage Collection จะมีขนาดเพิ่มขึ้นเรื่อยๆ อย่างต่อเนื่อง

ให้ตั้งค่าทั้งสองอย่าง โดยเริ่มจากนโยบายการเก็บรักษา (Retention) ซึ่งกำหนดงานหนึ่งรายการต่อหนึ่ง namespace:

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

จากนั้นจึงตั้งตารางเวลาการเรียกคืนพื้นที่ (Collection schedule) บน datastore โดยให้ห่างจากงาน Pruning สองสามชั่วโมงและอยู่นอกช่วงเวลาการสำรองข้อมูล:

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

พิสูจน์การแยกส่วนการทำงานนี้ด้วยตนเองบนโฮสต์ PBS:

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

ให้รันงาน Pruning แล้วตามด้วย df คุณจะพบว่าตัวเลขพื้นที่ที่ใช้งานอยู่ไม่มีการเปลี่ยนแปลง จากนั้นให้รัน Garbage Collection แล้วตามด้วย df อีกครั้ง คุณจะเห็นว่าตัวเลขมีการเปลี่ยนแปลง

กระบวนการ Garbage Collection ทำงานสองขั้นตอน ขั้นตอนแรกคือการไล่ตรวจสอบ index ทุกรายการใน datastore และอัปเดตเวลาการเข้าถึง (access time) ของทุก chunk ที่ index เหล่านั้นอ้างอิงถึง ขั้นตอนที่สองคือการลบ chunk ที่มีเวลาการเข้าถึงเก่ากว่าระยะเวลาที่กำหนด (cutoff) ซึ่งคือ 24 ชั่วโมงกับอีก 5 นาทีก่อนที่งานจะเริ่ม หรือเป็นเวลาเริ่มต้นของการสำรองข้อมูลที่เก่าที่สุดที่กำลังเขียนอยู่ แล้วแต่ว่าเวลาใดจะถึงก่อน ระยะเวลาเผื่อนี้มีไว้เนื่องจาก Linux มัก mount ระบบไฟล์ด้วย relatime เป็นค่าเริ่มต้น ซึ่งจะอัปเดตเวลาการเข้าถึงเพียงวันละครั้งแทนที่จะอัปเดตทุกครั้งที่มีการอ่าน ดังนั้น chunk ที่เพิ่งเขียนไปเมื่อหนึ่งชั่วโมงก่อนจะไม่ถูกลบแม้ว่าจะยังไม่มีสิ่งใดอ้างอิงถึงก็ตาม และพื้นที่ที่ถูกปลดปล่อยจากการทำ Pruning จะปรากฏให้เห็นในการทำ Collection ครั้งแรกที่รันหลังจาก chunk นั้นถูกเข้าถึงครั้งล่าสุดเกินหนึ่งวัน หาก datastore ดูเหมือนไม่มีการเรียกคืนพื้นที่ มักเป็นเพราะข้อมูลยังอยู่ในช่วงเวลาเผื่อนี้

บน VPS ขนาดเล็ก งานนี้ถือเป็นงานที่หนักที่สุดที่เครื่องต้องประมวลผล เพราะต้องทำ stat ไฟล์ chunk ทุกไฟล์บนโวลุ่ม บันทึกของงานจะสรุปข้อมูลที่ถูกลบไปแล้วและข้อมูลที่ยังค้างอยู่เนื่องจากระยะเวลาผ่อนผัน หากมีข้อมูลค้างอยู่จำนวนมาก ให้รันงานอีกครั้งในวันถัดไป PBS มีตัวเลือก gc-atime-safety-check และ gc-atime-cutoff สำหรับปรับแต่ง datastore ซึ่งควรปล่อยไว้ตามค่าเริ่มต้น เนื่องจากตัวเลือกเหล่านี้มีไว้สำหรับพื้นที่จัดเก็บที่ไม่สามารถบันทึกเวลาการเข้าถึงได้ และการปิดระบบตรวจสอบความปลอดภัยบนระบบไฟล์ที่ mount ด้วย noatime คือสาเหตุที่ทำให้คุณสูญเสีย chunk ที่ snapshot ปัจจุบันยังคงอ้างอิงอยู่

การตรวจสอบยืนยันว่า chunk ยังคงอ่านได้

การสำรองข้อมูลที่อัปโหลดเสร็จสมบูรณ์อาจไม่สามารถอ่านได้ในอีกหนึ่งปีถัดมา การตรวจสอบจะอ่าน chunk ซ้ำและเปรียบเทียบกับ checksum ที่เก็บไว้ใน index เพื่อให้ตรวจพบความเสียหายตามกำหนดการ แทนที่จะไปพบตอนกู้คืนข้อมูล

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

ให้จำกัดจำนวน thread ไว้ในระดับต่ำบน VPS ขนาดเล็ก การตรวจสอบถูกจำกัดด้วยประสิทธิภาพของ disk และ CPU ซึ่งหากไม่จำกัดจะไปแย่งทรัพยากรกับงานอื่นบนเซิร์ฟเวอร์ สำหรับการตั้งกำหนดการ ให้ใช้แท็บ Verify Jobs ของ datastore ในหน้าเว็บอินเทอร์เฟซ โดยตั้งงานรายสัปดาห์ที่ข้าม snapshot ซึ่งตรวจสอบไปแล้ว และตรวจสอบซ้ำเฉพาะข้อมูลที่เก่ากว่า 30 วัน วิธีนี้จะครอบคลุมทั้งคลังข้อมูลเมื่อเวลาผ่านไปโดยไม่ต้องทำงานซ้ำซ้อน

snapshot ที่ไม่ผ่านการตรวจสอบจะถูกทำเครื่องหมายว่าล้มเหลวในมุมมองของ datastore ห้ามเพิกเฉยต่อสถานะนี้ เนื่องจาก chunk ถูกใช้งานร่วมกัน ความเสียหายของ chunk เพียงชิ้นเดียวจาก base image มักจะทำให้ทุก snapshot ที่อ้างอิงถึง chunk นั้นล้มเหลวตามไปด้วย วิธีการซ่อมแซมคือการลบ snapshot ที่ล้มเหลวทิ้งแล้วทำการสำรองข้อมูลใหม่ เพื่ออัปโหลด chunk ที่ขาดหายไปอีกครั้ง หากยังคงพบความล้มเหลวอยู่ ให้สงสัยว่าเกิดจากระบบจัดเก็บข้อมูลภายใต้ datastore และควรตั้งค่า การตรวจสอบสุขภาพของดิสก์บน VPS เพื่อให้ไดรฟ์แจ้งเตือนคุณก่อนที่งานตรวจสอบจะตรวจพบปัญหา

ทดสอบการกู้คืนข้อมูล และทดสอบโดยไม่ใช้คลัสเตอร์

คุณไม่มีทางทราบได้ว่าข้อมูลสำรองใช้งานได้จริงจนกว่าคุณจะได้ลองกู้คืน การทดสอบมี 2 รูปแบบ ซึ่งตรวจสอบคนละประเด็นกัน

กู้คืนทั้ง Guest บนคลัสเตอร์:

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

คอลัมน์แรกของ pvesm list คือ volume ID ซึ่งมี timestamp รวมอยู่ด้วย ดังนั้นให้คัดลอกค่าของคุณแทนการพิมพ์ตามตัวอย่าง ให้กู้คืนไปยัง Guest ID ที่ยังไม่ได้ใช้งานและจัดเก็บไว้ใน storage อื่น จากนั้นเริ่มการทำงานโดยตัดการเชื่อมต่อ network interface ห้ามกู้คืนทับ Guest ที่กำลังทำงานอยู่เพื่อทดสอบข้อมูลสำรอง เพราะหากการกู้คืนล้มเหลวกลางคัน คุณจะสูญเสียทั้งข้อมูลสำรองและข้อมูลต้นฉบับที่ยังใช้งานได้ไปพร้อมกัน

การทดสอบที่สองคือสิ่งที่ไม่มีใครทำกัน ให้สมมติว่าอาคารที่ตั้งคลัสเตอร์ถูกทำลายไปแล้ว และทำการกู้คืนจากเครื่องที่ไม่เคยเป็นส่วนหนึ่งของคลัสเตอร์นั้นมาก่อน บนเครื่อง Debian 13 ใดๆ ให้เพิ่ม repository สำหรับ client-only ดังนี้ /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

กรอกค่าในช่องว่างที่มีเครื่องหมายคำพูดทั้ง 3 จุดด้วยค่าของคุณเอง และระบุชื่อ archive ในบรรทัดสุดท้ายตามที่ snapshot files แสดงไว้ การทดสอบนี้จะพิสูจน์ในสิ่งที่การทดสอบแรกทำไม่ได้ นั่นคือไฟล์ key ของคุณสามารถถอดรหัสข้อมูลจริงได้ และคุณสามารถสั่งงาน client จากเครื่องที่ไม่เคยเก็บค่าคอนฟิกูเรชันของคลัสเตอร์คุณมาก่อนได้ ให้จดบันทึกค่าทั้ง 4 รายการที่จำเป็น ได้แก่ repository string, token secret, fingerprint และไฟล์ key แล้วเก็บไว้ด้วยกันในสถานที่ที่แผนรับมือภัยพิบัติของคุณระบุไว้

การทำ Deduplication ส่งผลต่อค่าใช้จ่ายพื้นที่จัดเก็บข้อมูลของคุณอย่างไร

การทำ Deduplication เป็นเรื่องจริงและใช้งานได้ครอบคลุมทั้ง datastore ตัวอย่างเช่น หากคุณมี Debian guest 10 ตัวที่ใช้ base system ชุดเดียวกัน guest ตัวที่สองที่เหมือนกันแทบจะไม่ใช้พื้นที่จัดเก็บเพิ่มเลย นอกจากนี้ยังช่วยประหยัด bandwidth ในการอัปโหลด เพราะ client จะส่งเพียง checksum แทนการส่งข้อมูลจริงสำหรับ chunk ใดๆ ที่เซิร์ฟเวอร์มีอยู่แล้ว

สิ่งที่การทำ Deduplication ทำไม่ได้นั้นควรกล่าวถึงอย่างตรงไปตรงมา:

ไม่สามารถลดขนาดข้อมูลที่มีการเปลี่ยนแปลงได้ ฐานข้อมูลที่มีการเขียนทับไฟล์ส่วนใหญ่ทุกคืนจะสร้าง chunk ใหม่ขึ้นมาทุกคืน และการเก็บข้อมูลย้อนหลัง (retention) จะทำให้ chunk เหล่านี้เพิ่มจำนวนขึ้น
ไม่สามารถข้ามขอบเขตของ encryption key ได้ ดังที่กล่าวไว้ข้างต้น
ไม่สามารถข้ามขอบเขตของ datastore ได้ ซึ่งเป็นเหตุผลหลักในการใช้ namespaces
ไม่สามารถป้องกัน volume เต็มได้ เมื่อ datastore เต็ม การสำรองข้อมูลจะล้มเหลว และวิธีแก้ไขเดียวคือการขยาย volume หรือลดระยะเวลาการเก็บข้อมูลย้อนหลัง

ห้ามซ้อนทับการทำ deduplication อีกชั้นไว้ด้านล่าง เพราะ chunk ที่ส่งมานั้นผ่านการทำ deduplication และบีบอัดมาจาก client แล้ว ดังนั้นการใช้ ZFS deduplication ภายใต้ datastore จะทำให้สิ้นเปลือง RAM ในการค้นหาข้อมูลที่ซ้ำกันซึ่งถูกลบออกไปก่อนที่จะถูกเขียนลงดิสก์แล้ว การใช้ระบบไฟล์ ext4 หรือ xfs แบบปกติบน volume จึงเป็นทางเลือกที่เหมาะสมที่สุด

หน้าเว็บอินเทอร์เฟซจะแสดงค่า deduplication factor สำหรับ datastore ค่านี้อธิบายลักษณะของ guest ของคุณและเป็นค่าเดียวที่ควรนำมาใช้ในการวางแผน เพราะอัตราส่วนที่เผยแพร่ทั่วไปเป็นข้อมูลของผู้อื่น หากคุณต้องการสำรองข้อมูลระดับไฟล์สำหรับเครื่องที่ไม่ใช่ Proxmox guest ให้รันเครื่องมือเหล่านั้นควบคู่กันบน VPS เดียวกัน โดย PBS เป็นเป้าหมายที่รองรับ hypervisor สำหรับการสำรองข้อมูล guest ทั้งตัว ในขณะที่ restic และ BorgBackup จะเน้นไปที่ไดเรกทอรี และ การสำรองข้อมูลด้วย restic ไปยัง VPS จะเหมาะกับแล็ปท็อปและเซิร์ฟเวอร์แบบ standalone ซึ่ง PBS ไม่ได้ถูกออกแบบมาเพื่อรองรับตั้งแต่แรก

รูปแบบความล้มเหลวและสิ่งที่คุณจะพบ

ที่เก็บข้อมูลแสดงสถานะไม่ทำงาน (inactive) pvesm status --storage pbs-offsite จะแสดง inactive เมื่อโหนดไม่สามารถทำ TLS session ไปยังพอร์ต 8007 ได้สำเร็จ ให้ตรวจสอบ firewall บน VPS จากนั้นตรวจสอบ network firewall ของผู้ให้บริการ และตรวจสอบ fingerprint ตามลำดับ fingerprint ที่ไม่ตรงกับ certificate จะทำให้เกิดความล้มเหลวในลักษณะเดียวกับการถูกบล็อกพอร์ต และค่านี้จะเปลี่ยนไปทุกครั้งที่มีการเปลี่ยน certificate ใหม่

การสำรองข้อมูลครั้งแรกล้มเหลวเนื่องจากปัญหา permission รายการควบคุมการเข้าถึง (access control entry) ต้องระบุชื่อ token แทนที่จะเป็นชื่อผู้ใช้ และต้องครอบคลุม namespace ที่ที่เก็บข้อมูลนั้นชี้ไป ให้ยืนยันทั้งสองค่านี้ที่แท็บ permissions ของ datastore ในหน้าเว็บอินเตอร์เฟซก่อนที่จะไปตรวจสอบส่วนอื่น

Garbage collection ปฏิเสธที่จะเริ่มทำงาน การตรวจสอบความปลอดภัยของเวลาการเข้าถึง (access time safety check) ล้มเหลว ซึ่งมักหมายความว่าระบบไฟล์ของ datastore ถูก mount ด้วยตัวเลือก noatime ให้รัน findmnt -no OPTIONS /mnt/datastore/store1 เพื่อยืนยัน แก้ไขตัวเลือกใน /etc/fstab แล้วทำการ mount ใหม่ ห้ามปิดการตรวจสอบนี้เพื่อข้ามปัญหาไป

ที่เก็บข้อมูลมีขนาดเพิ่มขึ้นเรื่อยๆ งาน prune ทำงานแล้วแต่ไม่มีการคืนพื้นที่ว่าง สาเหตุอาจเกิดจากไม่มีการตั้งตารางเวลาสำหรับ garbage collection หรือการทำงานทุกครั้งอยู่ในช่วงเวลาผ่อนผัน (grace window) 24 ชั่วโมง เนื่องจากรันงานทันทีหลังจากสำรองข้อมูลเสร็จสิ้น ให้ตรวจสอบตารางเวลาด้วย proxmox-backup-manager datastore show store1

การสำรองข้อมูลที่เคยรวดเร็วกลับใช้เวลานานหลายชั่วโมง เกสต์ที่ถูกหยุดทำงาน ย้ายโฮสต์ หรือกู้คืนข้อมูล จะสูญเสีย dirty bitmap ไป ทำให้การรันครั้งถัดไปต้องอ่านข้อมูลทั้งดิสก์ในฝั่งคลัสเตอร์ แม้ว่าจะมีการอัปโหลดข้อมูลจริงเพียงเล็กน้อยก็ตาม ใน log ของงานจะแสดงระยะเวลาที่ยาวนานพร้อมตัวเลขการอัปโหลดที่น้อย และการรันครั้งถัดไปจะกลับมารวดเร็วเหมือนเดิม หากงานทุกอย่างบน VPS ทำงานช้าทั้งหมด สาเหตุส่วนใหญ่มักอยู่นอกเหนือจาก datastore และ CPU steal time จาก noisy neighbour คือสิ่งแรกที่ควรวัดผล

FAQ

ทำไม datastore ของ Proxmox Backup Server ถึงยังคงมีขนาดเพิ่มขึ้นแม้ว่าจะรัน prune job แล้ว?

เพราะการทำ prune จะลบเพียง metadata ของ snapshot เท่านั้น ได้แก่ manifest, index, log และ notes ส่วน chunk ต่างๆ จะยังคงอยู่บนดิสก์จนกว่า garbage collection จะลบ chunk ที่ไม่มี index ใดๆ อ้างอิงถึงออกไป ให้กำหนดตารางเวลาให้กับ datastore ด้วย proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' และตรวจสอบผลลัพธ์โดยรัน df -h บน path ของ datastore ก่อนและหลังการรัน proxmox-backup-manager garbage-collection start store1 โดยควรเผื่อเวลาอย่างน้อยหนึ่งวัน เนื่องจากขั้นตอนที่สองจะลบเฉพาะ chunk ที่มีเวลาการเข้าถึง (access time) นานกว่า 24 ชั่วโมงกับอีก 5 นาทีเท่านั้น

Proxmox Backup Server ที่เป็น VPS ต้องการพื้นที่ดิสก์เท่าใด?

ให้รวมพื้นที่ที่ guest แต่ละตัวใช้งานจริง จากนั้นบวกด้วยอัตราการเปลี่ยนแปลงข้อมูลรายวันของ guest แต่ละตัวคูณด้วยจำนวนวันที่คุณเก็บข้อมูล ผลรวมนั้นคือเพดานสูงสุด เนื่องจากคุณสมบัติการบีบอัด (compression) และการลดความซ้ำซ้อน (deduplication) จะช่วยลดการใช้พื้นที่ลง ให้บวกเพิ่มอีกประมาณหนึ่งในห้าสำหรับ index และพื้นที่ทำงาน จากนั้นปัดเศษขึ้นเป็นขนาด volume ที่คุณสามารถจัดหาได้ ให้ตรวจสอบการใช้งานจริงในหน้า datastore อีกครั้งหลังจากผ่านไปสองสัปดาห์ เพราะการคาดการณ์ก่อนการสำรองข้อมูลครั้งแรกมักจะคลาดเคลื่อนเสมอ

ควรเก็บ encryption key สำหรับการสำรองข้อมูลไว้ที่ใด?

เก็บไว้ที่ใดก็ได้ที่ไม่ใช่แค่บน cluster ที่ key นั้นปกป้องอยู่ Proxmox VE จะเก็บ key ไว้ที่ /etc/pve/priv/storage/<storage>.enc ซึ่งจะถูก replicate ไปยังทุก node ดังนั้นหาก cluster เสียหาย ข้อมูลก็จะสูญหายไปด้วย ให้คัดลอก key ออกมาตั้งแต่วันแรก พิมพ์ออกมาด้วย proxmox-backup-client key paperkey และเก็บสำเนาชุดนั้นไว้ในอาคารอื่น โปรดทราบว่า key มีส่วนร่วมในการคำนวณ chunk digest ดังนั้นหากเปลี่ยน key ในภายหลัง จะส่งผลให้การสำรองข้อมูลครั้งถัดไปต้องอัปโหลดข้อมูลทั้งหมดใหม่อีกครั้ง

ควรใช้หนึ่ง datastore ต่อหนึ่ง Proxmox host หรือควรใช้ namespaces?

ควรใช้หนึ่ง datastore และหนึ่ง namespace ต่อหนึ่ง source host หรือ cluster การลดความซ้ำซ้อน (deduplication) จะทำงานภายใน datastore เดียวกันเท่านั้น ไม่ข้ามระหว่าง datastore ดังนั้นการแยกตาม host จะทำให้ base image ชุดเดียวกันถูกจัดเก็บซ้ำหลายครั้ง ส่วน namespaces จะช่วยแยกกลุ่มการสำรองข้อมูลออกจากกัน ทำให้ host สองเครื่องที่มี guest ID 100 เหมือนกันไม่เกิดการทับซ้อนกัน และการกำหนด access control path ในรูปแบบ /datastore/store1/pve-home จะช่วยจำกัดสิทธิ์ของ API token ของแต่ละ host ให้เข้าถึงได้เฉพาะ namespace ของตนเองเท่านั้น

VPS ขนาดเล็กจะสามารถรองรับการทำงานเป็น Proxmox backup server ได้หรือไม่?

โดยทั่วไปสามารถทำได้สำหรับ homelab เนื่องจากกระบวนการ chunking และ hashing จะเกิดขึ้นที่ฝั่ง Proxmox VE node ไม่ใช่ที่ backup server ตัว VPS จะทำหน้าที่เขียน chunk และรันงานหนักสองอย่างคือ garbage collection และ verification ให้จัดสรร RAM ขนาด 4 GB และกำหนดจำนวน thread สำหรับการตรวจสอบ (verification) ให้ต่ำไว้ ควรตั้งตารางเวลาสำหรับงานทั้งสองอย่างนอกช่วงเวลาที่มีการสำรองข้อมูล และหากงานเหล่านั้นยังคงใช้เวลานานเกินกว่าที่ดิสก์ควรจะทำได้ ให้วัดค่า steal time ก่อนที่จะตัดสินใจอัปเกรดแผนการใช้งานให้ใหญ่ขึ้น

#proxmox #backups#offsite#deduplication#vps