Proxmox Backup Server di VPS: Setup dan Restore

Apa yang sebenarnya diberikan Proxmox Backup Server pada VPS

Proxmox Backup Server (PBS) pada VPS adalah target di luar lokasi yang menggunakan protokol yang sama dengan cluster Proxmox VE (virtual environment) Anda. Karena itu, setiap backup setelah backup pertama bersifat incremental, dideduplikasi di antara guest, dienkripsi sebelum keluar dari lokasi Anda, dan dapat diverifikasi setelahnya. Anda menyewa VPS dengan volume block, menginstal PBS pada Debian 13, membuat satu datastore pada volume tersebut, lalu menambahkannya di Proxmox VE sebagai storage bertipe pbs. Instalasinya memerlukan waktu sepuluh menit. Setelah itu, namespace, garbage collection, pengelolaan kunci, dan restore yang benar-benar pernah Anda jalankan akan menentukan apakah backup tersebut masih berguna setahun kemudian.

Alasan menggunakan PBS, bukan menyalin file vzdump ke disk sewaan, adalah chunk store. Client membagi setiap disk guest menjadi chunk berukuran sekitar 4 MiB, menghitung hash-nya, lalu hanya mengunggah chunk yang belum ada di datastore. Untuk virtual machine yang sedang berjalan, QEMU melacak block yang berubah dalam dirty bitmap setelah backup pertama. Karena itu, proses berikutnya hanya membaca block tersebut dari disk lokal. Guest berukuran 200 GB yang berubah sebesar 3 GB per hari akan mengirim sekitar 3 GB per hari. Mekanisme inilah yang memungkinkan uplink rumah dan volume sewaan digunakan bersama. Itu juga alasan VPS sebagai target backup di luar lokasi lebih baik daripada drive cadangan di rumah teman. Jika Anda masih menentukan lokasi hypervisor, Proxmox di rumah dibandingkan VPS sewaan membahas pertanyaan tersebut secara terpisah.

Tentukan ukuran volume sebelum menyewanya

Menentukan ukuran adalah perhitungan menggunakan angka Anda sendiri. Gunakan ruang yang benar-benar dipakai setiap guest, bukan ukuran disk virtualnya, lalu tambahkan perubahan per hari dikalikan jumlah hari penyimpanan. Kompresi dan deduplikasi sama-sama mengurangi angka tersebut, jadi anggap hasilnya sebagai batas atas, bukan target.

[
  {
    "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 adalah contoh perhitungan, bukan hasil pengukuran. Baca ruang yang digunakan dari df -h di dalam setiap guest, lalu baca perubahan harian dari ukuran backup kedua dan ketiga pada log tugas PBS setelah keduanya tersedia.

Guest mail pada contoh menggunakan 120 GB dan berubah sekitar 3.0 GB per hari. Karena itu, tiga puluh snapshot harian memerlukan sekitar 210 GB: satu salinan penuh ditambah perubahan selama tiga puluh hari. Jumlahkan kolom terakhir untuk semua 3 guest. Totalnya sekitar 619 GB. Tambahkan seperlima untuk indeks, metadata, dan ruang kerja yang diperlukan garbage collection. Hasilnya mengarah pada volume berukuran 1 TB.

Bagian lain dari rencana ini sederhana. PBS dapat berjalan dengan RAM 2 GB dan bekerja nyaman dengan RAM 4 GB, karena pekerjaan yang membutuhkan banyak sumber daya berlangsung di sisi cluster: node Proxmox VE membaca disk guest serta melakukan chunking dan hashing. Tugas VPS adalah menulis chunk dan menjalankan dua pekerjaan berat, yaitu garbage collection dan verifikasi. Sewalah datastore sebagai block volume terpisah, bukan satu root disk berukuran besar. Dengan begitu, Anda dapat memperbesar volume nanti tanpa membangun ulang server.

Instal Proxmox Backup Server di Debian 13

Per Agustus 2026, pasangan versi yang berlaku adalah Proxmox Backup Server 4 pada Debian 13 dengan codename trixie. Panduan lama memasangkan PBS 2 dengan Debian 11. Codename merupakan bagian dari definisi repositori. Karena itu, menyalin nama suite lama akan menghasilkan error apt tentang release file yang tidak tersedia. Mulai dari image Debian 13 standar. Jalankan semua perintah di bawah ini sebagai root, atau gunakan sudo seperti yang ditulis.

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

Nilai checksum harus terbaca sebagai 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Jika tidak, hentikan proses. Keyring yang salah berarti Anda akan menginstal paket yang ditandatangani oleh pihak yang belum Anda verifikasi.

Tulis /etc/apt/sources.list.d/pbs.sources dengan repositori no-subscription. Repositori ini sesuai untuk server tanpa kontrak dukungan:

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

Antarmuka web tersedia pada port HTTPS 8007. Login sebagai root@pam menggunakan password root sistem, karena PBS mengautentikasi pengguna tersebut melalui PAM (pluggable authentication modules), yaitu akun yang sama dengan yang digunakan sistem operasi. Sertifikatnya ditandatangani sendiri, dan browser akan memberi tahu Anda tentang hal itu. Fingerprint sertifikat tersebut adalah nilai yang nantinya dipasang oleh Proxmox VE, sehingga peringatan ini memang diharapkan dan bukan masalah yang perlu diperbaiki.

Port 8007 menyediakan formulir login di Internet publik, jadi jangan membukanya untuk semua alamat. Satu file nftables dapat mencakup aturan ini. Menulis /etc/nftables.conf akan mengosongkan ruleset saat ini. Karena itu, lewati langkah ini jika ada komponen lain yang sudah mengelola firewall pada server 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
  }
}

Terapkan aturan tersebut dengan sudo systemctl enable --now nftables. Biarkan sesi SSH kedua tetap terbuka saat melakukannya: policy drop ditambah satu kesalahan ketik pada aturan SSH dapat mengunci Anda dari server sendiri. Ganti 203.0.113.7 dengan alamat asal koneksi cluster Anda. Jika alamat tersebut dinamis, perluas aturan agar mencakup rentang milik provider Anda atau akhiri koneksi melalui tunnel. Ingat bahwa sebagian besar panel VPS memiliki firewall jaringan terpisah di depan mesin. Firewall tersebut juga harus mengizinkan port yang sama.

Tempatkan datastore pada volume tersendiri

Datastore tidak boleh berada di filesystem root. Jika datastore memenuhi filesystem root yang digunakan bersama, pencadangan gagal dan layanan lain pada server juga gagal, termasuk logging yang diperlukan untuk mencari penyebabnya. Pasang volume blok, format volume tersebut, mount, lalu buat datastore di dalam mount point.

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

Ambil nama device dari lsblk. Pada sebagian besar image KVM, namanya adalah /dev/vdb, sedangkan pada image lain namanya /dev/sdb. Jangan pernah menganggap namanya selalu sama. Tambahkan mount ke /etc/fstab berdasarkan label agar perubahan nama device setelah reboot tidak mengarahkan datastore ke disk 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 harus menampilkan device, path, dan opsi yang mencakup rw,relatime. Ada dua kegagalan yang tersembunyi dalam satu baris tersebut. Jika mount belum tersedia tetapi datastore tetap dibuat, PBS menulis ke filesystem root di bawah mount point. Mount yang berhasil pada boot berikutnya akan menyembunyikan data tersebut tanpa menghapusnya. Akibatnya, datastore terlihat kosong, sedangkan filesystem root tetap penuh. Jika opsinya menyatakan noatime, PBS menolak bekerja karena PBS menjalankan pemeriksaan keamanan access time saat datastore dibuat dan setiap kali garbage collection dijalankan.

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

Perintah tersebut membuat direktori .chunks yang berisi 65536 subdirektori, dengan nama 0000 hingga ffff. Datastore terdiri atas ratusan ribu file kecil, bukan beberapa file besar. Ada dua konsekuensinya. Menyalin datastore dengan tool biasa pada tingkat file terlalu lambat untuk digunakan. Selain itu, snapshot volume dari provider yang diambil saat pencadangan berjalan bukan salinan datastore yang konsisten. Ini adalah alasan yang sama dengan snapshot tidak menggantikan pencadangan di bagian lain.

Namespace mencegah dua host saling bertabrakan

Datastore secara default bersifat datar. Backup diberi nama vm/100, ct/101, dan host/<name>. Dua cluster yang masing-masing memiliki guest dengan ID 100 menulis ke group yang sama. Snapshot keduanya saling tercampur, dan aturan retensi yang ditulis untuk salah satunya turut menghitung snapshot milik yang lain. Namespace memberi setiap sumber tree tersendiri di dalam satu datastore.

Buat namespace tersebut pada host PBS. Argumen --repository berbentuk [[auth-id@]server[:port]:]datastore. Jadi, namespace lokal ditulis sebagai root@pam@localhost:store1, dan perintah tersebut meminta kata sandi 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'

Deduplicaton tidak terpengaruh oleh pemisahan ini. Chunk digunakan bersama di seluruh datastore. Jadi, sepuluh guest Debian yang tersebar di tiga namespace tetap hanya menyimpan satu salinan sistem dasar. Inilah alasan menggunakan satu datastore dengan namespace, bukan satu datastore untuk setiap host: datastore yang terpisah berarti pool chunk yang terpisah, dan pool chunk yang terpisah berarti instalasi Debian yang sama harus dibayar beberapa kali.

Berikan setiap sumber akun sendiri dan batasi cakupannya ke namespace miliknya. Token API (application programming interface) adalah kredensial milik seorang pengguna dan memiliki izin sendiri. Inilah yang diperlukan 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'

Perintah token mencetak secret tepat satu kali:

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

Salin secret tersebut sekarang karena PBS tidak menyimpan bentuk apa pun yang dapat ditampilkan lagi. Periksa perintah access control tersebut dua kali. Perintah itu menyebut token, backup@pbs!pve-home, bukan pengguna, karena izin token hanya dihitung dari entri yang menyebut token itu sendiri. Entri yang hanya menyebut backup@pbs membuat token tidak memiliki akses sama sekali. Akibatnya, backup pertama gagal karena izin, bukan karena masalah yang terlihat pada jaringan. Path juga sama pentingnya: token yang dibatasi ke /datastore/store1/pve-home tidak dapat membaca atau menghapus apa pun di namespace kantor. Dengan demikian, satu cluster yang dibobol tidak dapat menghancurkan riwayat situs lain.

Tambahkan VPS sebagai penyimpanan cadangan di Proxmox VE

Baca sidik jari sertifikat pada host PBS terlebih dahulu.

sudo proxmox-backup-manager cert info | grep Fingerprint

Kemudian, pada node mana pun dalam 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

Tempelkan nilai cert info yang dicetak, sebagai pengganti placeholder pada baris ketiga. Menjalankan --password tanpa nilai akan membuat pvesm memintanya, sehingga rahasia token tidak tersimpan dalam riwayat shell Anda. Nilai tersebut disimpan di /etc/pve/priv/storage/pbs-offsite.pw, sedangkan definisi storage disimpan di /etc/pve/storage.cfg. Berkas ini direplikasi ke setiap node dalam cluster, sehingga Anda cukup mengonfigurasikannya satu kali untuk seluruh cluster.

--prune-backups keep-all=1 memberi tahu Proxmox VE agar tidak menghapus apa pun. Retensi dikonfigurasi di sisi PBS, yang dibahas lebih lanjut di bawah. Alasannya perlu dinyatakan dengan jelas: token tersebut tidak memerlukan izin untuk menghapus, sehingga cluster yang dienkripsi ransomware tidak dapat mengakses dan memangkas riwayat offsite yang seharusnya digunakan untuk memulihkannya.

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

pvesm status menampilkan active pada kolom status, dengan total dan ruang terpakai datastore di sebelahnya. inactive berarti node tidak dapat menyelesaikan sesi TLS (transport layer security) ke port 8007. Ini menunjukkan masalah firewall atau sidik jari, bukan masalah kredensial.

Pencadangan pertama mengunggah semua data, jadi hitung estimasinya sebelum memulainya. 200 GB setara dengan 1600 gigabit, sedangkan uplink 100 Mbit mentransfer 0.1 gigabit per detik. Jadi, waktu minimumnya sekitar empat setengah jam, dan waktu sebenarnya akan lebih lama. Mulai pencadangan saat bandwidth tidak sedang diperlukan. Setiap proses berikutnya hanya mengirim chunk baru.

Lokasi enkripsi sisi klien dan kunci

VPS adalah komputer yang tidak Anda miliki. Lakukan enkripsi di sisi klien agar datastore hanya menyimpan potongan data yang tidak dapat dibaca oleh penyedia.

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

Perintah tersebut menulis kunci baru ke /etc/pve/priv/storage/pbs-offsite.enc. File itu hanya dapat dibaca oleh root dan direplikasi bersama seluruh isi /etc/pve. Mulai backup berikutnya, klien mengenkripsi setiap potongan data sebelum mengirimkannya. Server tetap dapat mencantumkan snapshot dan ukurannya, tetapi tidak dapat membaca isinya.

Bagian ini menentukan apakah mekanisme tersebut benar-benar menjadi backup, bukan sumber risiko. Kunci yang dibuat tidak memiliki passphrase dan hanya ada pada cluster yang dilindunginya. Jika cluster tersebut dicuri atau dienkripsi oleh pihak lain, VPS akan menyimpan data yang tidak dapat dibuka oleh siapa pun. Salin kunci ke luar cluster pada hari kunci itu dibuat.

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 ditujukan untuk dicetak di kertas dan disimpan di tempat lain. Perlakukan file tersebut sebagai rahasia, karena siapa pun yang memilikinya dapat mendekripsi setiap backup yang dibuat dengan kunci itu. Untuk setup yang lebih besar, PBS juga mendukung master key, yaitu pasangan kunci RSA (Rivest Shamir Adleman) yang dibuat dengan proxmox-backup-client key create-master-key. Setiap backup menyimpan kunci enkripsinya sendiri yang dienkripsi menggunakan bagian publik, sedangkan bagian privat tetap offline untuk pemulihan.

Salah satu konsekuensi desain ini perlu diketahui sebelum Anda memulai, bukan setelahnya. Pada backup terenkripsi, digest potongan data dihitung dari konten teks biasa yang digabungkan dengan kunci enkripsi. Karena itu, dua potongan data identik yang dienkripsi menggunakan kunci berbeda menghasilkan digest berbeda dan tidak pernah dideduplikasi satu sama lain. Mengubah kunci berarti backup berikutnya akan mengunggah ulang seluruh data. Potongan data lama tetap tersimpan sampai snapshot-nya dipangkas dan dikumpulkan. Tentukan penggunaan enkripsi sebelum upload pertama.

Penanda prune, garbage collection mereklamasi ruang

Ini adalah bagian yang sering dilewati, padahal bagian inilah yang memenuhi volume. Prune pada snapshot menghapus metadatanya: manifest, indeks, log, dan catatan. Proses ini sama sekali tidak menghapus chunk. Chunk digunakan bersama oleh beberapa snapshot, sehingga tidak ada proses yang dapat mengetahui bahwa sebuah chunk tidak digunakan sampai semua indeks yang tersisa dibaca. Itulah tugas garbage collection. Datastore yang memiliki jadwal prune tetapi tidak memiliki jadwal garbage collection hanya akan terus bertambah besar.

Atur keduanya. Atur retensi terlebih dahulu, dengan satu job untuk 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 atur jadwal collection pada datastore, beberapa jam setelah job prune dan di luar waktu pencadangan:

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

Buktikan perbedaannya sekali pada host PBS:

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

Jalankan job prune, lalu df. Nilai penggunaan tidak berubah. Jalankan garbage collection, lalu df lagi. Nilai tersebut berubah.

Garbage collection berjalan dalam dua fase. Fase pertama membaca setiap indeks dalam datastore dan memperbarui waktu akses setiap chunk yang dirujuk oleh indeks tersebut. Fase kedua menghapus chunk yang waktu aksesnya lebih lama daripada batas waktu. Batas ini adalah 24 hours dan 5 minutes sebelum proses dimulai, atau waktu mulai backup tertua yang masih ditulis, mana pun yang lebih awal. Margin tersebut diperlukan karena Linux memasang filesystem dengan relatime secara default. Opsi ini memperbarui waktu akses kira-kira sekali sehari, bukan pada setiap pembacaan. Karena itu, chunk yang ditulis satu jam lalu tidak pernah dihapus meskipun belum ada indeks yang merujuknya. Ruang yang dibebaskan oleh prune akan terlihat pada collection pertama yang berjalan lebih dari satu hari setelah chunk terakhir disentuh. Datastore yang tampak tidak mereklamasi ruang sering kali hanya masih berada dalam periode tersebut.

Pada VPS kecil, ini adalah job terberat yang dijalankan server karena proses ini memeriksa setiap file chunk pada volume. Log task diakhiri dengan ringkasan item yang dihapus dan item yang masih tertunda karena grace period. Jika banyak item masih tertunda, jalankan kembali proses tersebut pada hari berikutnya. PBS menyediakan gc-atime-safety-check dan gc-atime-cutoff sebagai opsi tuning datastore. Biarkan keduanya pada nilai default. Opsi tersebut ditujukan untuk storage yang tidak dapat mencatat waktu akses. Menonaktifkan pemeriksaan keamanan pada filesystem yang dipasang dengan noatime dapat menghapus chunk yang masih dirujuk oleh snapshot aktif.

Verifikasi membuktikan bahwa chunk masih dapat dibaca

Backup yang berhasil diunggah tanpa error tetap dapat menjadi tidak terbaca setahun kemudian. Verifikasi membaca ulang chunk dan membandingkannya dengan checksum yang tersimpan dalam indeks. Dengan demikian, kerusakan ditemukan sesuai jadwal, bukan saat proses restore.

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

Gunakan jumlah thread yang rendah pada VPS kecil. Verifikasi dibatasi oleh disk dan CPU. Jika tidak, proses ini akan bersaing dengan aktivitas lain pada server. Untuk menjadwalkannya, gunakan tab Verify Jobs pada antarmuka web datastore. Job mingguan yang melewati snapshot yang sudah diverifikasi dan memverifikasi ulang snapshot yang berusia lebih dari 30 hari akan mencakup seluruh datastore secara berkala tanpa mengulangi pekerjaan.

Snapshot yang gagal diverifikasi ditandai sebagai gagal dalam tampilan datastore. Jangan abaikan kegagalan tersebut. Chunk digunakan bersama, sehingga satu chunk yang rusak dari base image biasanya membuat setiap snapshot yang merujuk padanya gagal. Untuk memperbaikinya, lupakan snapshot yang gagal lalu jalankan backup baru. Proses ini akan mengunggah kembali chunk yang hilang. Jika kegagalan terus muncul, curigai storage yang mendasari datastore. Siapkan pemantauan kesehatan disk pada VPS agar drive memberi tahu Anda sebelum job verifikasi mendeteksi masalah.

Uji pemulihan, lalu uji tanpa cluster

Anda tidak akan tahu bahwa backup dapat digunakan sampai Anda memulihkan salah satunya. Kedua pengujian ini memeriksa hal yang berbeda.

Guest secara keseluruhan, pada cluster:

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

Kolom pertama pvesm list adalah ID volume, dan timestamp merupakan bagian dari ID tersebut. Karena itu, salin nilai milik Anda, bukan mengetik contoh di atas. Lakukan pemulihan ke ID guest yang belum digunakan dan storage yang berbeda, lalu jalankan guest dengan antarmuka jaringan terputus. Jangan pernah menimpa guest yang sedang berjalan untuk memeriksa apakah backup berfungsi. Jika pemulihan gagal di tengah proses, salinan yang masih berfungsi juga akan hilang.

Pengujian kedua adalah pengujian yang hampir tidak pernah dilakukan. Anggap gedung tempat cluster berada sudah tidak dapat digunakan, lalu lakukan pemulihan dari mesin yang sebelumnya tidak pernah menjadi bagian dari cluster tersebut. Pada mesin Debian 13 mana pun, tambahkan repository khusus client 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

Ganti tiga placeholder dalam tanda kutip dengan nilai milik Anda, lalu ambil nama arsip pada baris terakhir dari output snapshot files. Ini membuktikan hal yang tidak dapat dibuktikan oleh pengujian pertama: salinan file key Anda dapat mendekripsi data nyata, dan Anda dapat mengoperasikan client dari mesin yang tidak pernah menyimpan konfigurasi cluster Anda. Catat empat nilai yang diperlukan, yaitu string repository, token secret, fingerprint, dan file key. Simpan semuanya bersama-sama di lokasi yang ditentukan oleh rencana pemulihan bencana Anda.

Fungsi deduplikasi terhadap biaya penyimpanan disk

Deduplikasi benar-benar berfungsi, dan prosesnya berlaku di seluruh datastore. Sepuluh guest Debian dapat berbagi satu salinan sistem dasar, sehingga biaya penyimpanan guest kedua yang identik hampir tidak ada. Deduplikasi juga menghemat bandwidth upload karena client mengirim checksum, bukan data, untuk setiap chunk yang sudah tersimpan di server.

Hal yang tidak dilakukan deduplikasi perlu dijelaskan dengan tegas.

• Deduplikasi tidak mengecilkan data yang berubah. Database yang menulis ulang sebagian besar filenya setiap malam akan menghasilkan chunk baru setiap malam, dan retensi akan menggandakannya.
• Deduplikasi tidak dapat melewati batas cryptographic key, seperti yang dijelaskan di atas.
• Deduplikasi tidak dapat melewati batas datastore. Inilah alasan utama penggunaan namespace.
• Deduplikasi tidak mencegah volume penuh. Saat datastore penuh, backup gagal. Pilihannya hanya menggunakan volume yang lebih besar atau mempersingkat retensi.

Jangan menambahkan lapisan deduplikasi lain di bawahnya. Chunk sudah tiba dalam kondisi dideduplikasi dan dikompresi oleh client. Karena itu, deduplikasi ZFS di bawah datastore hanya menggunakan RAM untuk mencari kecocokan yang sudah dihapus sebelum data ditulis. Gunakan ext4 atau xfs biasa pada volume.

Antarmuka web menampilkan faktor deduplikasi untuk datastore. Angka tersebut menggambarkan guest Anda. Angka itu juga satu-satunya angka yang layak digunakan untuk perencanaan, karena rasio yang dipublikasikan menggambarkan data milik orang lain. Jika Anda juga memerlukan backup tingkat file untuk mesin yang bukan guest Proxmox, jalankan backup tersebut secara bersamaan pada VPS yang sama: PBS adalah target yang memahami hypervisor untuk seluruh guest, sedangkan restic dan BorgBackup menargetkan direktori, dan backup restic ke VPS sesuai untuk laptop serta server mandiri yang sejak awal tidak ditujukan untuk dicakup oleh PBS.

Mode kegagalan dan hal yang akan terlihat

Storage berstatus inactive. pvesm status --storage pbs-offsite menampilkan inactive ketika node tidak dapat menyelesaikan sesi TLS ke port 8007. Periksa firewall pada VPS, kemudian firewall jaringan terpisah milik provider, lalu fingerprint. Fingerprint yang tidak lagi cocok dengan sertifikat menimbulkan tampilan yang sama seperti port yang diblokir, dan berubah setiap kali sertifikat tersebut diganti.

Backup pertama gagal karena masalah permission. Entri access control harus mencantumkan token, bukan user, dan harus mencakup namespace yang dituju storage. Konfirmasikan keduanya pada tab permissions datastore di antarmuka web sebelum memeriksa bagian lain.

Garbage collection menolak untuk dijalankan. Pemeriksaan keamanan access time gagal. Ini hampir selalu berarti filesystem datastore di-mount dengan noatime. Jalankan findmnt -no OPTIONS /mnt/datastore/store1 untuk mengonfirmasi, perbaiki opsi tersebut di /etc/fstab, lalu lakukan remount. Jangan menonaktifkan pemeriksaan ini untuk melewatinya.

Datastore terus membesar. Job prune berjalan, tetapi tidak ada data yang direklamasi. Penyebabnya adalah tidak adanya jadwal garbage collection, atau setiap proses collection berlangsung dalam grace window 24 jam karena dijalankan segera setelah backup. Periksa jadwal dengan proxmox-backup-manager datastore show store1.

Backup yang sebelumnya cepat kini memerlukan waktu berjam-jam. Guest yang dihentikan, dimigrasikan, atau dipulihkan akan kehilangan dirty bitmap. Akibatnya, proses berikutnya membaca seluruh disk pada sisi cluster meskipun data yang di-upload sangat sedikit. Log task menunjukkan durasi yang panjang dengan angka upload yang kecil, lalu proses berikutnya kembali cepat. Jika setiap job pada VPS juga lambat, penyebabnya biasanya berada di luar datastore. CPU steal time dari noisy neighbour adalah hal pertama yang perlu diukur.

FAQ

Mengapa datastore Proxmox Backup Server saya terus bertambah besar saat tugas prune berjalan?

Karena prune hanya menghapus metadata snapshot: manifest, indeks, log, dan catatan. Chunk tetap berada di disk hingga garbage collection menghapus chunk yang tidak lagi dirujuk oleh indeks mana pun. Berikan jadwal kepada datastore menggunakan proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27', lalu buktikan dengan menjalankan df -h pada path datastore sebelum dan sesudah proxmox-backup-manager garbage-collection start store1. Perkirakan jeda setidaknya satu hari, karena fase kedua hanya menghapus chunk yang waktu aksesnya lebih lama dari 24 jam 5 menit.

Berapa banyak disk yang dibutuhkan VPS Proxmox Backup Server?

Jumlahkan ruang yang benar-benar digunakan setiap guest, lalu tambahkan perubahan harian setiap guest dikalikan dengan jumlah hari penyimpanan. Total tersebut merupakan batas atas, karena kompresi dan deduplikasi sama-sama mengurangi kebutuhan ruang. Tambahkan sekitar seperlima untuk indeks dan ruang kerja, lalu bulatkan ke atas agar sesuai dengan ukuran volume yang dapat dibeli. Periksa kembali setelah dua minggu berdasarkan penggunaan aktual pada tampilan datastore, karena perkiraan sebelum backup pertama selalu meleset ke salah satu arah.

Di mana kunci enkripsi backup harus disimpan?

Simpan di mana saja, tetapi jangan hanya pada cluster yang dilindunginya. Proxmox VE menyimpannya di /etc/pve/priv/storage/<storage>.enc, yang direplikasi ke setiap node dan karena itu akan hilang bersama cluster. Salin kunci tersebut sejak hari pertama, cetak menggunakan proxmox-backup-client key paperkey, dan simpan salinannya di gedung yang berbeda. Perhatikan juga bahwa kunci ikut digunakan dalam digest chunk, sehingga penggantiannya nanti menyebabkan backup berikutnya mengunggah semuanya kembali.

Apakah saya memerlukan satu datastore per host Proxmox, atau namespace?

Gunakan satu datastore dan satu namespace untuk setiap host sumber atau cluster. Deduplikasi bekerja di seluruh datastore, bukan antar-datastore. Jadi, pemisahan berdasarkan host akan menyimpan image dasar yang sama beberapa kali. Namespace memisahkan grup backup, sehingga dua host yang sama-sama memiliki guest dengan ID 100 tidak dapat saling bertabrakan. Path kontrol akses berbentuk /datastore/store1/pve-home membatasi token API setiap host ke namespace miliknya sendiri.

Apakah VPS kecil dapat menangani tugasnya sebagai server backup Proxmox?

Biasanya dapat, untuk homelab, karena proses chunking dan hashing berlangsung pada node Proxmox VE, bukan pada server backup. VPS menulis chunk dan menjalankan dua tugas berat, yaitu garbage collection dan verifikasi. Sediakan RAM 4 GB dan pertahankan jumlah thread verifikasi tetap rendah. Jadwalkan kedua tugas tersebut di luar jendela backup. Jika keduanya masih memerlukan waktu jauh lebih lama daripada yang seharusnya diperlukan disk, ukur steal time sebelum membeli paket yang lebih besar.