VPS वर Proxmox Backup Server कसे सेट करावे?

VPS वर Proxmox Backup Server वापरण्याचे फायदे

VPS वर Proxmox Backup Server (PBS) असणे म्हणजे एक ऑफसाइट बॅकअप टार्गेट असणे, जे तुमच्या Proxmox VE (virtual environment) क्लस्टरशी सुसंगत प्रोटोकॉल वापरते. यामुळे पहिल्या बॅकअप नंतरचे सर्व बॅकअप हे इंक्रीमेंटल (incremental) असतात, सर्व गेस्ट्समध्ये डीड्युप्लिकेटेड (deduplicated) असतात, तुमच्या ठिकाणाहून बाहेर पडण्यापूर्वी एनक्रिप्टेड (encrypted) असतात आणि त्यानंतर त्यांची पडताळणी (verifiable) केली जाते. तुम्ही ब्लॉक व्हॉल्यूमसह एक VPS भाड्याने घेता, त्यावर Debian 13 वर PBS इन्स्टॉल करता, त्या व्हॉल्यूमवर एक डेटास्टोअर तयार करता आणि Proxmox VE मध्ये ते pbs प्रकारातील स्टोरेज म्हणून जोडता. हे इन्स्टॉलेशन दहा मिनिटांत पूर्ण होते. त्यानंतरच्या सर्व गोष्टी, जसे की namespaces, garbage collection, key custody आणि तुम्ही प्रत्यक्षात करून पाहिलेला रिस्टोर, यावरूनच ठरते की एक वर्षानंतर तुमचा बॅकअप किती उपयुक्त ठरेल.

भाड्याने घेतलेल्या डिस्कवर vzdump फाइल्स कॉपी करण्याऐवजी PBS वापरण्याचे मुख्य कारण म्हणजे 'चंक स्टोअर' (chunk store). क्लायंट प्रत्येक गेस्ट डिस्कचे सुमारे 4 MiB च्या चंक्समध्ये विभाजन करतो, त्यांचे हॅश (hashes) तयार करतो आणि फक्त तेच चंक्स अपलोड करतो जे डेटास्टोअरमध्ये आधीपासून उपलब्ध नाहीत. चालू असलेल्या व्हर्च्युअल मशीनसाठी, पहिल्या बॅकअप नंतर QEMU एका 'डर्टी बिटमॅप' (dirty bitmap) मध्ये बदललेले ब्लॉक्स ट्रॅक करते, त्यामुळे पुढच्या वेळी फक्त तेच ब्लॉक्स स्थानिक डिस्कवरून वाचले जातात. दररोज 3 GB बदल होणारा 200 GB चा गेस्ट दररोज फक्त 3 GB डेटा पाठवतो. यामुळेच होम अपलिंक आणि भाड्याने घेतलेले व्हॉल्यूम एकत्र प्रभावीपणे काम करू शकतात आणि म्हणूनच ऑफसाइट बॅकअप टार्गेट म्हणून VPS हे मित्राच्या घरी ठेवलेल्या अतिरिक्त ड्राइव्हपेक्षा अधिक सरस ठरते. जर तुम्ही अजूनही हायपरवायझर कुठे असावा याचा विचार करत असाल, तर घरी Proxmox विरुद्ध भाड्याने घेतलेला VPS या विषयावर स्वतंत्रपणे चर्चा केली आहे.

भाड्याने घेण्यापूर्वी व्हॉल्यूमचा आकार निश्चित करा

आकाराचे गणित हे तुम्ही स्वतःच्या आकड्यांवर करायचे असते. प्रत्येक गेस्ट प्रत्यक्ष किती जागा वापरतो ते पहा, त्याच्या व्हर्च्युअल डिस्कचा आकार नाही. त्यानंतर, दररोज होणारा बदल आणि तुम्ही किती दिवस बॅकअप ठेवणार आहात, यांचा गुणाकार करून त्यात मिळवा. कॉम्प्रेशन (compression) आणि डीड्युप्लिकेशन (deduplication) मुळे ही आकडेवारी सुधारते, त्यामुळे मिळालेल्या निकालाला कमाल मर्यादा (ceiling) समजा, उद्दिष्ट नाही.

[
  {
    "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 वापरून वापरलेली जागा तपासा. एकदा बॅकअप तयार झाल्यावर, PBS टास्क लॉगमध्ये दुसऱ्या आणि तिसऱ्या बॅकअपच्या आकारावरून दररोज होणारा बदल तपासा.

उदाहरणातील मेल गेस्ट 120 GB जागा वापरतो आणि दररोज सुमारे 3.0 GB बदल होतो. त्यामुळे तीस दिवसांच्या स्नॅपशॉट्ससाठी साधारणपणे 210 GB जागा लागेल: एक पूर्ण प्रत आणि तीस दिवसांचा बदल. सर्व 3 गेस्टसाठी शेवटच्या कॉलमची बेरीज करा, जी सुमारे 619 GB येते. इंडेक्स, मेटाडेटा आणि गार्बेज कलेक्शनसाठी लागणारी अतिरिक्त जागा म्हणून यात आणखी एक पंचमांश (one-fifth) जागा मिळवा, ज्यामुळे 1 TB व्हॉल्यूमची गरज स्पष्ट होते.

उर्वरित प्लॅनसाठी कमी संसाधने लागतात. PBS ला 2 GB RAM पुरेशी असते आणि 4 GB मध्ये ते उत्तम चालते, कारण मुख्य काम क्लस्टरच्या बाजूला होते: Proxmox VE नोड गेस्ट डिस्क वाचतो आणि त्याचे चंकिंग (chunking) व हॅशिंग (hashing) करतो. VPS चे काम फक्त चंक्स लिहिणे आणि दोन महत्त्वाची कामे करणे आहे: गार्बेज कलेक्शन आणि व्हेरिफिकेशन. डेटास्टोरला एका मोठ्या रूट डिस्कऐवजी स्वतंत्र ब्लॉक व्हॉल्यूम म्हणून भाड्याने घ्या, कारण भविष्यात सर्व्हर पुन्हा तयार न करता तुम्ही व्हॉल्यूमचा आकार वाढवू शकता.

Debian 13 वर Proxmox Backup Server इन्स्टॉल करणे

ऑगस्ट 2026 पर्यंत, सध्याची जोडी Proxmox Backup Server 4 आणि Debian 13 (कोडनेम trixie) अशी आहे. जुन्या मार्गदर्शिकांमध्ये PBS 2 आणि Debian 11 ची जोडी वापरली आहे आणि कोडनेम हे रिपॉझिटरी व्याख्येचा भाग असल्याने, जुन्या सुटचे नाव वापरल्यास apt कडून 'missing release file' अशी त्रुटी येते. एका कोऱ्या 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 चा अर्थ असा की तुम्ही अशा पॅकेजेस इन्स्टॉल करत आहात ज्यांची स्वाक्षरी तुम्ही तपासलेली नाही.

ज्या सर्व्हरकडे सपोर्ट कॉन्ट्रॅक्ट नाही, त्यांच्यासाठी योग्य असलेली no-subscription रिपॉझिटरी /etc/apt/sources.list.d/pbs.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

वेब इंटरफेस HTTPS पोर्ट 8007 वर उपलब्ध होतो. root@pam म्हणून सिस्टिमच्या root पासवर्डसह लॉग इन करा, कारण PBS त्या वापरकर्त्याचे प्रमाणीकरण PAM (pluggable authentication modules) द्वारे करते, जे ऑपरेटिंग सिस्टिम वापरते तेच खाते येथे वापरले जाते. हे प्रमाणपत्र self-signed असल्याने तुमचा ब्राउझर तशी सूचना देईल. त्या प्रमाणपत्राची फिंगरप्रिंट हीच Proxmox VE नंतर पिन करते, त्यामुळे ही चेतावणी अपेक्षित आहे, ती दुरुस्त करण्याची समस्या नाही.

पोर्ट 8007 हे सार्वजनिक इंटरनेटवर एक लॉगिन फॉर्म आहे, त्यामुळे ते सर्वांसाठी खुले ठेवू नका. एक nftables फाईल यासाठी पुरेशी आहे. /etc/nftables.conf लिहिल्याने सध्याचे नियम flushed (पुसले) होतात, त्यामुळे जर या मशीनवर फायरवॉलचे व्यवस्थापन इतर कशाद्वारे होत असेल, तर ही पायरी वगळा.

#!/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 सत्र सुरू ठेवा: policy drop आणि SSH नियमात एक टायपो (चुकीचा शब्द) तुम्हाला तुमच्याच सर्व्हरपासून लॉक करू शकतो. 203.0.113.7 च्या जागी तुमच्या क्लस्टरचा पत्ता लिहा. जर तो पत्ता डायनॅमिक असेल, तर तो नियम तुमच्या प्रोव्हायडरच्या रेंजपर्यंत वाढवा किंवा टनेलद्वारे कनेक्शन पूर्ण करा. लक्षात ठेवा की बहुतेक VPS पॅनेलमध्ये मशीनच्या समोर एक स्वतंत्र नेटवर्क फायरवॉल असते, ज्यामध्ये त्याच पोर्टला परवानगी देणे आवश्यक आहे.

डेटास्टोअर स्वतंत्र व्हॉल्यूमवर ठेवा

डेटास्टोअर रूट फाइलसिस्टमवर नसावा. जेव्हा डेटास्टोअर सामायिक रूट फाइलसिस्टम पूर्ण भरतो, तेव्हा बॅकअप अयशस्वी होतो आणि सर्व्हरवरील इतर सर्व गोष्टीही बंद पडतात, ज्यामध्ये समस्या शोधण्यासाठी आवश्यक असलेले लॉगिंग देखील समाविष्ट आहे. ब्लॉक व्हॉल्यूम जोडा, तो फॉरमॅट करा, माउंट करा आणि त्यानंतरच माउंट पॉइंटच्या आत डेटास्टोअर तयार करा.

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

डिव्हाइसचे नाव lsblk वरून घ्या. बहुतेक KVM इमेजेसवर हे /dev/vdb असते आणि इतरांवर /dev/sdb असते, त्यामुळे गृहीत धरणे कधीही सुरक्षित नसते. माउंटला लेबलद्वारे /etc/fstab मध्ये जोडा, जेणेकरून रीबूटनंतर डिव्हाइसचे नाव बदलल्यास डेटास्टोअर चुकीच्या डिस्ककडे निर्देश करणार नाही:

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 ने डिव्हाइस, पाथ आणि rw,relatime सह इतर पर्याय दर्शवले पाहिजेत. त्या एका ओळीत दोन त्रुटी लपलेल्या असतात. जर माउंट तिथे नसेल आणि तुम्ही तरीही डेटास्टोअर तयार केला, तर PBS माउंट पॉइंटच्या खाली रूट फाइलसिस्टममध्ये डेटा लिहितो आणि पुढच्या वेळी यशस्वी माउंट झाल्यावर तो डेटा हटवला न जाता लपवला जातो: अशा वेळी डेटास्टोअर रिकामा दिसतो आणि रूट फाइलसिस्टम पूर्ण भरलेलीच राहते. जर पर्यायांमध्ये noatime असेल, तर PBS काम करण्यास नकार देतो, कारण डेटास्टोअर तयार करताना आणि प्रत्येक गार्बेज कलेक्शनच्या वेळी तो access time ची सुरक्षा तपासणी करतो.

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

हे एक .chunks डिरेक्टरी तयार करते ज्यामध्ये 65536 सबडिरेक्टरीज असतात, ज्यांची नावे 0000 ते ffff अशी असतात. डेटास्टोअरमध्ये काही मोठ्या फाइल्स नसून लाखो लहान फाइल्स असतात. यातून दोन गोष्टी स्पष्ट होतात. सामान्य फाइल-लेव्हल टूल वापरून डेटास्टोअर कॉपी करणे इतके संथ असते की ते निरुपयोगी ठरते, आणि बॅकअप सुरू असताना घेतलेला प्रोव्हायडर व्हॉल्यूम स्नॅपशॉट ही त्याची सुसंगत प्रत नसते, हेच कारण आहे की स्नॅपशॉट्स बॅकअपची जागा घेऊ शकत नाहीत.

Namespaces दोन होस्टना एकमेकांशी संघर्ष करण्यापासून रोखतात

डेटास्टोअर डीफॉल्टनुसार फ्लॅट असतो. बॅकअप्सना vm/100, ct/101 आणि host/<name> अशी नावे दिली जातात. जर दोन क्लस्टर्समधील प्रत्येकी एका गेस्टचा ID 100 असेल, तर ते एकाच ग्रुपमध्ये लिहितात, त्यांचे स्नॅपशॉट्स एकमेकांत मिसळतात आणि एकासाठी लिहिलेला रिटेंशन नियम दुसऱ्याच्या स्नॅपशॉट्सवर लागू होतो. Namespaces प्रत्येक सोर्सला एकाच डेटास्टोअरमध्ये स्वतःचे स्वतंत्र ट्री (tree) देतात.

ते PBS होस्टवर तयार करा. --repository आर्ग्युमेंटचे स्वरूप [[auth-id@]server[:port]:]datastore असे असते, त्यामुळे स्थानिक आर्ग्युमेंट root@pam@localhost:store1 असे वाचले जाते आणि कमांड रूट पासवर्ड विचारते.

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) संपूर्ण डेटास्टोअरमध्ये शेअर केले जातात, त्यामुळे तीन namespaces मध्ये पसरलेले दहा Debian गेस्ट्स बेस सिस्टमची एकच प्रत साठवतात. प्रति होस्ट एक डेटास्टोअर करण्यापेक्षा namespaces सह एकच डेटास्टोअर वापरण्याचे हेच मुख्य कारण आहे: स्वतंत्र डेटास्टोअर्स म्हणजे स्वतंत्र चंक पूल्स, आणि स्वतंत्र चंक पूल्स म्हणजे एकाच Debian इन्स्टॉलसाठी अनेकदा जागा खर्च करणे.

प्रत्येक सोर्सला त्याचे स्वतःचे खाते द्या, जे त्याच्या स्वतःच्या namespace पुरते मर्यादित असेल. API (application programming interface) टोकन हे वापरकर्त्याशी संबंधित क्रेडेंशियल असते आणि त्याला स्वतःचे परवानग्यांचे अधिकार असतात, जे चोरीला जाण्याची शक्यता असलेल्या मशीनसाठी आवश्यक असतात.

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'

टोकन कमांड सिक्रेट (secret) फक्त एकदाच प्रिंट करते:

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

ते आताच कॉपी करा, कारण PBS कडे त्याची अशी कोणतीही प्रत नसते जी ते तुम्हाला पुन्हा दाखवू शकेल. ॲक्सेस कंट्रोल कमांड दोनदा तपासा. ती टोकनचे नाव, backup@pbs!pve-home, वापरते, वापरकर्त्याचे नाव नाही, कारण टोकनच्या परवानग्या केवळ टोकनच्या नावाचा उल्लेख असलेल्या नोंदींवरूनच मोजल्या जातात. केवळ backup@pbs साठीची नोंद टोकनला कोणताही ॲक्सेस देत नाही आणि अशा वेळी पहिला बॅकअप नेटवर्कमधील कोणत्याही त्रुटीपेक्षा परवानग्यांच्या त्रुटीमुळे (permissions) अयशस्वी होतो. पाथ (path) तितकाच महत्त्वाचा आहे: /datastore/store1/pve-home साठी मर्यादित असलेले टोकन office namespace मधील कोणतीही गोष्ट वाचू किंवा हटवू शकत नाही, त्यामुळे एक कॉम्प्रमाइज झालेला क्लस्टर दुसऱ्या साइटचा इतिहास नष्ट करू शकत नाही.

Proxmox VE मध्ये बॅकअप स्टोरेज म्हणून VPS जोडा

प्रथम 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 तुम्हाला ती विचारते, ज्यामुळे टोकन सीक्रेट तुमच्या शेल हिस्ट्रीमध्ये राहत नाही. हे /etc/pve/priv/storage/pbs-offsite.pw मध्ये साठवले जाते आणि स्टोरेजची व्याख्या स्वतः /etc/pve/storage.cfg मध्ये जाते, जी क्लस्टरमधील प्रत्येक नोडवर रेप्लिकेट केली जाते, त्यामुळे तुम्ही हे संपूर्ण क्लस्टरसाठी एकदाच कॉन्फिगर करता.

--prune-backups keep-all=1 Proxmox VE ला काहीही डिलीट न करण्याची सूचना देते. रिटेन्शन (Retention) हे PBS च्या बाजूने असते, ज्याबद्दल पुढे सविस्तर माहिती दिली आहे, आणि याचे एक स्पष्ट कारण आहे: अशा प्रकारे टोकनला डिलीट करण्याची परवानगी लागत नाही, त्यामुळे जर क्लस्टर रॅन्समवेअरमुळे एन्क्रिप्ट झाले, तर ते ऑफसाइट हिस्ट्रीपर्यंत पोहोचून ती नष्ट करू शकत नाही.

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

pvesm status स्टेटस कॉलममध्ये active प्रिंट करते, ज्याच्या बाजूला डेटास्टोअरची एकूण आणि वापरलेली जागा दिसते. inactive चा अर्थ असा की नोड पोर्ट 8007 वर TLS (transport layer security) सेशन पूर्ण करू शकला नाही; ही समस्या क्रेडेंशियलची नसून फायरवॉल किंवा फिंगरप्रिंटची असते.

पहिला बॅकअप सर्व डेटा अपलोड करतो, त्यामुळे सुरू करण्यापूर्वी हिशोब करून घ्या. 200 GB म्हणजे 1600 gigabits, आणि 100 Mbit अपलिंक प्रति सेकंद 0.1 gigabit डेटा हलवते, त्यामुळे किमान वेळ साडेचार तास लागते आणि प्रत्यक्ष वेळ त्यापेक्षा जास्त असू शकते. जेव्हा तुम्हाला बँडविड्थची गरज नसेल तेव्हाच हे सुरू करा. त्यानंतरच्या प्रत्येक रनमध्ये फक्त नवीन चंक्स (chunks) पाठवले जातात.

क्लायंट-साइड एन्क्रिप्शन आणि की (key) कुठे साठवली जाते

VPS हा असा संगणक आहे ज्याची मालकी तुमची नाही. त्यामुळे क्लायंटवरच डेटा एन्क्रिप्ट करा, जेणेकरून डेटास्टोअरमध्ये असे भाग (chunks) राहतील जे सर्व्हिस प्रोव्हायडर वाचू शकणार नाही.

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

हे कमांड /etc/pve/priv/storage/pbs-offsite.enc मध्ये एक नवीन की लिहिते, जी फक्त root वापरकर्ता वाचू शकतो आणि ती /etc/pve च्या उर्वरित भागासोबत रेप्लिकेट केली जाते. पुढच्या बॅकअपपासून, क्लायंट प्रत्येक चंक बाहेर पाठवण्यापूर्वी तो एन्क्रिप्ट करतो. सर्व्हर तुमच्या स्नॅपशॉट्सची यादी आणि त्यांचा आकार पाहू शकतो, परंतु तो त्यांची सामग्री वाचू शकत नाही.

आता तो भाग जो याला एक सुरक्षित बॅकअप बनवतो. तयार केलेल्या की ला कोणताही पासफ्रेज नसतो आणि ती फक्त ज्या क्लस्टरचे संरक्षण करते तिथेच अस्तित्वात असते. जर तो क्लस्टर चोरीला गेला किंवा दुसऱ्या कोणी तो एन्क्रिप्ट केला, तरी 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 मास्टर की ला देखील सपोर्ट करते. ही RSA (Rivest Shamir Adleman) की जोडी proxmox-backup-client key create-master-key वापरून तयार केली जाते, जिथे प्रत्येक बॅकअप स्वतःची एन्क्रिप्शन की पब्लिक की ने एन्क्रिप्ट करून साठवतो, तर प्रायव्हेट की रिकव्हरीसाठी ऑफलाइन ठेवली जाते.

या डिझाइनचा एक परिणाम सुरू करण्यापूर्वीच जाणून घेणे महत्त्वाचे आहे. एन्क्रिप्टेड बॅकअपसाठी, चंक डायजेस्ट (chunk digest) हा प्लेन टेक्स्ट आणि एन्क्रिप्शन की एकत्र करून मोजला जातो. त्यामुळे, वेगवेगळ्या की अंतर्गत एन्क्रिप्ट केलेले दोन सारखे चंक वेगवेगळे डायजेस्ट तयार करतात आणि ते एकमेकांसोबत डीड्युप्लिकेट (deduplicate) होत नाहीत. की बदलल्यास पुढच्या बॅकअपमध्ये सर्व डेटा पुन्हा अपलोड होतो आणि जुने चंक जोपर्यंत त्यांचे स्नॅपशॉट्स काढून टाकले (pruned) जात नाहीत, तोपर्यंत तिथेच राहतात. त्यामुळे, पहिला बॅकअप अपलोड करण्यापूर्वीच एन्क्रिप्शनबाबत निर्णय घ्या.

प्रून मार्क्स, गार्बेज कलेक्शन रिकलेम्स

हा विभाग वगळला जातो आणि यामुळेच व्हॉल्यूम भरतो. स्नॅपशॉट प्रून केल्याने त्याचे मेटाडेटा (मॅनिफेस्ट, इंडेक्स, लॉग आणि नोट्स) काढून टाकले जातात. यामुळे कोणतेही चंक्स (chunks) डिलीट होत नाहीत. चंक्स हे स्नॅपशॉट्समध्ये सामायिक केलेले असतात, त्यामुळे जोपर्यंत सर्व उर्वरित इंडेक्स वाचले जात नाहीत, तोपर्यंत एखादा चंक वापरला जात नाही हे समजू शकत नाही. गार्बेज कलेक्शन हे काम ते इंडेक्स वाचण्याचे काम करते. ज्या डेटास्टोअरमध्ये प्रूनचे वेळापत्रक आहे पण गार्बेज कलेक्शनचे नाही, त्याचा आकार सतत वाढतच राहतो.

दोन्ही सेट करा. आधी रिटेंशन, प्रत्येक नेमस्पेससाठी एक जॉब:

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

त्यानंतर डेटास्टोअरवर कलेक्शनचे वेळापत्रक सेट करा, जे प्रून जॉबच्या काही तास नंतर आणि बॅकअप विंडोच्या बाहेर असावे:

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

प्रून जॉब चालवा, त्यानंतर df वापरा, वापरलेल्या जागेच्या आकड्यात कोणताही बदल होणार नाही. आता गार्बेज कलेक्शन चालवा, त्यानंतर पुन्हा df वापरा, आता बदल दिसून येईल.

गार्बेज कलेक्शन दोन टप्प्यांत चालते. पहिल्या टप्प्यात डेटास्टोअरमधील प्रत्येक इंडेक्स तपासला जातो आणि त्या इंडेक्सद्वारे संदर्भित प्रत्येक चंकची ॲक्सेस टाइम अपडेट केली जाते. दुसऱ्या टप्प्यात, ज्या चंक्सची ॲक्सेस टाइम कटऑफपेक्षा जुनी आहे, ते डिलीट केले जातात. हा कटऑफ रन सुरू होण्यापूर्वीच्या 24 तास आणि 5 मिनिटांचा असतो, किंवा सध्या सुरू असलेल्या सर्वात जुन्या बॅकअपची वेळ, यापैकी जे आधी असेल ते ग्राह्य धरले जाते. हे मार्जिन असण्याचे कारण म्हणजे Linux डीफॉल्टनुसार फाइलसिस्टम relatime सह माउंट करते, जे प्रत्येक रीडवर ॲक्सेस टाइम अपडेट करण्याऐवजी दिवसातून एकदाच अपडेट करते. त्यामुळे एक तासापूर्वी लिहिलेला चंक, जरी तो कोणीही वापरत नसला तरी, लगेच डिलीट होत नाही. प्रूनमुळे मोकळी झालेली जागा चंक शेवटच्या वेळी वापरल्यापासून एका दिवसाच्या कालावधीनंतरच दिसून येते. जर डेटास्टोअरमध्ये कोणतीही जागा रिकामी झाली नाही असे वाटत असेल, तर ते सहसा या कालावधीच्या आत असते.

लहान VPS वर हे सर्वात जड काम असते, कारण ते व्हॉल्यूमवरील प्रत्येक चंक फाइलची माहिती (stats) तपासते. टास्क लॉगच्या शेवटी काय काढून टाकले आणि ग्रेस पिरियडमुळे काय अजूनही प्रलंबित आहे याचा सारांश असतो. जर खूप काही प्रलंबित असेल, तर ते दुसऱ्या दिवशी पुन्हा चालवा. PBS मध्ये gc-atime-safety-check आणि gc-atime-cutoff हे डेटास्टोअर ट्युनिंग पर्याय म्हणून उपलब्ध आहेत, पण ते जसे आहेत तसेच ठेवावेत. हे पर्याय अशा स्टोरेजसाठी आहेत जे ॲक्सेस टाइम्स रेकॉर्ड करू शकत नाहीत. noatime सह माउंट केलेल्या फाइलसिस्टमवर ही सुरक्षा तपासणी बंद केल्यास, जिवंत स्नॅपशॉट्सद्वारे संदर्भित असलेले चंक्स गमावण्याची शक्यता असते.

डेटाचे भाग वाचनीय असल्याची खात्री करणे (Verification)

यशस्वीरित्या अपलोड झालेला बॅकअप एक वर्षांनंतरही वाचता येईलच याची खात्री नसते. Verification प्रक्रियेत डेटाचे भाग (chunks) पुन्हा वाचले जातात आणि इंडेक्समध्ये साठवलेल्या चेकसमशी त्यांची तुलना केली जाते. यामुळे रिस्टोर करताना समस्या शोधण्याऐवजी, ती आधीच नियमित वेळापत्रकानुसार शोधता येते.

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

छोट्या VPS वर थ्रेडची संख्या कमी ठेवा. Verification प्रक्रियेवर डिस्क आणि CPU चा ताण येतो, त्यामुळे ती इतर चालू असलेल्या कामांशी स्पर्धा करू शकते. वेळापत्रकासाठी, वेब इंटरफेसमध्ये datastore च्या Verify Jobs टॅबचा वापर करा: दर आठवड्याला चालणारी जॉब, जी आधीच व्हेरिफाय केलेले स्नॅपशॉट्स वगळते आणि 30 दिवसांपेक्षा जुन्या भागांची पुन्हा तपासणी करते, ती संपूर्ण डेटा स्टोअर कव्हर करते आणि अनावश्यक काम टाळते.

ज्या स्नॅपशॉटची पडताळणी अयशस्वी होते, तो datastore व्ह्यूमध्ये 'failed' म्हणून चिन्हांकित केला जातो. अशा त्रुटींकडे दुर्लक्ष करू नका. डेटाचे भाग सामायिक (shared) असल्याने, बेस इमेजमधील एक खराब झालेला भाग सहसा त्या भागाचा संदर्भ देणाऱ्या प्रत्येक स्नॅपशॉटला अयशस्वी ठरवतो. ही समस्या सोडवण्यासाठी अयशस्वी स्नॅपशॉट्स काढून टाका (forget) आणि नवीन बॅकअप घ्या, ज्यामुळे गहाळ झालेले भाग पुन्हा अपलोड होतील. जर त्रुटी वारंवार येत असतील, तर datastore च्या खालील स्टोरेजमध्ये दोष असण्याची शक्यता असते. अशा वेळी VPS वर डिस्क हेल्थ मॉनिटरिंग सेट करा, जेणेकरून verify जॉब सांगण्याआधीच ड्राइव्ह तुम्हाला त्रुटीबद्दल सूचित करेल.

रिस्टोरची चाचणी करा, त्यानंतर क्लस्टरशिवाय त्याची चाचणी करा

जोपर्यंत तुम्ही बॅकअप रिस्टोर करून पाहत नाही, तोपर्यंत तो काम करतो की नाही हे समजत नाही. या दोन चाचण्या वेगवेगळ्या गोष्टी तपासतात.

संपूर्ण गेस्ट, क्लस्टरवर:

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) आहे आणि टाइमस्टॅम्प त्याचाच एक भाग आहे, त्यामुळे उदाहरणातील मजकूर टाईप करण्याऐवजी तुमचा स्वतःचा आयडी कॉपी करा. एका न वापरलेल्या गेस्ट आयडीवर आणि वेगळ्या स्टोरेजवर रिस्टोर करा, त्यानंतर त्याचे नेटवर्क इंटरफेस डिस्कनेक्ट करून ते सुरू करा. बॅकअप काम करतोय का हे तपासण्यासाठी चालू असलेल्या गेस्टवर कधीही रिस्टोर करू नका, कारण रिस्टोर अर्धवट अयशस्वी झाल्यास तुमची मूळ कार्यरत प्रतही नष्ट होऊ शकते.

दुसरी चाचणी अशी आहे जी कोणीही करत नाही. समजा ज्या इमारतीत क्लस्टर आहे ती आता अस्तित्वात नाही, अशा परिस्थितीत क्लस्टरचा भाग नसलेल्या मशीनवरून रिस्टोर करा. कोणत्याही Debian 13 मशीनवर, क्लायंट-ओन्ली रिपॉझिटरी /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

अवतरण चिन्हात दिलेले तीन प्लेसहोल्डर्स तुमच्या स्वतःच्या व्हॅल्यूजने भरा आणि शेवटच्या ओळीतील आर्काइव्हचे नाव snapshot files ने प्रिंट केलेल्या माहितीवरून घ्या. हे अशा गोष्टी सिद्ध करते ज्या पहिल्या चाचणीत सिद्ध होऊ शकत नाहीत: तुमची की फाईल (key file) प्रत्यक्ष डेटा डिक्रिप्ट करू शकते आणि तुम्ही अशा मशीनवरून क्लायंट चालवू शकता ज्यामध्ये तुमच्या क्लस्टरचे कॉन्फिगरेशन कधीही नव्हते. त्यासाठी आवश्यक असलेल्या चार व्हॅल्यूज - रिपॉझिटरी स्ट्रिंग, टोकन सीक्रेट, फिंगरप्रिंट आणि की फाईल - लिहून ठेवा आणि त्या तुमच्या आपत्ती निवारण योजनेत (disaster plan) नमूद केलेल्या सुरक्षित ठिकाणी ठेवा.

डीडुप्लिकेशन (deduplication) तुमच्या डिस्क बिलावर काय परिणाम करते आणि काय करत नाही

डीडुप्लिकेशन ही एक वास्तव प्रक्रिया आहे आणि ती संपूर्ण डेटास्टोअरवर काम करते. दहा Debian गेस्ट्स त्यांच्या बेस सिस्टमची एकच प्रत सामायिक करतात, त्यामुळे दुसरा हुबेहूब गेस्ट साठवण्यासाठी जवळजवळ काहीही खर्च येत नाही. यामुळे अपलोड बँडविड्थचीही बचत होते, कारण सर्व्हरकडे आधीच असलेला कोणताही डेटाचा तुकडा (chunk) पुन्हा पाठवण्याऐवजी क्लायंट फक्त त्याचा checksum पाठवतो.

हे काय करत नाही, हे स्पष्टपणे समजून घेणे महत्त्वाचे आहे.

• हे बदलणाऱ्या डेटाचा आकार कमी करत नाही. जो डेटाबेस दररोज रात्री त्याच्या फाइल्सचा मोठा भाग पुन्हा लिहितो, तो दररोज नवीन चंक्स तयार करतो आणि रिटेंशनमुळे त्यांची संख्या वाढते.
• हे एनक्रिप्शन की (encryption key) च्या मर्यादेपलीकडे काम करत नाही, ज्याचा उल्लेख वर केला आहे.
• हे डेटास्टोअरच्या मर्यादेपलीकडे काम करत नाही, जे नेमस्पेस (namespaces) वापरण्यामागचे मुख्य कारण आहे.
• हे व्हॉल्यूम पूर्ण होण्यापासून रोखत नाही. जेव्हा डेटास्टोअर पूर्ण भरतो, तेव्हा बॅकअप अपयशी ठरतात आणि त्यावर फक्त एकच उपाय असतो: मोठा व्हॉल्यूम किंवा कमी रिटेंशन कालावधी.

याखाली डीडुप्लिकेशनचा दुसरा स्तर लावू नका. क्लायंटद्वारे चंक्स आधीच डीडुप्लिकेट आणि कॉम्प्रेस केलेले असतात, त्यामुळे डेटास्टोअरच्या खाली ZFS डीडुप्लिकेशन वापरल्यास, ते चंक्स लिहिण्यापूर्वीच काढून टाकलेल्या मॅचेस शोधण्यासाठी विनाकारण RAM खर्च करते. यासाठी व्हॉल्यूमवर साधे ext4 किंवा xfs वापरणे हाच योग्य पर्याय आहे.

वेब इंटरफेस डेटास्टोअरसाठी डीडुप्लिकेशन फॅक्टर दर्शवतो. तो आकडा तुमच्या गेस्ट्सची स्थिती सांगतो आणि नियोजनासाठी तोच विचारात घेणे योग्य आहे, कारण प्रसिद्ध केलेली गुणोत्तरे (ratios) ही इतरांच्या डेटावर आधारित असतात. जर तुम्हाला Proxmox गेस्ट नसलेल्या मशीनचे फाइल-लेव्हल बॅकअप घेण्याची गरज असेल, तर ते त्याच VPS वर समांतर चालवा: PBS हे संपूर्ण गेस्ट्ससाठी हायपरवाइजर-अवेअर टार्गेट आहे, तर restic आणि BorgBackup डिरेक्टरीजवर लक्ष केंद्रित करतात आणि restic backups to a VPS लॅपटॉप्स आणि स्टँडअलोन सर्व्हर्ससाठी उपयुक्त आहेत, ज्यांच्यासाठी PBS बनवलेले नाही.

अपयशाचे प्रकार आणि तुम्हाला दिसणारी लक्षणे

स्टोरेज inactive असल्याचे दिसते. जेव्हा नोड port 8007 वर TLS सत्र पूर्ण करू शकत नाही, तेव्हा pvesm status --storage pbs-offsite हे inactive प्रिंट करते. VPS वरील फायरवॉल तपासा, त्यानंतर प्रोव्हायडरची स्वतंत्र नेटवर्क फायरवॉल तपासा आणि शेवटी फिंगरप्रिंट तपासा. जर फिंगरप्रिंट प्रमाणपत्राशी जुळत नसेल, तर ते ब्लॉक केलेल्या पोर्टप्रमाणेच अपयशी ठरते; प्रमाणपत्र बदलले की फिंगरप्रिंटही बदलते.

परवानगीच्या (permissions) समस्येमुळे पहिली बॅकअप प्रक्रिया अपयशी ठरते. ॲक्सेस कंट्रोल एंट्रीमध्ये वापरकर्त्याऐवजी टोकनचा उल्लेख असणे आवश्यक आहे आणि ती स्टोरेज ज्या नेमस्पेसकडे निर्देश करते, त्या नेमस्पेसला कव्हर करणारी असावी. इतर कुठेही तपासण्यापूर्वी वेब इंटरफेसवरील डेटास्टोअरच्या परवानग्यांच्या टॅबमध्ये या दोन्ही गोष्टींची खात्री करा.

गार्बेज कलेक्शन सुरू होण्यास नकार देते. ॲक्सेस टाइम सेफ्टी चेक अयशस्वी झाला आहे, ज्याचा अर्थ असा होतो की डेटास्टोअर फाइलसिस्टम noatime माउंट केलेली आहे. हे निश्चित करण्यासाठी findmnt -no OPTIONS /mnt/datastore/store1 चालवा, /etc/fstab मधील पर्याय दुरुस्त करा आणि पुन्हा माउंट करा. या समस्येतून मार्ग काढण्यासाठी हा चेक डिसेबल करू नका.

डेटास्टोअरची साईज फक्त वाढतच आहे. प्रून जॉब्स (prune jobs) चालतात पण कोणतीही जागा रिकामी होत नाही. एकतर गार्बेज कलेक्शनचे वेळापत्रक सेट केलेले नाही, किंवा प्रत्येक कलेक्शन बॅकअप पूर्ण झाल्यानंतर लगेच चालत असल्याने ते 24 तासांच्या ग्रेस विंडोमध्ये येते. proxmox-backup-manager datastore show store1 वापरून वेळापत्रक तपासा.

जो बॅकअप पूर्वी जलद होत होता, तो आता तासनतास घेतो. एखादा गेस्ट जो थांबवला गेला आहे, स्थलांतरित (migrated) केला आहे किंवा रिस्टोर केला आहे, तो त्याचे डर्टी बिटमॅप गमावतो. त्यामुळे पुढच्या वेळी क्लस्टर स्तरावर संपूर्ण डिस्क वाचली जाते, जरी प्रत्यक्षात खूप कमी डेटा अपलोड होत असला तरीही. टास्क लॉगमध्ये कमी अपलोड आकडेवारीसह जास्त वेळ लागल्याचे दिसते, परंतु त्यानंतरची रन पुन्हा जलद होते. जर VPS वरील प्रत्येक जॉब संथ असेल, तर त्याचे कारण सहसा डेटास्टोअरच्या बाहेर असते आणि CPU steal time from a noisy neighbour ही मोजण्यासाठी पहिली गोष्ट आहे.

FAQ

prune job चालल्यानंतर माझा Proxmox Backup Server datastore का वाढत राहतो?

कारण pruning फक्त स्नॅपशॉट मेटाडेटा काढून टाकते: जसे की manifest, indexes, log आणि notes. जोपर्यंत garbage collection अशा chunks ना काढून टाकत नाही ज्यांचा कोणताही index संदर्भ देत नाही, तोपर्यंत ते chunks डिस्कवरच राहतात. datastore साठी proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' सह एक वेळापत्रक (schedule) सेट करा आणि proxmox-backup-manager garbage-collection start store1 करण्यापूर्वी व नंतर datastore पाथवर df -h चालवून याची खात्री करा. किमान एका दिवसाचा विलंब अपेक्षित धरा, कारण phase two फक्त अशाच chunks ना काढून टाकते ज्यांचा access time 24 तास आणि 5 मिनिटांपेक्षा जुना आहे.

Proxmox Backup Server VPS साठी किती डिस्कची आवश्यकता असते?

प्रत्येक guest प्रत्यक्षात किती जागा वापरतो याची बेरीज करा, त्यानंतर प्रत्येक guest मधील दैनंदिन बदल आणि तुम्ही किती दिवस बॅकअप ठेवणार आहात याचा गुणाकार करून त्यात मिळवा. compression आणि deduplication तुमच्या फायद्याचे असल्याने ही एकूण बेरीज एक कमाल मर्यादा (ceiling) असेल. indexes आणि कामासाठी लागणाऱ्या अतिरिक्त जागेसाठी सुमारे एक-पंचमांश जागा जोडा आणि त्यानंतर तुम्हाला खरेदी करता येईल अशा व्हॉल्यूम साईजपर्यंत ती वाढवा. दोन आठवड्यांनंतर datastore व्ह्यूमध्ये प्रत्यक्ष वापराची पुन्हा तपासणी करा, कारण पहिल्या बॅकअपच्या आधी लावलेला अंदाज नेहमीच कमी किंवा जास्त असू शकतो.

बॅकअप encryption key कुठे साठवली पाहिजे?

ज्या क्लस्टरचे ती संरक्षण करते, त्याव्यतिरिक्त इतर कोणत्याही ठिकाणी. Proxmox VE ती /etc/pve/priv/storage/<storage>.enc वर ठेवते, जी प्रत्येक नोडवर replicate केली जाते आणि त्यामुळे क्लस्टरसोबत ती नष्ट होऊ शकते. पहिल्याच दिवशी तिची प्रत बाहेर काढा, proxmox-backup-client key paperkey वापरून ती प्रिंट करा आणि ती प्रत दुसऱ्या इमारतीत सुरक्षित ठेवा. हे देखील लक्षात घ्या की key ही chunk digest चा भाग असते, त्यामुळे ती नंतर बदलल्यास पुढच्या बॅकअपमध्ये सर्व डेटा पुन्हा अपलोड करावा लागेल.

मला प्रत्येक Proxmox होस्टसाठी एक datastore हवा आहे की namespaces?

प्रत्येक सोर्स होस्ट किंवा क्लस्टरसाठी एक datastore आणि एक namespace पुरेसे आहे. deduplication हे एका datastore मध्ये काम करते, दोन वेगवेगळ्या datastores मध्ये नाही, त्यामुळे होस्टनुसार विभागणी केल्यास एकाच बेस इमेज अनेकदा साठवल्या जातील. namespaces मुळे बॅकअप ग्रुप्स वेगळे राहतात, त्यामुळे दोन होस्ट्सवर ID 100 असलेला guest असल्यास संघर्ष (collision) होत नाही आणि /datastore/store1/pve-home स्वरूपातील access control path प्रत्येक होस्टच्या API token ला त्याच्या स्वतःच्या namespace पुरते मर्यादित ठेवते.

एक छोटा VPS Proxmox बॅकअप सर्व्हर म्हणून काम करू शकेल का?

सहसा, homelab साठी हे शक्य आहे, कारण chunking आणि hashing ची प्रक्रिया Proxmox VE नोडवर होते, बॅकअप सर्व्हरवर नाही. VPS फक्त chunks लिहितो आणि दोन जड प्रक्रिया चालवतो: garbage collection आणि verification. त्याला 4 GB RAM द्या आणि verification thread ची संख्या कमी ठेवा. दोन्ही प्रक्रिया बॅकअप विंडोच्या बाहेर शेड्यूल करा आणि तरीही त्यांना डिस्कच्या क्षमतेपेक्षा जास्त वेळ लागत असेल, तर मोठा प्लॅन घेण्यापूर्वी steal time मोजून पहा.