VPS पर Proxmox Backup Server कैसे सेटअप करें

VPS पर Proxmox Backup Server आपको वास्तव में क्या देता है

VPS पर Proxmox Backup Server (PBS) एक ऑफसाइट लक्ष्य है जो उसी प्रोटोकॉल का उपयोग करता है जिसे आपका Proxmox VE (वर्चुअल एनवायरनमेंट) क्लस्टर पहले से उपयोग कर रहा है। इसलिए, पहले बैकअप के बाद हर बैकअप इंक्रीमेंटल होता है, गेस्ट्स के बीच डी-डुप्लिकेटेड होता है, आपके परिसर से बाहर निकलने से पहले एन्क्रिप्ट किया जाता है, और बाद में सत्यापित किया जा सकता है। आप ब्लॉक वॉल्यूम के साथ एक VPS किराए पर लेते हैं, Debian 13 पर PBS इंस्टॉल करते हैं, उस वॉल्यूम पर एक डेटास्टोर बनाते हैं, और इसे Proxmox VE में pbs प्रकार के स्टोरेज के रूप में जोड़ते हैं। इंस्टॉलेशन में दस मिनट लगते हैं। इसके बाद की हर चीज़, जैसे नेमस्पेस, गारबेज कलेक्शन, की कस्टडी और एक रिस्टोर जिसे आपने वास्तव में रन किया है, यह तय करती है कि एक साल बाद आपका बैकअप कितना उपयोगी होगा।

किराए की डिस्क पर vzdump फाइलों को कॉपी करने के बजाय PBS का उपयोग करने का कारण इसका चंक स्टोर है। क्लाइंट प्रत्येक गेस्ट डिस्क को लगभग 4 MiB के चंक्स में विभाजित करता है, उनका हैश बनाता है, और केवल उन्हीं चंक्स को अपलोड करता है जो डेटास्टोर में पहले से मौजूद नहीं हैं। एक चल रही वर्चुअल मशीन के लिए, QEMU पहले बैकअप के बाद डर्टी बिटमैप में बदले हुए ब्लॉक्स को ट्रैक करता है, इसलिए अगली बार केवल उन्हीं ब्लॉक्स को लोकल डिस्क से पढ़ा जाता है। एक 200 GB का गेस्ट जो प्रतिदिन 3 GB बदलता है, वह लगभग 3 GB प्रतिदिन भेजता है। यही वह चीज़ है जो होम अपलिंक और किराए के वॉल्यूम को एक साथ काम करने योग्य बनाती है, और यही कारण है कि ऑफसाइट बैकअप लक्ष्य के रूप में एक VPS किसी मित्र के घर पर रखी अतिरिक्त ड्राइव से बेहतर है। यदि आप अभी भी यह तय कर रहे हैं कि हाइपरवाइजर को स्वयं कहाँ रहना चाहिए, तो घर पर Proxmox बनाम किराए का VPS उस प्रश्न को अलग से कवर करता है।

Volume को किराए पर लेने से पहले उसका आकार निर्धारित करें

आकार का निर्धारण वह गणित है जिसे आप अपने स्वयं के आंकड़ों पर करते हैं। प्रत्येक guest द्वारा वास्तव में उपयोग की जाने वाली जगह को लें, न कि उसकी virtual disk के आकार को, और फिर उसमें प्रतिदिन होने वाले बदलाव को दिनों की संख्या से गुणा करके जोड़ें। 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
  }
]

ये पंक्तियाँ एक कार्यशील उदाहरण हैं, न कि कोई माप। प्रत्येक guest के अंदर df -h से उपयोग की गई जगह को पढ़ें, और एक बार PBS task log में दूसरा और तीसरा backup मौजूद हो जाने पर, उनके आकार से दैनिक बदलाव को पढ़ें।

उदाहरण में mail guest 120 GB का उपयोग करता है और प्रतिदिन लगभग 3.0 GB बदलता है, इसलिए तीस दैनिक snapshots के लिए लगभग 210 GB की आवश्यकता होती है: एक पूर्ण प्रतिलिपि और तीस दिनों का बदलाव। सभी 3 guests के लिए अंतिम कॉलम को जोड़ें और कुल योग लगभग 619 GB है। indexes, metadata और garbage collection को काम करने के लिए आवश्यक जगह के लिए इसमें एक-पांचवां हिस्सा और जोड़ें, जो 1 TB volume की ओर इशारा करता है।

योजना का शेष भाग छोटा है। PBS 2 GB RAM के साथ ठीक काम करता है और 4 GB के साथ सहज रहता है, क्योंकि भारी काम cluster side पर होता है: Proxmox VE node guest disks को पढ़ता है और chunking तथा hashing का कार्य करता है। VPS का काम chunks को लिखना और दो भारी jobs, garbage collection और verification को चलाना है। Datastore को एक बड़े root disk के बजाय एक अलग block volume के रूप में किराए पर लें, क्योंकि आप बाद में सर्वर को फिर से बनाए बिना volume का आकार बढ़ा सकते हैं।

Debian 13 पर Proxmox Backup Server इंस्टॉल करें

अगस्त 2026 तक, वर्तमान पेयरिंग Debian 13 (कोडनेम trixie) पर Proxmox Backup Server 4 है। पुराने गाइड्स में PBS 2 को Debian 11 के साथ जोड़ा गया है, और कोडनेम रिपॉजिटरी परिभाषा का हिस्सा होता है, इसलिए पुराने सुइट नाम को कॉपी करने पर आपको missing release file के बारे में apt एरर मिलेगा। एक सादे 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

योग (sum) 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 होना चाहिए। यदि ऐसा नहीं है, तो रुक जाएं। गलत keyring का मतलब है कि आप ऐसे पैकेज इंस्टॉल करने वाले हैं जो किसी ऐसी चीज़ द्वारा हस्ताक्षरित (signed) हैं जिसे आपने चेक नहीं किया है।

/etc/apt/sources.list.d/pbs.sources को 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 पासवर्ड के साथ root@pam के रूप में लॉग इन करें, क्योंकि PBS उस यूजर को PAM (pluggable authentication modules) के विरुद्ध प्रमाणित करता है, जो वही अकाउंट्स हैं जिनका उपयोग ऑपरेटिंग सिस्टम करता है। सर्टिफिकेट self-signed है और आपका ब्राउज़र ऐसा ही कहेगा। उस सर्टिफिकेट का फिंगरप्रिंट वह मान है जिसे Proxmox VE बाद में पिन करता है, इसलिए यह चेतावनी अपेक्षित है, न कि कोई ऐसी समस्या जिसे ठीक करने की आवश्यकता है।

पोर्ट 8007 पब्लिक इंटरनेट पर एक लॉगिन फॉर्म है, इसलिए इसे सभी के लिए खुला न छोड़ें। एक nftables फ़ाइल इसे कवर करती है। /etc/nftables.conf लिखना वर्तमान रूल्सेट को flushes (साफ) कर देता है, इसलिए यदि इस बॉक्स पर कोई अन्य चीज़ पहले से ही फ़ायरवॉल को मैनेज कर रही है, तो इसे छोड़ दें।

#!/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 पैनल में मशीन के सामने एक अलग नेटवर्क फ़ायरवॉल होता है जिसे उसी पोर्ट को अनुमति देनी चाहिए।

Datastore को उसके अपने volume पर रखें

Datastore को root filesystem पर नहीं होना चाहिए। जब एक datastore साझा root filesystem को भर देता है, तो backup विफल हो जाता है और सर्वर पर मौजूद बाकी सब कुछ भी, जिसमें वह logging भी शामिल है जिसकी आपको समस्या का कारण जानने के लिए आवश्यकता होती है। Block volume को attach करें, उसे format करें, mount करें, और उसके बाद ही mount point के अंदर datastore बनाएँ।

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

Device का नाम lsblk से लें। अधिकांश KVM images पर यह /dev/vdb होता है और अन्य पर /dev/sdb, और यह मान लेना कभी भी सुरक्षित नहीं होता। Mount को /etc/fstab में label के आधार पर जोड़ें, ताकि reboot के बाद device का नाम बदलने पर datastore गलत disk की ओर न मुड़ जाए:

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 को device, path, और rw,relatime सहित अन्य options को print करना चाहिए। उस एक पंक्ति में दो विफलताएं छिपी होती हैं। यदि mount वहां नहीं है और आप फिर भी datastore बनाते हैं, तो PBS mount point के नीचे root filesystem में लिखना शुरू कर देता है, और अगली बार सफल mount होने पर वह data छिप जाता है लेकिन delete नहीं होता: ऐसी स्थिति में datastore खाली दिखता है और root filesystem भरा रहता है। यदि options में noatime लिखा है, तो PBS काम करने से मना कर देगा, क्योंकि यह datastore बनाते समय और हर garbage collection के दौरान access time की सुरक्षा जांच करता है।

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

यह एक .chunks directory बनाता है जिसमें 65536 subdirectories होती हैं, जिनका नाम 0000 से ffff तक होता है। Datastore लाखों छोटी files का संग्रह है, न कि कुछ बड़ी files का। इसके दो परिणाम होते हैं। साधारण file-level tool से datastore को copy करना इतना धीमा होता है कि वह व्यर्थ है, और backup चलते समय लिया गया provider volume snapshot उसका consistent copy नहीं होता है, यही कारण है कि snapshots backup का विकल्प नहीं होते कहीं और भी।

Namespaces दो hosts को आपस में टकराने से रोकते हैं

Datastore डिफ़ॉल्ट रूप से flat होता है। Backups के नाम vm/100, ct/101 और host/<name> होते हैं। यदि दो clusters में से प्रत्येक का एक guest ID 100 के साथ एक ही group में लिखता है, तो उनके snapshots आपस में मिल जाते हैं, और एक के लिए लिखा गया retention rule दूसरे के snapshots की भी गिनती करने लगता है। Namespaces हर source को एक datastore के भीतर अपनी अलग tree देते हैं।

इन्हें PBS host पर बनाएँ। --repository argument का प्रारूप [[auth-id@]server[:port]:]datastore होता है, इसलिए एक local namespace root@pam@localhost:store1 के रूप में पढ़ा जाता है, और यह command root password मांगती है।

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 में साझा किए जाते हैं, इसलिए तीन namespaces में फैले दस Debian guests भी base system की केवल एक ही copy store करते हैं। यही कारण है कि प्रति host एक datastore बनाने के बजाय namespaces के साथ एक ही datastore का उपयोग करना बेहतर है: अलग-अलग datastores का मतलब है अलग-अलग chunk pools, और अलग-अलग chunk pools का मतलब है एक ही Debian install के लिए कई बार storage खर्च करना।

प्रत्येक source को उसका अपना account दें, जो उसके अपने namespace तक सीमित हो। एक API (application programming interface) token वह credential है जो एक user से संबंधित होता है और जिसके अपने permissions होते हैं, जो कि ऐसी machine पर आवश्यक है जिसके चोरी होने का जोखिम हो।

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 command secret को केवल एक बार print करती है:

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

इसे अभी copy कर लें, क्योंकि PBS के पास इसका कोई ऐसा रूप नहीं होता जिसे वह आपको दोबारा दिखा सके। Access control command को ध्यान से देखें। यह token का नाम, backup@pbs!pve-home, बताती है, न कि user का, क्योंकि token के permissions केवल उन entries से calculate किए जाते हैं जो token का नाम लेती हैं। केवल backup@pbs के लिए एक entry होने पर token के पास कोई access नहीं बचेगा, और फिर पहला backup network में दिखाई देने वाली किसी समस्या के बजाय permissions की त्रुटि के कारण fail हो जाएगा। Path भी उतना ही महत्वपूर्ण है: /datastore/store1/pve-home तक सीमित token office namespace में कुछ भी पढ़ या delete नहीं कर सकता, इसलिए एक compromised cluster किसी दूसरे site का history नष्ट नहीं कर सकता।

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 को कुछ भी डिलीट न करने का निर्देश देता है। रिटेंशन PBS साइड पर होता है, जिसे आगे विस्तार से समझाया गया है, और इसका एक स्पष्ट कारण है: इस स्थिति में टोकन को डिलीट करने की अनुमति की आवश्यकता नहीं होती है। अतः यदि कोई क्लस्टर रैनसमवेयर द्वारा एन्क्रिप्ट हो जाता है, तो वह ऑफसाइट हिस्ट्री को डिलीट नहीं कर पाएगा, जिसे बैकअप के लिए सुरक्षित रखा गया है।

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

pvesm status स्टेटस कॉलम में active प्रिंट करता है, जिसके साथ डेटास्टोर का कुल और उपयोग किया गया स्पेस दिखाई देता है। inactive का अर्थ है कि नोड पोर्ट 8007 पर TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) सेशन पूरा नहीं कर सका। यह क्रेडेंशियल की समस्या के बजाय फायरवॉल या फिंगरप्रिंट की समस्या है।

पहला बैकअप सब कुछ अपलोड करता है, इसलिए इसे शुरू करने से पहले गणना कर लें। 200 GB का मतलब 1600 गीगाबिट्स है, और 100 Mbit अपलिंक 0.1 गीगाबिट प्रति सेकंड की गति से डेटा ट्रांसफर करता है, इसलिए न्यूनतम समय लगभग साढ़े चार घंटे है और वास्तविक समय इससे अधिक होगा। इसे तब शुरू करें जब आपको बैंडविड्थ की आवश्यकता न हो। इसके बाद के हर रन में केवल नए चंक्स ही भेजे जाते हैं।

Client-side encryption और key कहाँ रहती है

VPS एक ऐसा कंप्यूटर है जिसके आप मालिक नहीं हैं। Client-side पर encryption करें, ताकि datastore में ऐसे chunks रहें जिन्हें provider पढ़ न सके।

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

यह /etc/pve/priv/storage/pbs-offsite.enc में एक नई key लिखता है, जिसे केवल root ही पढ़ सकता है, और इसे /etc/pve के बाकी हिस्सों के साथ replicate किया जाता है। अगली backup से, client हर chunk को बाहर भेजने से पहले encrypt कर देता है। Server अभी भी आपके snapshots और उनके sizes की सूची देख सकता है, लेकिन वह उनकी सामग्री को नहीं पढ़ सकता।

अब वह हिस्सा जो इसे एक liability के बजाय backup बनाता है। उत्पन्न की गई key में कोई passphrase नहीं होता है, और यह केवल उसी cluster पर मौजूद होती है जिसकी यह सुरक्षा करती है। यदि वह cluster चोरी हो जाता है या किसी और द्वारा encrypt कर दिया जाता है, तो VPS में ऐसा डेटा होगा जिसे कोई नहीं खोल सकता। जिस दिन आप key बनाएँ, उसी दिन उसे cluster से बाहर copy कर लें।

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 key को एक ऐसे document के रूप में print करता है जिसे कागज़ पर छापा जाना चाहिए और कहीं और सुरक्षित रखा जाना चाहिए। file को स्वयं एक secret की तरह मानें, क्योंकि इसे रखने वाला कोई भी व्यक्ति इसके साथ किए गए हर backup को decrypt कर सकता है। बड़े setup के लिए, PBS एक master key को भी support करता है, जो proxmox-backup-client key create-master-key के साथ बनाई गई एक RSA (Rivest Shamir Adleman) key pair है, जहाँ प्रत्येक backup अपनी encryption key को public half के साथ encrypt करके store करता है, जबकि private half recovery के लिए offline रहता है।

इस design का एक परिणाम शुरू करने से पहले जानना बेहतर है, न कि बाद में। Encrypted backups के लिए, chunk digest की गणना plain text सामग्री और encryption key को जोड़कर की जाती है, इसलिए अलग-अलग keys के तहत encrypt किए गए दो समान chunks अलग-अलग digests उत्पन्न करते हैं और कभी भी एक-दूसरे के साथ deduplicate नहीं होते हैं। Key बदलने का मतलब है कि अगला backup सब कुछ फिर से upload करेगा, और पुराने chunks तब तक वहीं रहेंगे जब तक कि उनके snapshots को prune और collect नहीं कर लिया जाता। पहले upload से पहले ही encryption के बारे में निर्णय ले लें।

Prune marks, garbage collection reclaims

यह वह सेक्शन है जिसे अक्सर छोड़ दिया जाता है, और यही वह कारण है जिससे वॉल्यूम भर जाता है। किसी snapshot को prune करने से केवल उसका मेटाडेटा हटता है: manifest, indexes, log और notes। यह किसी भी chunk को डिलीट नहीं करता है। Chunks कई snapshots के बीच साझा किए जाते हैं, इसलिए जब तक हर बचे हुए index को पढ़ा न जाए, यह पता नहीं चल सकता कि कोई chunk उपयोग में नहीं है। Garbage collection ही वह प्रक्रिया है जो उन्हें पढ़ती है। जिस datastore में prune का शेड्यूल तो है लेकिन 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

फिर datastore पर collection शेड्यूल सेट करें, prune जॉब के कुछ घंटे बाद और backup विंडो के बाहर:

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

Prune जॉब चलाएं, फिर df चलाएं, उपयोग किए गए स्पेस का आंकड़ा नहीं बदलेगा। अब garbage collection चलाएं, फिर दोबारा df चलाएं, तो आंकड़ा बदल जाएगा।

Garbage collection दो चरणों में चलता है। पहला चरण datastore के हर index को स्कैन करता है और उन सभी chunks के access time को अपडेट करता है जिन्हें वे indexes रेफर करते हैं। दूसरा चरण उन chunks को डिलीट करता है जिनका access time कटऑफ से पुराना है। यह कटऑफ रन शुरू होने से 24 घंटे और 5 मिनट पहले का समय होता है, या फिर उस सबसे पुराने backup का शुरुआती समय जो अभी भी लिखा जा रहा है (जो भी पहले हो)। यह मार्जिन इसलिए है क्योंकि Linux डिफ़ॉल्ट रूप से फाइल्सystems को relatime के साथ माउंट करता है, जो हर रीड के बजाय लगभग दिन में एक बार access time अपडेट करता है। इसलिए एक घंटा पहले लिखा गया chunk तब भी डिलीट नहीं होता भले ही उसे कोई रेफर न कर रहा हो, और prune द्वारा खाली की गई जगह उस पहली collection के बाद दिखाई देती है जो chunk के आखिरी बार छुए जाने के एक दिन बाद चलती है। यदि किसी datastore में कोई जगह खाली होती नहीं दिख रही है, तो अक्सर इसका कारण यही समय सीमा (window) होती है।

एक छोटे VPS पर यह सबसे भारी जॉब होती है, क्योंकि यह वॉल्यूम पर मौजूद हर chunk फाइल को stats करती है। टास्क लॉग एक सारांश के साथ समाप्त होता है कि क्या हटाया गया और क्या grace period के कारण अभी भी पेंडिंग है। यदि बहुत कुछ पेंडिंग है, तो इसे अगले दिन फिर से चलाएं। PBS datastore ट्यूनिंग विकल्पों के रूप में gc-atime-safety-check और gc-atime-cutoff प्रदान करता है, और दोनों को नहीं छेड़ना चाहिए: ये उन स्टोरेज के लिए हैं जो access times रिकॉर्ड नहीं कर सकते, और noatime माउंटेड फाइल्सystem पर सुरक्षा जांच को बंद करने से आप उन chunks को खो सकते हैं जिन्हें लाइव snapshots अभी भी रेफर कर रहे हैं।

सत्यापन यह सुनिश्चित करता है कि चंक्स अभी भी पठनीय हैं

एक बैकअप जो सफलतापूर्वक अपलोड हो गया था, वह एक साल बाद अपठनीय हो सकता है। सत्यापन (verification) चंक्स को दोबारा पढ़ता है और उनकी तुलना इंडेक्स में संग्रहीत चेकसम से करता है, जिससे क्षति का पता रिस्टोर के समय के बजाय समय रहते चल जाता है।

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

छोटे VPS पर थ्रेड काउंट कम रखें। सत्यापन डिस्क और CPU द्वारा सीमित होता है, अन्यथा यह सर्वर पर चल रहे अन्य कार्यों के साथ संसाधनों के लिए प्रतिस्पर्धा करेगा। शेड्यूल के लिए, वेब इंटरफेस में datastore के Verify Jobs टैब का उपयोग करें: एक साप्ताहिक जॉब जो पहले से सत्यापित स्नैपशॉट्स को छोड़ देती है और 30 दिनों से पुराने किसी भी डेटा को दोबारा सत्यापित करती है, वह बिना काम दोहराए समय के साथ पूरे स्टोर को कवर कर लेती है।

जो स्नैपशॉट सत्यापन में विफल रहता है, उसे datastore व्यू में विफल (failed) के रूप में चिह्नित किया जाता है। इसे अनदेखा न करें। चंक्स साझा (shared) होते हैं, इसलिए बेस इमेज का एक क्षतिग्रस्त चंक आमतौर पर उन सभी स्नैपशॉट्स को विफल कर देता है जो उसे रेफरेंस करते हैं। इसे ठीक करने का तरीका विफल स्नैपशॉट्स को हटाना (forget) और एक नया बैकअप चलाना है, जो गायब चंक्स को फिर से अपलोड कर देता है। यदि विफलताएं बार-बार दिखाई देती हैं, तो datastore के नीचे मौजूद स्टोरेज पर संदेह करें, और VPS पर डिस्क हेल्थ मॉनिटरिंग सेट करें ताकि ड्राइव आपको सत्यापन जॉब से पहले ही सूचित कर दे।

Restore का परीक्षण करें, फिर इसे cluster के बिना टेस्ट करें

जब तक आप backup को restore करके नहीं देख लेते, तब तक आप यह नहीं जान सकते कि वह काम करता है या नहीं। इसके लिए दो परीक्षण करें, क्योंकि वे अलग-अलग चीजों की जाँच करते हैं।

पूरे guest का, cluster पर परीक्षण:

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 इसका हिस्सा है, इसलिए उदाहरण टाइप करने के बजाय अपनी ID को copy करें। इसे एक unused guest ID में और अलग storage पर restore करें, फिर इसके network interface को disconnected रखकर इसे start करें। चलते हुए guest के ऊपर कभी भी restore न करें ताकि यह सुनिश्चित हो सके कि backup काम कर रहे हैं, क्योंकि यदि restore बीच में ही विफल हो गया तो आपकी working copy भी नष्ट हो जाएगी।

दूसरा परीक्षण वह है जिसे कोई नहीं करता। मान लें कि जिस building में cluster था वह अब नहीं है, और एक ऐसी machine से restore करें जो कभी उसका हिस्सा नहीं थी। किसी भी Debian 13 box पर, client-only repository को /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

उद्धरण चिह्नों (quoted placeholders) में दिए गए तीनों स्थानों को अपने मानों (values) से भरें, और अंतिम पंक्ति में archive का नाम वह रखें जो snapshot files ने print किया था। यह वह साबित करता है जो पहला परीक्षण नहीं कर सकता: कि आपकी key file की copy वास्तविक data को decrypt कर सकती है, और आप उस machine से client को चला सकते हैं जिसने कभी आपके cluster का configuration नहीं रखा था। जिन चार मानों की आवश्यकता थी—repository string, token secret, fingerprint और key file—उन्हें लिख लें, और उन्हें उस स्थान पर सुरक्षित रखें जहाँ आपका disaster plan निर्देश देता है।

Deduplication आपके डिस्क बिल पर क्या असर डालता है और क्या नहीं

Deduplication वास्तविक है और यह पूरे datastore पर काम करता है। दस Debian guests अपने base system की एक ही copy साझा करते हैं, इसलिए दूसरे समान guest को store करने में लगभग कोई खर्च नहीं आता। यह upload bandwidth की भी बचत करता है, क्योंकि यदि server के पास पहले से ही कोई chunk मौजूद है, तो client data के बजाय केवल उसका checksum भेजता है।

यह क्या नहीं करता है, इस पर स्पष्ट रहना आवश्यक है।

• यह उस data को छोटा नहीं करता जो बदलता रहता है। एक database जो हर रात अपनी files के बड़े हिस्से को rewrite करता है, वह हर रात नए chunks बनाता है और retention उन्हें multiply कर देता है।
• यह encryption key की सीमा के पार काम नहीं करता, जैसा कि ऊपर बताया गया है।
• यह datastore की सीमा के पार काम नहीं करता, जो कि namespaces का मुख्य उद्देश्य है।
• यह volume को भरने से नहीं रोकता। जब datastore भर जाता है, तो backups विफल हो जाते हैं, और इसका एकमात्र समाधान बड़ा volume या कम retention है।

इसके नीचे deduplication की एक और परत न लगाएँ। Chunks पहले से ही client द्वारा deduplicate और compress होकर आते हैं, इसलिए datastore के नीचे ZFS deduplication केवल RAM खर्च करता है ताकि उन matches को खोजा जा सके जिन्हें लिखे जाने से पहले ही हटा दिया गया था। यहाँ volume पर साधारण ext4 या xfs का उपयोग करना ही सही विकल्प है।

Web interface datastore के लिए एक deduplication factor दिखाता है। वह संख्या आपके guests के बारे में बताती है, और योजना बनाने के लिए केवल वही महत्वपूर्ण है, क्योंकि प्रकाशित ratios किसी और के data पर आधारित होते हैं। यदि आपको उन machines के file-level backups की भी आवश्यकता है जो Proxmox guests नहीं हैं, तो उन्हें उसी VPS पर साथ चलाएँ: PBS पूरे guests के लिए एक hypervisor-aware target है, जबकि restic and BorgBackup directories को target करते हैं, और restic backups to a VPS उन laptops और standalone servers के लिए उपयुक्त हैं जिन्हें cover करने के लिए PBS नहीं बनाया गया था।

विफलता के प्रकार और आपको क्या दिखाई देगा

स्टोरेज inactive दिखाई देता है। pvesm status --storage pbs-offsite तब inactive प्रिंट करता है जब नोड port 8007 पर TLS session पूरा नहीं कर पाता है। VPS पर firewall की जाँच करें, फिर प्रदाता के अलग नेटवर्क firewall की, और अंत में fingerprint की। यदि fingerprint certificate से मेल नहीं खाता है, तो यह उसी तरह विफल होता है जैसे कोई port ब्लॉक हो, और जब भी certificate बदला जाता है, तो यह बदल जाता है।

पहला बैकअप अनुमतियों (permissions) के कारण विफल हो जाता है। एक्सेस कंट्रोल एंट्री में उपयोगकर्ता के बजाय टोकन का नाम होना चाहिए, और इसे उस namespace को कवर करना चाहिए जिसकी ओर स्टोरेज इंगित करता है। कहीं और देखने से पहले वेब इंटरफेस में datastore के permissions टैब पर दोनों की पुष्टि करें।

Garbage collection शुरू होने से मना कर देता है। एक्सेस टाइम सुरक्षा जाँच विफल हो गई है, जिसका लगभग हमेशा मतलब यह होता है कि datastore filesystem noatime माउंट किया गया है। पुष्टि करने के लिए findmnt -no OPTIONS /mnt/datastore/store1 चलाएँ, /etc/fstab में विकल्प को ठीक करें, और रीमाउंट करें। इसे बायपास करने के लिए जाँच को अक्षम (disable) न करें।

Datastore केवल बढ़ता रहता है। Prune जॉब्स चलते हैं लेकिन कुछ भी रिकलेम नहीं होता है। या तो कोई garbage collection शेड्यूल नहीं है, या प्रत्येक कलेक्शन 24 घंटे की ग्रेस विंडो के भीतर आता है क्योंकि यह बैकअप के तुरंत बाद चलता है। proxmox-backup-manager datastore show store1 के साथ शेड्यूल की जाँच करें।

जो बैकअप पहले जल्दी हो जाता था, वह अब घंटों लेता है। एक गेस्ट जिसे रोका गया, माइग्रेट किया गया या रिस्टोर किया गया, वह अपना dirty bitmap खो देता है। इसलिए, अगला रन क्लस्टर साइड पर पूरी डिस्क को पढ़ता है, भले ही वह बहुत कम डेटा अपलोड करे। टास्क लॉग में कम अपलोड फिगर के साथ लंबी अवधि दिखाई देती है, और अगला रन फिर से तेज़ होता है। यदि VPS पर हर जॉब धीमी है, तो कारण आमतौर पर datastore के बाहर होता है, और noisy neighbour से CPU steal time मापने वाली पहली चीज़ है।

FAQ

Prune job चलने के बाद भी मेरा Proxmox Backup Server datastore क्यों बढ़ता रहता है?

क्योंकि pruning केवल snapshot metadata को हटाता है: manifest, indexes, log और notes। Chunks तब तक disk पर रहते हैं जब तक garbage collection उन chunks को नहीं हटा देता जिन्हें कोई भी index refer नहीं करता। Datastore के लिए proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' के साथ एक schedule सेट करें, और proxmox-backup-manager garbage-collection start store1 से पहले और बाद में datastore path पर df -h चलाकर इसकी पुष्टि करें। कम से कम एक दिन के अंतराल की अपेक्षा रखें, क्योंकि phase two केवल उन्हीं chunks को हटाता है जिनका access time 24 घंटे और 5 मिनट से अधिक पुराना होता है।

Proxmox Backup Server VPS को कितनी disk की आवश्यकता होती है?

प्रत्येक guest द्वारा वास्तव में उपयोग की जा रही जगह को जोड़ें, फिर प्रत्येक guest के दैनिक बदलाव को उन दिनों की संख्या से गुणा करें जितने दिन आप backup रखते हैं। यह कुल योग एक अधिकतम सीमा है, क्योंकि compression और deduplication दोनों आपके पक्ष में काम करते हैं। Indexes और working room के लिए लगभग पांचवां हिस्सा जोड़ें, फिर इसे उस volume size तक round up करें जिसे आप खरीद सकते हैं। दो सप्ताह बाद datastore view में वास्तविक उपयोग के आधार पर दोबारा जाँच करें, क्योंकि पहले backup से पहले लगाया गया अनुमान हमेशा किसी न किसी दिशा में गलत होता है।

Backup encryption key को कहाँ store किया जाना चाहिए?

उस cluster के अलावा कहीं भी जिसे यह सुरक्षित करता है। Proxmox VE इसे /etc/pve/priv/storage/<storage>.enc पर रखता है, जो हर node पर replicate होता है और इसलिए cluster के साथ ही खो जाता है। इसे पहले दिन ही copy कर लें, proxmox-backup-client key paperkey के साथ print करें, और उस copy को किसी दूसरी इमारत में रखें। यह भी ध्यान रखें कि key chunk digest का हिस्सा होती है, इसलिए इसे बाद में बदलने का मतलब है कि अगला backup सब कुछ फिर से upload करेगा।

क्या मुझे प्रति Proxmox host एक datastore चाहिए, या namespaces?

प्रत्येक source host या cluster के लिए एक datastore और एक namespace रखें। Deduplication एक datastore के भीतर काम करता है, न कि datastores के बीच, इसलिए host के आधार पर split करने से एक ही base image कई बार store हो जाती है। Namespaces backup groups को अलग रखते हैं, ताकि दो hosts, जिनमें ID 100 वाला guest है, आपस में न टकराएं, और /datastore/store1/pve-home के रूप का access control path प्रत्येक host के API token को उसके अपने namespace तक सीमित रखता है।

क्या एक छोटा VPS Proxmox backup server के रूप में काम कर पाएगा?

आमतौर पर homelab के लिए हाँ, क्योंकि chunking और hashing का काम backup server के बजाय Proxmox VE node पर होता है। VPS केवल chunks लिखता है और दो भारी jobs, garbage collection और verification, चलाता है। इसे 4 GB RAM दें और verification thread counts को कम रखें। दोनों jobs को backup window के बाहर schedule करें, और यदि वे अभी भी disk की क्षमता से कहीं अधिक समय लेते हैं, तो बड़ा plan खरीदने से पहले steal time को मापें।