VPS లో Proxmox Backup Server ని సెటప్ చేయడం ఎలా

VPS పై Proxmox Backup Server మీకు ఏమి అందిస్తుంది

VPS పై Proxmox Backup Server (PBS) అనేది మీ Proxmox VE (virtual environment) క్లస్టర్ ఇప్పటికే ఉపయోగించే ప్రోటోకాల్‌ను అనుసరించే ఒక offsite target. దీనివల్ల మొదటి బ్యాకప్ తర్వాత ప్రతి బ్యాకప్ incremental గా ఉంటుంది, గెస్ట్ మెషీన్ల మధ్య deduplicate చేయబడుతుంది, మీ సర్వర్ నుండి బయటకు వెళ్లే ముందే encrypt చేయబడుతుంది మరియు తర్వాత ధృవీకరించబడుతుంది. మీరు block volume ఉన్న ఒక VPS ను అద్దెకు తీసుకుని, దానిపై Debian 13 లో PBS ను ఇన్‌స్టాల్ చేసి, ఆ volume లో ఒక datastore ను సృష్టించి, Proxmox VE లో దానిని pbs రకానికి చెందిన storage గా జోడించాలి. దీని ఇన్‌స్టాలేషన్ పది నిమిషాల్లో పూర్తవుతుంది. ఆ తర్వాత వచ్చే namespaces, garbage collection, key custody మరియు మీరు నిజంగా నిర్వహించే restore ప్రక్రియలే, ఒక సంవత్సరం తర్వాత మీ బ్యాకప్ ఎంత విలువైనదో నిర్ణయిస్తాయి.

అద్దెకు తీసుకున్న డిస్క్‌లోకి vzdump ఫైళ్లను కాపీ చేయడానికి బదులుగా PBS ను ఉపయోగించడానికి ప్రధాన కారణం దాని chunk store. క్లయింట్ ప్రతి గెస్ట్ డిస్క్‌ను సుమారు 4 MiB పరిమాణం గల chunks గా విభజించి, వాటికి hashes సృష్టిస్తుంది. datastore లో ఇప్పటికే లేని chunks ను మాత్రమే అది అప్‌లోడ్ చేస్తుంది. నడుస్తున్న virtual machine కోసం, మొదటి బ్యాకప్ తర్వాత QEMU ఒక dirty bitmap లో మారిన blocks ను ట్రాక్ చేస్తుంది, కాబట్టి తదుపరి బ్యాకప్ సమయంలో స్థానిక డిస్క్ నుండి ఆ blocks ను మాత్రమే చదువుతుంది. రోజుకు 3 GB డేటా మారే 200 GB గెస్ట్ మెషీన్, రోజుకు సుమారు 3 GB డేటాను మాత్రమే పంపుతుంది. ఇదే మీ ఇంటి ఇంటర్నెట్ కనెక్షన్ మరియు అద్దెకు తీసుకున్న volume కలిసి పనిచేసేలా చేస్తుంది, అందుకే offsite backup target గా VPS అనేది స్నేహితుడి ఇంట్లో ఉంచిన అదనపు డ్రైవ్ కంటే మెరుగైనది. హైపర్‌వైజర్ ఎక్కడ ఉండాలో మీరు ఇంకా నిర్ణయించుకోకపోతే, ఇంట్లో Proxmox vs అద్దె VPS అనే అంశం ఆ ప్రశ్నకు విడిగా సమాధానం ఇస్తుంది.

వాల్యూమ్‌ను అద్దెకు తీసుకునే ముందు దాని పరిమాణాన్ని నిర్ణయించండి

పరిమాణాన్ని నిర్ణయించడం అనేది మీరు మీ స్వంత గణాంకాలపై చేసే అంకగణితం. ప్రతి guest వాస్తవంగా ఎంత స్థలాన్ని ఉపయోగిస్తుందో చూడండి, దాని virtual disk పరిమాణాన్ని కాదు. ఆపై రోజుకు ఎంత మారుతుందో దాన్ని లెక్కించి, మీరు బ్యాకప్‌లను ఉంచే రోజుల సంఖ్యతో గుణించండి. Compression మరియు deduplication ఈ గణాంకాలను మెరుగుపరుస్తాయి, కాబట్టి వచ్చిన ఫలితాన్ని గరిష్ట పరిమితిగా పరిగణించండి, లక్ష్యంగా కాదు.

[
  {
    "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 లోని రెండవ మరియు మూడవ బ్యాకప్‌ల పరిమాణం ద్వారా రోజువారీ మార్పును తెలుసుకోండి.

ఉదాహరణలోని mail guest 120 GB స్థలాన్ని ఉపయోగిస్తుంది మరియు రోజుకు సుమారు 3.0 GB మారుతుంది. కాబట్టి, ముప్పై రోజుల snapshots కోసం సుమారు 210 GB అవసరం: ఒక పూర్తి కాపీ మరియు ముప్పై రోజుల మార్పులు. మొత్తం 3 guests కోసం చివరి కాలమ్‌ను కలిపితే మొత్తం సుమారు 619 GB అవుతుంది. indexes, metadata మరియు garbage collection సమర్థవంతంగా పనిచేయడానికి అదనంగా మరో ఐదవ వంతు స్థలాన్ని కలిపితే, 1 TB వాల్యూమ్ సరిపోతుంది.

మిగిలిన ప్రణాళిక చాలా చిన్నది. PBS కు 2 GB RAM సరిపోతుంది, 4 GB ఉంటే మరింత సౌకర్యవంతంగా ఉంటుంది. ఎందుకంటే ప్రధానమైన పని cluster వైపు జరుగుతుంది: Proxmox VE node guest disks ను చదివి, chunking మరియు hashing చేస్తుంది. VPS చేసే పని chunks ను రాయడం మరియు garbage collection, verification వంటి రెండు భారీ పనులను నిర్వహించడం. Datastore ను ఒకే పెద్ద root disk గా కాకుండా, విడి block volume గా అద్దెకు తీసుకోండి. ఎందుకంటే సర్వర్‌ను మళ్లీ నిర్మించాల్సిన అవసరం లేకుండానే, వాల్యూమ్‌ను తర్వాత పెంచుకోవచ్చు.

Debian 13 పై Proxmox Backup Server ఇన్‌స్టాలేషన్

ఆగస్టు 2026 నాటికి, ప్రస్తుత వెర్షన్ Debian 13 (కోడ్‌నేమ్ trixie) పై Proxmox Backup Server 4. పాత గైడ్‌లు PBS 2 ను Debian 11 తో సూచిస్తాయి; repository definition లో కోడ్‌నేమ్ భాగమై ఉంటుంది కాబట్టి, పాత suite పేరును ఉపయోగిస్తే missing release file అని apt error వస్తుంది. కాబట్టి, కొత్త 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 repository ని /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 port 8007 లో అందుబాటులో ఉంటుంది. సిస్టమ్ root పాస్‌వర్డ్‌తో root@pam గా లాగిన్ అవ్వండి, ఎందుకంటే PBS ఆ యూజర్‌ను PAM (pluggable authentication modules) ద్వారా ధృవీకరిస్తుంది; ఇది ఆపరేటింగ్ సిస్టమ్ ఉపయోగించే అదే అకౌంట్. ఈ సర్టిఫికేట్ self-signed కాబట్టి మీ బ్రౌజర్ హెచ్చరికను చూపిస్తుంది. ఆ సర్టిఫికేట్ యొక్క fingerprint విలువనే Proxmox VE తర్వాత పిన్ చేస్తుంది, కాబట్టి ఈ హెచ్చరిక సాధారణమే, ఇది పరిష్కరించాల్సిన సమస్య కాదు.

Port 8007 పబ్లిక్ ఇంటర్నెట్‌లో లాగిన్ ఫారమ్‌ను కలిగి ఉంటుంది, కాబట్టి దీన్ని అందరికీ అందుబాటులో ఉంచవద్దు. ఒక nftables ఫైల్ దీనికి సరిపోతుంది. /etc/nftables.conf ని రాయడం వల్ల ప్రస్తుత ruleset 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 లో ఒక చిన్న తప్పు చేసినా మీరు మీ సర్వర్ నుండి లాక్ అవుతారు. 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

lsblk నుండి device పేరును తీసుకోండి. చాలా KVM images లో ఇది /dev/vdb గా, మరికొన్నింటిలో /dev/sdb గా ఉంటుంది, కాబట్టి దేనినీ ఊహించడం సురక్షితం కాదు. Reboot తర్వాత device పేరు మారినా datastore తప్పుడు disk కు మళ్ళించబడకుండా ఉండటానికి, label ద్వారా /etc/fstab లో mount ను జోడించండి:

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 ను చూపించాలి. ఈ ఒక్క లైన్‌లోనే రెండు రకాల వైఫల్యాలు దాగి ఉన్నాయి. ఒకవేళ mount లేకపోయినా మీరు datastore ను సృష్టిస్తే, PBS ఆ mount point కింద ఉన్న root filesystem లోనే డేటాను రాస్తుంది. ఆ తర్వాత మీరు mount చేసినప్పుడు, పాత డేటా కనబడకుండా పోతుంది కానీ డిలీట్ అవ్వదు: అప్పుడు datastore ఖాళీగా కనిపిస్తుంది, కానీ root filesystem నిండుగానే ఉంటుంది. ఒకవేళ options లో noatime అని ఉంటే, PBS పనిచేయడానికి నిరాకరిస్తుంది. ఎందుకంటే datastore సృష్టించినప్పుడు మరియు ప్రతి garbage collection సమయంలో అది access time safety check ను నిర్వహిస్తుంది.

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

ఇది 65536 subdirectories కలిగిన ఒక .chunks డైరెక్టరీని సృష్టిస్తుంది, వీటి పేర్లు 0000 నుండి ffff వరకు ఉంటాయి. Datastore అంటే కొన్ని పెద్ద ఫైళ్లు కాదు, లక్షలాది చిన్న ఫైళ్ల సమాహారం. దీనివల్ల రెండు విషయాలు గుర్తుంచుకోవాలి. సాధారణ file-level tool తో datastore ను కాపీ చేయడం చాలా నెమ్మదిగా ఉంటుంది, అది పనికిరాదు. అలాగే, backups నడుస్తున్నప్పుడు తీసుకునే provider volume snapshot అనేది datastore కు ఒక consistent కాపీ కాదు. అందుకే snapshots backups కు ప్రత్యామ్నాయం కావు, ఇది ఎక్కడైనా వర్తిస్తుంది.

Namespaces రెండు హోస్ట్‌ల మధ్య ఘర్షణను నివారిస్తాయి

Datastore డిఫాల్ట్‌గా ఫ్లాట్‌గా ఉంటుంది. బ్యాకప్‌లకు vm/100, ct/101 మరియు host/<name> అని పేర్లు ఉంటాయి. ID 100 కలిగిన గెస్ట్ ఉన్న రెండు క్లస్టర్‌లు ఒకే గ్రూప్‌లోకి డేటాను రాస్తే, వాటి స్నాప్‌షాట్‌లు కలిసిపోతాయి; ఒక దాని కోసం రాసిన రిటెన్షన్ రూల్ మరొక దాని స్నాప్‌షాట్‌లను కూడా పరిగణనలోకి తీసుకుంటుంది. Namespaces ప్రతి సోర్స్‌కు ఒకే datastore లోపల ప్రత్యేకమైన ట్రీని అందిస్తాయి.

వీటిని 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 మొత్తం datastore అంతటా షేర్ చేయబడతాయి, కాబట్టి మూడు namespaces లో విస్తరించి ఉన్న పది Debian గెస్ట్‌లు కూడా బేస్ సిస్టమ్ యొక్క ఒకే కాపీని స్టోర్ చేస్తాయి. హోస్ట్‌కు ఒక datastore చొప్పున కాకుండా, namespaces తో కూడిన ఒకే datastore ను ఎంచుకోవడానికి ఇదే ప్రధాన కారణం: విడివిడి datastores అంటే విడివిడి chunk pools అని అర్థం, దీనివల్ల ఒకే Debian ఇన్‌స్టాలేషన్ కోసం పదేపదే ఖర్చు చేయాల్సి వస్తుంది.

ప్రతి సోర్స్‌కు దాని స్వంత namespace కు పరిమితమైన ప్రత్యేక ఖాతాను ఇవ్వండి. API (application programming interface) token అనేది ఒక యూజర్‌కు చెందిన క్రెడెన్షియల్ మరియు ఇది సొంత అనుమతులను కలిగి ఉంటుంది; దొంగిలించబడే అవకాశం ఉన్న మెషీన్‌పై మీకు ఇదే అవసరం.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

Token కమాండ్ సీక్రెట్‌ను ఒక్కసారి మాత్రమే ప్రింట్ చేస్తుంది:

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

దీనిని వెంటనే కాపీ చేయండి, ఎందుకంటే PBS దీనిని మళ్ళీ చూపించలేదు. Access control కమాండ్‌ను రెండుసార్లు చూడండి. ఇది యూజర్‌ను కాకుండా, backup@pbs!pve-home అనే టోకెన్‌ను పేర్కొంటుంది, ఎందుకంటే టోకెన్ అనుమతులు టోకెన్‌ను నేరుగా పేర్కొనే ఎంట్రీల నుండి మాత్రమే లెక్కించబడతాయి. కేవలం backup@pbs కోసం మాత్రమే ఉన్న ఎంట్రీ వల్ల టోకెన్‌కు ఎటువంటి యాక్సెస్ ఉండదు, అప్పుడు మొదటి బ్యాకప్ నెట్‌వర్క్‌లో కనిపించే దేనివల్లనో కాకుండా, అనుమతుల సమస్య వల్ల విఫలమవుతుంది. పాత్ (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 వైపు ఉంటుంది, దీని గురించి కింద వివరించబడింది. దీనికి ఒక ముఖ్యమైన కారణం ఉంది: అప్పుడు టోకెన్‌కు తొలగించే అనుమతి అవసరం ఉండదు. కాబట్టి, ransomware బారిన పడిన క్లస్టర్, మిమ్మల్ని రక్షించాల్సిన ఆఫ్-సైట్ హిస్టరీని చేరుకుని తొలగించలేదు.

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 గిగాబిట్లు, మరియు 100 Mbit అప్‌లింక్ సెకనుకు 0.1 గిగాబిట్‌ను తరలిస్తుంది. కాబట్టి కనీస సమయం సుమారు నాలుగున్నర గంటలు పడుతుంది, వాస్తవానికి ఇంకా ఎక్కువ సమయం పట్టవచ్చు. మీకు బ్యాండ్‌విడ్త్ అవసరం లేని సమయంలో దీనిని ప్రారంభించండి. ఆ తర్వాత జరిగే ప్రతి రన్ కేవలం కొత్త చంక్స్‌ను మాత్రమే పంపుతుంది.

క్లయింట్-సైడ్ ఎన్‌క్రిప్షన్ మరియు కీ ఎక్కడ ఉంటుంది

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 మాస్టర్ కీని కూడా సపోర్ట్ చేస్తుంది. ఇది proxmox-backup-client key create-master-key తో సృష్టించబడిన RSA (Rivest Shamir Adleman) కీ జత. ఇందులో ప్రతి బ్యాకప్ తన సొంత ఎన్‌క్రిప్షన్ కీని పబ్లిక్ హాఫ్ ద్వారా ఎన్‌క్రిప్ట్ చేసి నిల్వ చేస్తుంది, అయితే ప్రైవేట్ హాఫ్ రికవరీ కోసం ఆఫ్‌లైన్‌లో ఉంటుంది.

ఈ డిజైన్ వల్ల కలిగే ఒక పరిణామాన్ని మీరు ప్రారంభించే ముందే తెలుసుకోవడం మంచిది. ఎన్‌క్రిప్ట్ చేసిన బ్యాకప్‌ల కోసం, చంక్ డైజెస్ట్ (chunk digest) అనేది ప్లెయిన్ టెక్స్ట్ కంటెంట్‌ను ఎన్‌క్రిప్షన్ కీతో కలిపి లెక్కించబడుతుంది. కాబట్టి, వేర్వేరు కీలతో ఎన్‌క్రిప్ట్ చేయబడిన రెండు ఒకేలాంటి డేటా ముక్కలు వేర్వేరు డైజెస్ట్‌లను ఉత్పత్తి చేస్తాయి మరియు ఒకదానితో ఒకటి డీడూప్లికేట్ (deduplicate) కావు. కీని మార్చడం అంటే తదుపరి బ్యాకప్ ప్రతిదీ మళ్ళీ అప్‌లోడ్ చేస్తుంది, మరియు పాత ముక్కలు వాటి స్నాప్‌షాట్‌లు తొలగించబడే వరకు అక్కడే ఉంటాయి. మొదటి అప్‌లోడ్‌కు ముందే ఎన్‌క్రిప్షన్ గురించి నిర్ణయం తీసుకోండి.

Prune మార్కులు, గార్బేజ్ కలెక్షన్ రీక్లెయిమ్

ఈ విభాగం దాటవేయబడుతుంది, మరియు వాల్యూమ్‌ను నింపేది ఇదే. ఒక snapshot ను prune చేయడం వల్ల దాని మెటాడేటా (manifest, indexes, log మరియు notes) తొలగించబడుతుంది. ఇది ఏ chunks ను తొలగించదు. Chunks అనేవి snapshot ల మధ్య భాగస్వామ్యం చేయబడతాయి, కాబట్టి ప్రతి మిగిలిన index ను చదివే వరకు ఒక chunk ఉపయోగంలో లేదని ఏదీ గుర్తించలేదు, మరియు ఆ పనిని గార్బేజ్ కలెక్షన్ చేస్తుంది. Prune షెడ్యూల్ ఉండి, గార్బేజ్ కలెక్షన్ షెడ్యూల్ లేని datastore పరిమాణం పెరుగుతూనే ఉంటుంది.

రెండింటినీ సెట్ చేయండి. ముందుగా 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 పై కలెక్షన్ షెడ్యూల్, prune జాబ్ జరిగిన కొన్ని గంటల తర్వాత మరియు బ్యాకప్ విండో సమయం కాకుండా:

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 రన్ చేయండి, అప్పుడు ఉపయోగించిన స్థలం (used figure) మారదు. గార్బేజ్ కలెక్షన్‌ను రన్ చేయండి, ఆపై మళ్ళీ df రన్ చేయండి, అప్పుడు అది మారుతుంది.

గార్బేజ్ కలెక్షన్ రెండు దశల్లో జరుగుతుంది. మొదటి దశ datastore లోని ప్రతి index ను పరిశీలించి, ఆ indexes సూచించే ప్రతి chunk యొక్క access time ను అప్‌డేట్ చేస్తుంది. రెండవ దశ, రన్ ప్రారంభానికి 24 గంటల 5 నిమిషాల ముందు లేదా ఇంకా రాస్తున్న పాత బ్యాకప్ ప్రారంభ సమయం (ఏది ముందైతే అది) కంటే పాత access time ఉన్న chunks ను తొలగిస్తుంది. ఈ మార్జిన్ ఎందుకంటే, Linux ఫైల్‌సిస్టమ్‌లను డిఫాల్ట్‌గా relatime తో మౌంట్ చేస్తుంది, ఇది ప్రతి రీడ్‌కు కాకుండా రోజుకు ఒకసారి మాత్రమే access time ను అప్‌డేట్ చేస్తుంది. కాబట్టి, ఒక గంట క్రితం రాసిన chunk, దేని ద్వారా కూడా సూచించబడకపోయినా తొలగించబడదు. Prune ద్వారా ఖాళీ అయిన స్థలం, ఆ chunk చివరిసారిగా తాకిన సమయం నుండి ఒక రోజు దాటిన తర్వాత జరిగే మొదటి కలెక్షన్‌లో కనిపిస్తుంది. ఏమీ రీక్లెయిమ్ చేయనట్లు కనిపించే datastore, తరచుగా ఆ విండోలోనే ఉంటుంది.

చిన్న VPS లలో ఇది అత్యంత భారమైన జాబ్, ఎందుకంటే ఇది వాల్యూమ్‌లోని ప్రతి chunk ఫైల్‌ను stat చేస్తుంది. టాస్క్ లాగ్ చివరలో ఏమి తొలగించబడ్డాయి మరియు గ్రేస్ పీరియడ్ కారణంగా ఇంకా ఏమి పెండింగ్‌లో ఉన్నాయి అనే సారాంశం ఉంటుంది. ఒకవేళ ఎక్కువ పెండింగ్‌లో ఉంటే, మరుసటి రోజు మళ్ళీ రన్ చేయండి. PBS లో gc-atime-safety-check మరియు gc-atime-cutoff అనేవి datastore ట్యూనింగ్ ఆప్షన్లుగా ఉంటాయి, వీటిని మార్చకూడదు: ఇవి access time ను రికార్డ్ చేయలేని స్టోరేజ్ కోసం ఉంటాయి. noatime తో మౌంట్ చేసిన ఫైల్‌సిస్టమ్‌పై ఈ సేఫ్టీ చెక్‌ను ఆఫ్ చేయడం వల్ల, లైవ్ snapshot లు సూచించే chunks ను కోల్పోయే ప్రమాదం ఉంది.

చంక్స్ చదవగలిగే స్థితిలో ఉన్నాయని నిర్ధారించుకోవడం

సరిగ్గా అప్‌లోడ్ అయిన బ్యాకప్ కూడా ఒక సంవత్సరం తర్వాత చదవలేని స్థితికి చేరుకోవచ్చు. వెరిఫికేషన్ ప్రక్రియ చంక్స్‌ను తిరిగి చదివి, ఇండెక్స్‌లో నిల్వ ఉన్న చెక్‌సమ్స్‌తో పోల్చి చూస్తుంది. దీనివల్ల రీస్టోర్ చేసే సమయంలో కాకుండా, ముందే షెడ్యూల్ ప్రకారం డేటాలో నష్టం జరిగిందేమో తెలుస్తుంది.

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

చిన్న VPS లలో తక్కువ త్రెడ్ కౌంట్‌ను ఉపయోగించండి. వెరిఫికేషన్ అనేది డిస్క్ మరియు CPU సామర్థ్యంపై ఆధారపడి ఉంటుంది, కాబట్టి ఇది సర్వర్‌లో నడుస్తున్న ఇతర పనులతో పోటీ పడవచ్చు. షెడ్యూల్ కోసం, వెబ్ ఇంటర్‌ఫేస్‌లోని datastore యొక్క Verify Jobs ట్యాబ్‌ను ఉపయోగించండి: ఇప్పటికే వెరిఫై అయిన స్నాప్‌షాట్‌లను వదిలేసి, 30 రోజుల కంటే పాత వాటిని తిరిగి వెరిఫై చేసేలా వారానికోసారి ఒక జాబ్‌ను సెట్ చేయండి. ఇది పనులను పునరావృతం చేయకుండా మొత్తం స్టోర్‌ను కవర్ చేస్తుంది.

వెరిఫికేషన్ విఫలమైన స్నాప్‌షాట్, datastore వ్యూలో failed అని మార్క్ చేయబడుతుంది. దీన్ని నిర్లక్ష్యం చేయవద్దు. చంక్స్ షేర్ చేయబడతాయి కాబట్టి, బేస్ ఇమేజ్‌లోని ఒక దెబ్బతిన్న చంక్, దాన్ని రిఫరెన్స్ చేసే ప్రతి స్నాప్‌షాట్‌ను విఫలం చేస్తుంది. దీనికి పరిష్కారం ఏమిటంటే, విఫలమైన స్నాప్‌షాట్‌లను తొలగించి, కొత్త బ్యాకప్‌ను రన్ చేయడం; ఇది తప్పిపోయిన చంక్స్‌ను మళ్లీ అప్‌లోడ్ చేస్తుంది. ఒకవేళ లోపాలు మళ్లీ మళ్లీ కనిపిస్తుంటే, datastore కింద ఉన్న స్టోరేజ్‌ను అనుమానించాలి. కాబట్టి, డ్రైవ్ వెరిఫై జాబ్ కంటే ముందే మీకు హెచ్చరిక ఇచ్చేలా VPS లో డిస్క్ హెల్త్ మానిటరింగ్‌ను సెటప్ చేయండి.

రీస్టోర్‌ను పరీక్షించండి, ఆపై క్లస్టర్ లేకుండా దాన్ని పరీక్షించండి

బ్యాకప్ పనిచేస్తుందని మీరు నిర్ధారించుకోవాలంటే, దాన్ని రీస్టోర్ చేసి చూడాలి. ఇక్కడ రెండు రకాల పరీక్షలు ఉన్నాయి, ఇవి వేర్వేరు అంశాలను తనిఖీ చేస్తాయి.

క్లస్టర్‌పై పూర్తి గెస్ట్ (guest) రీస్టోర్:

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

pvesm list లోని మొదటి కాలమ్ వాల్యూమ్ IDని సూచిస్తుంది, మరియు టైమ్‌స్టాంప్ అందులో భాగంగా ఉంటుంది, కాబట్టి ఉదాహరణను టైప్ చేయకుండా మీ స్వంత IDని కాపీ చేయండి. దీన్ని ఉపయోగించని గెస్ట్ 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 చూపిన దాని నుండి తీసుకోండి. మొదటి పరీక్ష చేయలేని పనిని ఇది నిరూపిస్తుంది: మీ కీ ఫైల్ కాపీ అసలైన డేటాను డీక్రిప్ట్ చేయగలదని, మరియు మీ క్లస్టర్ కాన్ఫిగరేషన్ ఎప్పుడూ లేని మెషీన్ నుండి కూడా మీరు క్లయింట్‌ను నడపగలరని ఇది రుజువు చేస్తుంది. దీనికి అవసరమైన నాలుగు విలువలను - రిపోజిటరీ స్ట్రింగ్, టోకెన్ సీక్రెట్, ఫింగర్‌ప్రింట్ మరియు కీ ఫైల్ - రాసి పెట్టుకోండి, మరియు మీ డిజాస్టర్ ప్లాన్ సూచించిన చోట వాటిని భద్రపరచండి.

Deduplication మీ డిస్క్ బిల్లుపై చూపే ప్రభావం ఏమిటి మరియు ఏమిటి కాదు

Deduplication అనేది వాస్తవం, ఇది మొత్తం datastore అంతటా పనిచేస్తుంది. పది Debian గెస్ట్ సిస్టమ్‌లు ఒకే base system కాపీని పంచుకుంటాయి, కాబట్టి రెండవ అదే విధమైన గెస్ట్ సిస్టమ్‌ను నిల్వ చేయడానికి దాదాపు ఖర్చు ఉండదు. ఇది upload bandwidth ను కూడా ఆదా చేస్తుంది, ఎందుకంటే సర్వర్‌లో ఇప్పటికే ఉన్న ఏదైనా chunk కోసం క్లయింట్ డేటాకు బదులుగా checksum ను పంపుతుంది.

ఇది ఏమి చేయదో స్పష్టంగా తెలుసుకోవడం ముఖ్యం.

• ఇది మారుతున్న డేటాను తగ్గించదు. ప్రతి రాత్రి తన ఫైళ్లలో పెద్ద భాగాలను తిరిగి రాసే database ప్రతి రాత్రి కొత్త chunks ను సృష్టిస్తుంది, మరియు retention వాటిని పెంచుతుంది.
• ఇది పైన పేర్కొన్న విధంగా encryption key సరిహద్దులను దాటి పనిచేయదు.
• ఇది datastore సరిహద్దులను దాటి పనిచేయదు, ఇదే namespaces కోసం ఉన్న ప్రధాన వాదన.
• ఇది volume నిండకుండా ఆపలేదు. Datastore నిండినప్పుడు, backups విఫలమవుతాయి, అప్పుడు పెద్ద volume లేదా తక్కువ retention మాత్రమే పరిష్కారాలు.

దీని కింద మరొక deduplication పొరను వేయకండి. Chunks ఇప్పటికే క్లయింట్ ద్వారా deduplicate మరియు compress చేయబడి వస్తాయి, కాబట్టి datastore కింద ZFS deduplication అనేది వ్రాయబడకముందే తొలగించబడిన matches కోసం వెతకడానికి RAM ను వృథా చేస్తుంది. ఇక్కడ volume కోసం సాధారణ ext4 లేదా xfs సరైన ఎంపిక.

Web interface datastore కోసం deduplication factor ను నివేదిస్తుంది. ఆ సంఖ్య మీ గెస్ట్ సిస్టమ్‌లను వివరిస్తుంది, మరియు ప్లానింగ్ కోసం అదే పరిగణించదగినది, ఎందుకంటే ప్రచురించబడిన నిష్పత్తులు వేరొకరి డేటాను వివరిస్తాయి. మీకు Proxmox గెస్ట్‌లు కాని యంత్రాల file-level backups కూడా అవసరమైతే, వాటిని అదే VPS లో పక్కపక్కనే రన్ చేయండి: PBS అనేది మొత్తం గెస్ట్ సిస్టమ్‌ల కోసం hypervisor-aware లక్ష్యం, అయితే 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 లో ఆప్షన్‌ను సరిచేసి, మళ్లీ మౌంట్ చేయండి. దీన్ని అధిగమించడానికి చెక్‌ను డిసేబుల్ చేయవద్దు.

డేటాస్టోర్ పరిమాణం పెరుగుతూనే ఉంది. ప్రూన్ జాబ్‌లు రన్ అవుతున్నాయి కానీ ఏదీ రీక్లెయిమ్ అవ్వడం లేదు. గార్బేజ్ కలెక్షన్ షెడ్యూల్ లేకపోవడం లేదా బ్యాకప్‌ల తర్వాత వెంటనే రన్ అవ్వడం వల్ల ప్రతి కలెక్షన్ 24 గంటల గ్రేస్ విండోలోనే పడటం దీనికి కారణం కావచ్చు. proxmox-backup-manager datastore show store1 తో షెడ్యూల్‌ను తనిఖీ చేయండి.

గతంలో వేగంగా జరిగిన బ్యాకప్ ఇప్పుడు గంటల సమయం తీసుకుంటోంది. ఆగిపోయిన, మైగ్రేట్ అయిన లేదా రీస్టోర్ చేసిన గెస్ట్ దాని డర్టీ బిట్‌మ్యాప్‌ను కోల్పోతుంది. కాబట్టి, క్లస్టర్ వైపు చాలా తక్కువ డేటా అప్‌లోడ్ అయినప్పటికీ, తదుపరి రన్ మొత్తం డిస్క్‌ను రీడ్ చేస్తుంది. టాస్క్ లాగ్‌లో తక్కువ అప్‌లోడ్ ఫిగర్‌తో ఎక్కువ సమయం కనిపిస్తుంది, ఆ తర్వాత రన్ మళ్లీ వేగంగా జరుగుతుంది. ఒకవేళ VPS లోని ప్రతి జాబ్ నెమ్మదిగా ఉంటే, సమస్య సాధారణంగా డేటాస్టోర్ వెలుపల ఉంటుంది, అప్పుడు CPU steal time from a noisy neighbour ను మొదటగా కొలవాలి.

FAQ

Prune job రన్ అయినప్పుడు నా Proxmox Backup Server datastore ఎందుకు పెరుగుతూనే ఉంది?

ఎందుకంటే pruning కేవలం snapshot metadataను మాత్రమే తొలగిస్తుంది: అంటే manifest, indexes, log మరియు notes. ఏ index కూడా రిఫర్ చేయని chunks ను garbage collection తొలగించే వరకు అవి డిస్క్‌లోనే ఉంటాయి. 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 లో 24 గంటలు మరియు 5 నిమిషాల కంటే పాత access time ఉన్న chunks మాత్రమే తొలగించబడతాయి.

Proxmox Backup Server VPS కి ఎంత డిస్క్ స్పేస్ అవసరం?

ప్రతి guest వాస్తవానికి ఎంత స్పేస్ వాడుతుందో లెక్కించండి, ఆపై మీరు బ్యాకప్‌లను ఎన్ని రోజులు ఉంచుతారో, ఆ రోజులతో ప్రతి guest యొక్క రోజువారీ మార్పును (daily change) గుణించి కలపండి. Compression మరియు deduplication మీకు అనుకూలంగా పనిచేస్తాయి కాబట్టి, ఆ మొత్తం ఒక గరిష్ట పరిమితి (ceiling) అవుతుంది. Indexes మరియు పని చేయడానికి అవసరమైన స్థలం కోసం మరో ఐదవ వంతు (one-fifth) అదనంగా కలపండి, ఆపై మీరు కొనుగోలు చేయగల volume size కి దాన్ని రౌండ్ అప్ చేయండి. మొదటి బ్యాకప్‌కు ముందు చేసిన అంచనా ఎప్పుడూ ఏదో ఒక వైపు తప్పుగా ఉంటుంది కాబట్టి, రెండు వారాల తర్వాత datastore view లో వాస్తవ వినియోగాన్ని మళ్ళీ తనిఖీ చేయండి.

Backup encryption key ని ఎక్కడ భద్రపరచాలి?

అది ఏ cluster ని అయితే రక్షిస్తుందో, ఆ cluster లో తప్ప మరెక్కడైనా భద్రపరచవచ్చు. Proxmox VE దీన్ని /etc/pve/priv/storage/<storage>.enc వద్ద ఉంచుతుంది, ఇది ప్రతి node కి replicate అవుతుంది, కాబట్టి cluster పోతే ఇది కూడా పోతుంది. మొదటి రోజే దీన్ని కాపీ చేయండి, proxmox-backup-client key paperkey తో ప్రింట్ తీసుకోండి, మరియు ఆ కాపీని వేరే భవనంలో భద్రపరచండి. Key అనేది chunk digest లో భాగంగా ఉంటుందని గమనించండి, కాబట్టి దీన్ని తర్వాత మార్చడం అంటే తదుపరి బ్యాకప్ అంతా మళ్ళీ అప్‌లోడ్ అవ్వడమే.

నాకు ప్రతి Proxmox host కి ఒక datastore కావాలా, లేక namespaces సరిపోతాయా?

ప్రతి source host లేదా cluster కి ఒక datastore, ఒక namespace సరిపోతుంది. Deduplication అనేది datastore లోపల మాత్రమే పనిచేస్తుంది, వేర్వేరు datastores మధ్య పనిచేయదు, కాబట్టి host వారీగా విడగొడితే ఒకే base image ను పలుమార్లు స్టోర్ చేయాల్సి వస్తుంది. Namespaces బ్యాకప్ గ్రూపులను వేరుగా ఉంచుతాయి, కాబట్టి రెండు 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 ను రాయడం మరియు garbage collection, verification వంటి రెండు భారీ పనులను మాత్రమే చేస్తుంది. దీనికి 4 GB RAM కేటాయించండి మరియు verification thread counts తక్కువగా ఉంచండి. రెండు పనులను బ్యాకప్ సమయం కాకుండా వేరే సమయంలో షెడ్యూల్ చేయండి, ఒకవేళ డిస్క్ సామర్థ్యం కంటే అవి ఎక్కువ సమయం తీసుకుంటుంటే, పెద్ద ప్లాన్ కొనే ముందు steal time ను కొలవండి.