Cara Pasang Proxmox Backup Server pada VPS

Apa yang Proxmox Backup Server pada VPS sebenarnya berikan kepada anda

Proxmox Backup Server (PBS) pada VPS merupakan sasaran luar tapak yang menggunakan protokol sama seperti kluster Proxmox VE (virtual environment) anda, jadi setiap sandaran selepas yang pertama adalah bersifat inkremental, dinyahduplikasi merentas tetamu, disulitkan sebelum meninggalkan premis anda, dan boleh disahkan selepasnya. Anda menyewa VPS dengan volum blok, memasang PBS pada Debian 13, mencipta satu datastore pada volum tersebut, dan menambahkannya dalam Proxmox VE sebagai storan jenis pbs. Pemasangan mengambil masa sepuluh minit. Segala perkara selepas itu, seperti namespaces, garbage collection, jagaan kunci dan pemulihan yang telah anda jalankan, adalah penentu sama ada sandaran tersebut bernilai atau tidak setahun dari sekarang.

Sebab untuk menggunakan PBS berbanding menyalin fail vzdump ke cakera sewaan adalah chunk store. Pelanggan memecahkan setiap cakera tetamu kepada ketulan (chunks) bersaiz kira-kira 4 MiB, melakukan hashing terhadapnya, dan memuat naik hanya ketulan yang belum ada dalam datastore. Bagi mesin maya yang sedang berjalan, QEMU menjejaki blok yang berubah dalam dirty bitmap selepas sandaran pertama, jadi proses seterusnya hanya membaca blok tersebut daripada cakera tempatan. Tetamu bersaiz 200 GB yang berubah sebanyak 3 GB sehari hanya akan menghantar kira-kira 3 GB sehari. Inilah yang membolehkan pautan naik (uplink) rumah dan volum sewaan berfungsi bersama, dan sebab itulah VPS sebagai sasaran sandaran luar tapak lebih baik daripada cakera simpanan di rumah rakan. Jika anda masih membuat keputusan di mana hypervisor itu sendiri harus ditempatkan, Proxmox di rumah berbanding VPS sewaan membincangkan soalan tersebut secara berasingan.

Tentukan saiz volum sebelum anda menyewanya

Penentuan saiz ialah pengiraan aritmetik yang anda lakukan berdasarkan angka anda sendiri. Ambil ruang yang sebenarnya digunakan oleh setiap tetamu, bukan saiz cakera maya, kemudian tambah jumlah perubahan setiap hari didarab dengan bilangan hari anda menyimpannya. Pemampatan (compression) dan penyahduplikasian (deduplication) kedua-duanya menambah baik angka tersebut, jadi anggap hasil pengiraan itu sebagai had maksimum dan bukannya sasaran.

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

Baris-baris tersebut merupakan contoh kerja, bukan ukuran. Baca ruang yang digunakan daripada df -h di dalam setiap tetamu, dan baca perubahan harian daripada saiz sandaran kedua dan ketiga dalam log tugas PBS sebaik sahaja ia wujud.

Tetamu mel dalam contoh tersebut menggunakan 120 GB dan berubah kira-kira 3.0 GB sehari, jadi tiga puluh snapshot harian memerlukan kira-kira 210 GB: satu salinan penuh ditambah tiga puluh hari perubahan. Tambahkan lajur terakhir merentas semua 3 tetamu dan jumlahnya adalah kira-kira 619 GB. Tambahkan satu perlima lagi sebagai tambahan untuk indeks, metadata dan ruang yang diperlukan oleh garbage collection untuk berfungsi, yang menunjukkan keperluan volum 1 TB.

Selebihnya pelan ini adalah kecil. PBS beroperasi dengan baik pada 2 GB RAM dan selesa dengan 4 GB, kerana kerja berat berlaku di bahagian kluster: nod Proxmox VE membaca cakera tetamu serta melakukan chunking dan hashing. Apa yang dilakukan oleh VPS ialah menulis chunk dan menjalankan dua tugas berat, iaitu garbage collection dan pengesahan. Sewa datastore sebagai volum blok yang berasingan dan bukannya satu cakera root yang besar, kerana anda boleh membesarkan volum kemudian tanpa perlu membina semula pelayan.

Memasang Proxmox Backup Server pada Debian 13

Sehingga Ogos 2026, gandingan semasa ialah Proxmox Backup Server 4 pada Debian 13, dengan nama kod trixie. Panduan lama menggandingkan PBS 2 dengan Debian 11, dan nama kod tersebut merupakan sebahagian daripada definisi repositori. Oleh itu, menyalin nama suite lama akan menyebabkan ralat apt mengenai fail release yang tiada. Mulakan daripada imej Debian 13 yang bersih. Jalankan semua arahan di bawah sebagai root, atau dengan sudo seperti yang tertulis.

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

Hasil tambah (sum) mestilah terbaca 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Jika tidak, berhenti. Keyring yang salah bermakna anda akan memasang pakej yang ditandatangani oleh sesuatu yang belum anda semak.

Tulis /etc/apt/sources.list.d/pbs.sources dengan repositori no-subscription, iaitu repositori yang betul untuk pelayan tanpa kontrak sokongan:

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

Antara muka web menjawab pada port HTTPS 8007. Log masuk sebagai root@pam menggunakan kata laluan root sistem, kerana PBS mengesahkan pengguna tersebut melalui PAM (pluggable authentication modules), akaun yang sama yang digunakan oleh sistem pengendalian. Sijil tersebut ditandatangani sendiri (self-signed) dan pelayar anda akan memaklumkan perkara ini. Fingerprint sijil tersebut adalah nilai yang akan dipinkan oleh Proxmox VE kemudian, jadi amaran itu dijangka dan bukannya masalah yang perlu dibaiki.

Port 8007 ialah borang log masuk di internet awam, jadi jangan biarkannya terbuka kepada semua orang. Satu fail nftables sudah memadai. Menulis /etc/nftables.conf akan memadam set peraturan semasa, jadi langkau langkah ini jika ada perkara lain yang sudah menguruskan firewall pada mesin ini.

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

Gunakan peraturan tersebut dengan sudo systemctl enable --now nftables, dan pastikan sesi SSH kedua dibuka semasa anda melakukannya: policy drop ditambah satu kesilapan taip dalam peraturan SSH akan mengunci anda daripada pelayan anda sendiri. Gantikan 203.0.113.7 dengan alamat yang digunakan oleh kluster anda untuk keluar. Jika alamat tersebut dinamik, sama ada luaskan peraturan kepada julat pembekal anda atau tamatkan sambungan dalam terowong, dan ingat bahawa kebanyakan panel VPS mempunyai firewall rangkaian berasingan di hadapan mesin yang mesti membenarkan port yang sama.

Letakkan datastore pada volumnya sendiri

Datastore tidak boleh berada pada sistem fail root. Apabila datastore memenuhi sistem fail root yang dikongsi, sandaran akan gagal dan begitu juga dengan segala perkara lain pada mesin tersebut, termasuk log yang anda perlukan untuk mengetahui puncanya. Lampirkan volum blok, formatkannya, lekapkannya (mount), dan hanya selepas itu cipta datastore di dalam titik lekap tersebut.

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

Ambil nama peranti daripada lsblk. Ia adalah /dev/vdb pada kebanyakan imej KVM dan /dev/sdb pada imej lain, dan anda tidak boleh membuat andaian. Tambahkan lekap ke /etc/fstab mengikut label, supaya penamaan semula peranti selepas but semula tidak menyebabkan datastore menghala ke cakera yang salah:

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 sepatutnya memaparkan peranti, laluan, dan pilihan termasuk rw,relatime. Dua kegagalan tersembunyi dalam satu baris itu. Jika lekap tidak wujud dan anda tetap mencipta datastore, PBS akan menulis ke dalam sistem fail root di bawah titik lekap tersebut, dan lekap yang berjaya seterusnya akan menyembunyikan data itu tanpa memadamkannya: datastore kemudian kelihatan kosong dan sistem fail root kekal penuh. Jika pilihan menyatakan noatime, PBS enggan berfungsi, kerana ia menjalankan pemeriksaan keselamatan masa akses apabila datastore dicipta dan sekali lagi pada setiap pengumpulan sampah (garbage collection).

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

Itu mencipta direktori .chunks yang mengandungi 65536 subdirektori, dinamakan 0000 hingga ffff. Datastore terdiri daripada ratusan ribu fail kecil, bukan beberapa fail besar. Dua perkara perlu diambil perhatian. Menyalin datastore dengan alat peringkat fail biasa adalah terlalu perlahan sehingga tidak berguna, dan snapshot volum penyedia yang diambil semasa sandaran sedang berjalan bukanlah salinan yang konsisten, yang merupakan sebab yang sama mengapa snapshot tidak menggantikan sandaran di mana-mana tempat lain.

Namespace menghalang perlanggaran antara dua hos

Datastore secara lalai adalah rata. Sandaran dinamakan vm/100, ct/101 dan host/<name>. Dua kluster yang masing-masing mempunyai tetamu dengan ID 100 menulis ke dalam kumpulan yang sama, snapshot mereka bercampur, dan peraturan pengekalan yang ditulis untuk salah satu daripadanya akan mengira snapshot yang satu lagi. Namespace memberikan setiap sumber pokoknya sendiri di dalam satu datastore.

Ciptakannya pada hos PBS. Argumen --repository mempunyai format [[auth-id@]server[:port]:]datastore, jadi namespace tempatan dibaca sebagai root@pam@localhost:store1, dan arahan tersebut akan meminta kata laluan 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'

Deduplikasi tidak terjejas oleh pembahagian ini. Ketulan data (chunks) dikongsi merentasi keseluruhan datastore, jadi sepuluh tetamu Debian yang tersebar merentasi tiga namespace masih menyimpan satu salinan sistem asas. Itulah hujah untuk menggunakan satu datastore dengan namespace berbanding satu datastore bagi setiap hos: datastore yang berasingan bermakna kumpulan ketulan data yang berasingan, dan kumpulan ketulan data yang berasingan bermakna anda membayar untuk pemasangan Debian yang sama berkali-kali.

Berikan setiap sumber akaunnya sendiri, yang dihadkan kepada namespace masing-masing. Token API (application programming interface) ialah kelayakan yang dimiliki oleh pengguna dan membawa kebenarannya sendiri, iaitu apa yang anda perlukan pada mesin yang mungkin dicuri.

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'

Arahan token mencetak rahsia tersebut tepat sekali sahaja:

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

Salin ia sekarang, kerana PBS tidak menyimpan sebarang bentuk rahsia itu yang boleh ditunjukkan kepada anda semula. Perhatikan arahan kawalan akses dua kali. Ia menamakan token tersebut, backup@pbs!pve-home, dan bukan pengguna, kerana kebenaran token dikira hanya daripada entri yang menamakan token itu sendiri. Entri untuk backup@pbs sahaja menyebabkan token tersebut tidak mempunyai akses langsung, dan sandaran pertama kemudiannya gagal disebabkan kebenaran dan bukannya disebabkan sebarang perkara yang kelihatan dalam rangkaian. Laluan (path) juga sama penting: token yang dihadkan kepada /datastore/store1/pve-home tidak boleh membaca atau memadam apa-apa dalam namespace pejabat, jadi satu kluster yang terjejas tidak boleh memusnahkan sejarah tapak yang lain.

Menambah VPS sebagai storan sandaran dalam Proxmox VE

Baca cap jari sijil (certificate fingerprint) pada hos PBS terlebih dahulu.

sudo proxmox-backup-manager cert info | grep Fingerprint

Kemudian, pada mana-mana nod dalam kluster:

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

Tampal nilai cert info yang dipaparkan sebagai ganti pemegang tempat pada baris ketiga. Menghantar --password tanpa nilai akan menyebabkan pvesm memaparkan gesaan untuk memasukkannya, supaya rahsia token tidak tersimpan dalam sejarah shell anda. Ia disimpan di /etc/pve/priv/storage/pbs-offsite.pw, dan definisi storan itu sendiri dimasukkan ke dalam /etc/pve/storage.cfg, yang direplikasi ke setiap nod dalam kluster, jadi anda hanya perlu mengkonfigurasinya sekali untuk keseluruhan kluster.

--prune-backups keep-all=1 memberitahu Proxmox VE supaya tidak memadamkan apa-apa. Polisi pengekalan (retention) adalah tanggungjawab pihak PBS, yang akan dibincangkan dengan lebih lanjut di bawah, atas sebab yang perlu dinyatakan dengan jelas: token tersebut tidak memerlukan kebenaran untuk memadam, jadi kluster yang diserang perisian tebusan (ransomware) tidak boleh mencapai dan memadam sejarah sandaran luar tapak yang sepatutnya menyelamatkan kluster tersebut.

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

pvesm status memaparkan active dalam lajur status, berserta jumlah ruang storan dan ruang yang telah digunakan. inactive bermaksud nod tersebut tidak dapat melengkapkan sesi TLS (transport layer security) ke port 8007, yang biasanya merupakan masalah firewall atau cap jari, bukannya masalah kelayakan (credential).

Sandaran pertama akan memuat naik segala-galanya, jadi lakukan pengiraan sebelum anda memulakannya. 200 GB bersamaan dengan 1600 gigabit, dan pautan naik (uplink) 100 Mbit memindahkan 0.1 gigabit sesaat, jadi masa minimum adalah kira-kira empat jam setengah dan realitinya akan mengambil masa lebih lama. Mulakan sandaran apabila anda tidak memerlukan lebar jalur tersebut. Setiap proses sandaran selepas itu hanya akan menghantar ketulan data (chunks) yang baharu sahaja.

Penyulitan sisi pelanggan, dan lokasi kunci disimpan

VPS ialah komputer yang bukan milik anda. Lakukan penyulitan pada sisi pelanggan, supaya storan data hanya menyimpan cebisan yang tidak boleh dibaca oleh penyedia perkhidmatan.

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

Perintah tersebut menulis kunci baharu ke /etc/pve/priv/storage/pbs-offsite.enc, yang hanya boleh dibaca oleh root, dan direplikasi bersama-sama dengan baki /etc/pve. Bermula daripada sandaran seterusnya, pelanggan akan menyulitkan setiap cebisan sebelum ia dihantar keluar. Pelayan masih boleh menyenaraikan snapshot anda serta saiznya, namun ia tidak dapat membaca kandungan tersebut.

Sekarang, bahagian yang menjadikan ini satu sandaran dan bukannya liabiliti. Kunci yang dijana tidak mempunyai frasa laluan, dan ia hanya wujud pada kluster yang dilindunginya. Jika kluster tersebut dicuri atau disulitkan oleh pihak lain, VPS hanya memegang data yang tidak boleh dibuka oleh sesiapa. Salin kunci tersebut keluar daripada kluster pada hari anda menciptanya.

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 mencetak kunci sebagai dokumen yang bertujuan untuk dicetak di atas kertas dan disimpan di tempat lain. Anggap fail tersebut sebagai rahsia, kerana sesiapa yang memegangnya boleh menyahsulit setiap sandaran yang dibuat dengannya. Untuk persediaan yang lebih besar, PBS juga menyokong kunci induk, iaitu pasangan kunci RSA (Rivest Shamir Adleman) yang dicipta dengan proxmox-backup-client key create-master-key, di mana setiap sandaran menyimpan kunci penyulitannya sendiri yang disulitkan kepada bahagian awam, sementara bahagian peribadi disimpan di luar talian untuk tujuan pemulihan.

Satu kesan daripada reka bentuk ini perlu diketahui sebelum anda bermula, bukannya selepas. Bagi sandaran yang disulitkan, digest cebisan dikira daripada kandungan teks biasa yang digabungkan dengan kunci penyulitan. Oleh itu, dua cebisan yang sama yang disulitkan di bawah kunci yang berbeza akan menghasilkan digest yang berbeza dan tidak akan dinyahduplikasi antara satu sama lain. Menukar kunci bermakna sandaran seterusnya akan memuat naik segala-galanya semula, dan cebisan lama akan kekal di sana sehingga snapshotnya dibuang dan dikumpul. Tentukan keperluan penyulitan sebelum muat naik pertama dilakukan.

Tanda prune, pengumpulan sampah (garbage collection) menuntut semula ruang

Ini adalah bahagian yang sering dilangkau, dan ia merupakan punca storan penuh. Melakukan prune pada snapshot hanya membuang metadata: manifest, indeks, log dan nota. Ia tidak memadamkan sebarang chunk. Chunk dikongsi antara snapshot, jadi tiada apa yang dapat menentukan sama ada sesuatu chunk tidak digunakan sehingga setiap indeks yang tinggal dibaca, dan pengumpulan sampah adalah tugas yang membaca indeks tersebut. Datastore yang mempunyai jadual prune tetapi tiada jadual pengumpulan sampah akan terus berkembang saiznya.

Tetapkan kedua-duanya. Mulakan dengan pengekalan (retention), satu tugas bagi setiap 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

Kemudian jadual pengumpulan pada datastore, beberapa jam selepas tugas prune dan di luar tempoh sandaran (backup window):

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

Buktikan pembahagian tugas ini kepada diri sendiri sekali, pada hos PBS:

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

Jalankan tugas prune, kemudian df, dan angka penggunaan tidak akan berubah. Jalankan pengumpulan sampah, kemudian df sekali lagi, dan angka tersebut akan berubah.

Pengumpulan sampah berjalan dalam dua fasa. Fasa pertama menelusuri setiap indeks dalam datastore dan mengemas kini masa akses bagi setiap chunk yang dirujuk oleh indeks tersebut. Fasa kedua memadamkan chunk yang mempunyai masa akses lebih lama daripada tempoh had (cutoff), iaitu 24 jam dan 5 minit sebelum tugas bermula, atau masa bermulanya sandaran tertua yang masih dalam proses penulisan, yang mana lebih awal. Margin ini wujud kerana Linux melekapkan (mount) sistem fail dengan relatime secara lalai, yang mengemas kini masa akses kira-kira sekali sehari dan bukannya pada setiap bacaan. Jadi, chunk yang ditulis sejam yang lalu tidak akan dipadamkan walaupun tiada apa yang merujuknya lagi, dan ruang yang dibebaskan oleh prune akan muncul pada pengumpulan pertama yang dijalankan lebih daripada sehari selepas chunk tersebut terakhir disentuh. Datastore yang kelihatan seperti tidak menuntut semula sebarang ruang selalunya hanya berada dalam tempoh masa tersebut.

Pada VPS kecil, ini adalah tugas paling berat yang dijalankan oleh pelayan, kerana ia melakukan stat pada setiap fail chunk dalam volum tersebut. Log tugas berakhir dengan ringkasan tentang apa yang telah dibuang dan apa yang masih tertangguh disebabkan oleh tempoh tangguh (grace period). Jika banyak yang tertangguh, jalankan semula pada hari berikutnya. PBS mendedahkan gc-atime-safety-check dan gc-atime-cutoff sebagai pilihan penalaan datastore, dan kedua-duanya harus dibiarkan seperti asal: ia wujud untuk storan yang tidak dapat merekodkan masa akses, dan mematikan semakan keselamatan pada sistem fail yang dilekapkan dengan noatime adalah punca anda kehilangan chunk yang masih dirujuk oleh snapshot yang aktif.

Pengesahan membuktikan ketulan data masih boleh dibaca

Sandaran yang dimuat naik dengan sempurna boleh menjadi tidak boleh dibaca setahun kemudian. Pengesahan membaca semula ketulan data (chunks) dan membandingkannya dengan checksum yang disimpan dalam indeks, supaya kerosakan ditemui mengikut jadual dan bukannya semasa proses pemulihan.

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

Pastikan bilangan thread rendah pada VPS yang kecil. Pengesahan dihadkan oleh cakera dan CPU, dan ia akan bersaing dengan apa jua proses lain yang sedang dijalankan oleh pelayan tersebut. Untuk jadual, gunakan tab Verify Jobs pada datastore dalam antara muka web: tugasan mingguan yang melangkau snapshot yang telah disahkan dan mengesahkan semula mana-mana snapshot yang lebih lama daripada 30 hari akan meliputi keseluruhan storan dari semasa ke semasa tanpa mengulangi kerja yang sama.

Snapshot yang gagal dalam pengesahan akan ditandakan sebagai gagal dalam paparan datastore. Jangan abaikan kegagalan tersebut. Ketulan data dikongsi bersama, jadi satu ketulan yang rosak daripada imej asas biasanya akan menyebabkan kegagalan pada setiap snapshot yang merujuk kepadanya. Pembaikan yang perlu dilakukan adalah dengan memadam (forget) snapshot yang gagal dan menjalankan sandaran baharu, yang akan memuat naik semula ketulan data yang hilang. Jika kegagalan terus muncul, syaki storan di bawah datastore tersebut, dan sediakan pemantauan kesihatan cakera pada VPS supaya pemacu tersebut memberi amaran kepada anda sebelum tugasan pengesahan melakukannya.

Uji pemulihan, kemudian ujinya tanpa kluster

Anda tidak akan tahu sama ada sandaran berfungsi sehingga anda berjaya memulihkannya. Terdapat dua ujian, dan kedua-duanya menyemak perkara yang berbeza.

Tetamu keseluruhan, pada kluster:

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

Lajur pertama pvesm list ialah ID volum, dan cap masa adalah sebahagian daripadanya, jadi salin milik anda dan bukannya menaip contoh tersebut. Pulihkan ke dalam ID tetamu yang tidak digunakan dan ke storan yang berbeza, kemudian mulakannya dengan antara muka rangkaiannya diputuskan. Jangan sekali-kali memulihkan ke atas tetamu yang sedang berjalan untuk menyemak sama ada sandaran berfungsi, kerana pemulihan yang gagal di pertengahan jalan akan menyebabkan anda kehilangan salinan yang masih berfungsi.

Ujian kedua adalah ujian yang jarang dilakukan oleh sesiapa. Andaikan bangunan yang menempatkan kluster tersebut telah musnah, dan lakukan pemulihan daripada mesin yang tidak pernah menjadi sebahagian daripadanya. Pada mana-mana kotak Debian 13, tambahkan repositori klien sahaja sebagai /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

Isikan tiga pemegang tempat bertanda petikan dengan nilai anda sendiri, dan ambil nama arkib pada baris terakhir daripada apa yang dicetak oleh snapshot files. Ini membuktikan perkara yang tidak dapat dibuktikan oleh ujian pertama: bahawa salinan fail kunci anda menyahsulit data sebenar, dan anda boleh mengendalikan klien daripada mesin yang tidak pernah menyimpan konfigurasi kluster anda. Tuliskan empat nilai yang diperlukan, rentetan repositori, rahsia token, cap jari dan fail kunci, serta simpan semuanya bersama-sama di tempat yang dinyatakan dalam pelan bencana anda.

Apakah kesan deduplikasi terhadap bil storan anda

Deduplikasi adalah nyata dan ia berfungsi merentasi keseluruhan datastore. Sepuluh guest Debian berkongsi satu salinan sistem asas antara satu sama lain, jadi guest kedua yang serupa hampir tidak memerlukan kos storan tambahan. Ia juga menjimatkan lebar jalur muat naik kerana klien menghantar checksum dan bukannya data bagi mana-mana chunk yang sudah dimiliki oleh pelayan.

Perkara yang tidak dilakukan oleh deduplikasi perlu dinyatakan secara terus terang.

• Ia tidak mengecilkan data yang berubah-ubah. Pangkalan data yang menulis semula sebahagian besar failnya setiap malam akan menghasilkan chunk baharu setiap malam, dan tempoh pengekalan akan menggandakan jumlahnya.
• Ia tidak berfungsi merentasi sempadan kunci penyulitan, seperti yang dibincangkan di atas.
• Ia tidak berfungsi merentasi sempadan datastore, yang merupakan alasan utama penggunaan namespace.
• Ia tidak menghalang volum daripada penuh. Apabila datastore penuh, sandaran akan gagal, dan satu-satunya penyelesaian adalah volum yang lebih besar atau tempoh pengekalan yang lebih singkat.

Jangan tindihkan lapisan deduplikasi lain di bawahnya. Chunk tiba dalam keadaan sudah dideduplikasi dan dimampatkan oleh klien, jadi deduplikasi ZFS di bawah datastore hanya akan membazirkan RAM untuk mencari padanan yang telah dibuang sebelum ia ditulis. Sistem fail ext4 atau xfs biasa pada volum adalah pilihan yang tepat di sini.

Antara muka web melaporkan faktor deduplikasi untuk datastore. Nombor tersebut menerangkan keadaan guest anda, dan ia adalah satu-satunya angka yang wajar digunakan untuk perancangan, kerana nisbah yang diterbitkan biasanya berdasarkan data orang lain. Jika anda juga memerlukan sandaran peringkat fail bagi mesin yang bukan guest Proxmox, jalankan sandaran tersebut bersama-sama pada VPS yang sama: PBS ialah sasaran yang peka-hipervisor untuk keseluruhan guest, manakala restic dan BorgBackup ditujukan kepada direktori, dan sandaran restic ke VPS sesuai untuk komputer riba serta pelayan kendiri yang tidak diliputi oleh PBS.

Mod kegagalan dan perkara yang akan anda lihat

Storan menunjukkan status tidak aktif. pvesm status --storage pbs-offsite akan mencetak inactive apabila nod tidak dapat melengkapkan sesi TLS ke port 8007. Periksa firewall pada VPS, kemudian firewall rangkaian berasingan milik penyedia, dan seterusnya fingerprint. Fingerprint yang tidak lagi sepadan dengan sijil akan gagal dengan cara yang sama seperti port yang disekat, dan ia berubah setiap kali sijil tersebut diganti.

Sandaran pertama gagal disebabkan kebenaran. Entri kawalan akses perlu menamakan token dan bukannya pengguna, dan ia perlu meliputi namespace yang ditunjuk oleh storan tersebut. Sahkan kedua-duanya pada tab kebenaran datastore dalam antara muka web sebelum anda memeriksa tempat lain.

Pengumpulan sampah (garbage collection) enggan bermula. Semakan keselamatan masa akses gagal, yang hampir selalu bermaksud sistem fail datastore dilekapkan sebagai noatime. Jalankan findmnt -no OPTIONS /mnt/datastore/store1 untuk mengesahkan, betulkan pilihan dalam /etc/fstab, dan lekapkan semula. Jangan nyahdayakan semakan tersebut hanya untuk melangkauinya.

Datastore hanya berkembang. Kerja pemangkasan (prune jobs) dijalankan tetapi tiada ruang yang dituntut semula. Sama ada tiada jadual pengumpulan sampah, atau setiap pengumpulan berlaku dalam tempoh tangguh 24 jam kerana ia dijalankan serta-merta selepas sandaran. Periksa jadual dengan proxmox-backup-manager datastore show store1.

Sandaran yang dahulunya pantas kini mengambil masa berjam-jam. Tetamu yang dihentikan, dimigrasikan atau dipulihkan akan kehilangan dirty bitmap miliknya, jadi larian seterusnya akan membaca keseluruhan cakera pada bahagian kluster walaupun data yang dimuat naik sangat sedikit. Log tugas menunjukkan tempoh yang lama dengan angka muat naik yang kecil, dan larian seterusnya akan kembali pantas. Jika setiap kerja pada VPS menjadi perlahan, puncanya biasanya di luar datastore, dan CPU steal time daripada jiran yang bising adalah perkara pertama yang perlu diukur.

FAQ

Mengapakah datastore Proxmox Backup Server saya terus membesar apabila kerja prune dijalankan?

Ini kerana proses pruning hanya membuang metadata snapshot: manifest, indeks, log dan nota. Chunk kekal pada cakera sehingga garbage collection memadamkan chunk yang tidak lagi dirujuk oleh mana-mana indeks. Tetapkan jadual untuk datastore menggunakan proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27', dan buktikan keberkesanannya dengan menjalankan df -h pada laluan datastore sebelum dan selepas proxmox-backup-manager garbage-collection start store1. Jangkakan kelewatan sekurang-kurangnya sehari, kerana fasa kedua hanya membuang chunk yang mempunyai masa akses lebih lama daripada 24 jam dan 5 minit.

Berapakah saiz cakera yang diperlukan oleh VPS Proxmox Backup Server?

Jumlahkan ruang yang digunakan oleh setiap tetamu, kemudian tambahkan perubahan harian setiap tetamu didarab dengan bilangan hari anda menyimpan sandaran. Jumlah tersebut adalah had maksimum, kerana pemampatan dan penyahduplikasian (deduplication) akan mengurangkan penggunaan ruang. Tambahkan kira-kira satu perlima daripada jumlah tersebut untuk indeks dan ruang kerja, kemudian bundarkan kepada saiz volum yang boleh anda beli. Semak semula selepas dua minggu berdasarkan penggunaan sebenar dalam paparan datastore, kerana anggaran yang dibuat sebelum sandaran pertama sentiasa tidak tepat.

Di manakah kunci penyulitan sandaran perlu disimpan?

Di mana-mana sahaja kecuali hanya pada kluster yang dilindunginya. Proxmox VE menyimpannya di /etc/pve/priv/storage/<storage>.enc, yang direplikasi ke setiap nod dan oleh itu akan hilang bersama kluster tersebut. Salin kunci tersebut pada hari pertama, cetak menggunakan proxmox-backup-client key paperkey, dan simpan salinan tersebut di bangunan yang berbeza. Ambil perhatian juga bahawa kunci tersebut adalah sebahagian daripada chunk digest, jadi menggantikannya kemudian bermakna sandaran seterusnya akan memuat naik segala-galanya semula.

Adakah saya perlukan satu datastore bagi setiap hos Proxmox, atau namespace?

Gunakan satu datastore dan satu namespace bagi setiap hos sumber atau kluster. Penyahduplikasian berfungsi merentasi satu datastore dan bukan antara datastore yang berbeza, jadi memisahkan mengikut hos akan menyebabkan imej asas yang sama disimpan berulang kali. Namespace memastikan kumpulan sandaran terasing, supaya dua hos yang kedua-duanya mempunyai tetamu dengan ID 100 tidak akan bertembung, dan laluan kawalan akses dalam bentuk /datastore/store1/pve-home mengehadkan token API setiap hos kepada namespace masing-masing.

Adakah VPS kecil mampu berfungsi sebagai pelayan sandaran Proxmox?

Biasanya mampu, untuk kegunaan makmal rumah (homelab), kerana proses chunking dan hashing berlaku pada nod Proxmox VE dan bukannya pada pelayan sandaran. VPS hanya menulis chunk dan menjalankan dua kerja berat, iaitu garbage collection dan verifikasi. Berikan VPS tersebut 4 GB RAM dan pastikan bilangan thread verifikasi adalah rendah. Jadualkan kedua-dua kerja tersebut di luar waktu sandaran, dan jika ia masih mengambil masa yang jauh lebih lama daripada kelajuan cakera yang sepatutnya, ukur steal time sebelum anda membeli pelan yang lebih besar.