VPS-ல் Proxmox Backup Server அமைப்பது எப்படி?

VPS-ல் Proxmox Backup Server பயன்படுத்துவதால் கிடைக்கும் நன்மைகள்

VPS-ல் இயங்கும் Proxmox Backup Server (PBS) என்பது உங்கள் Proxmox VE (virtual environment) cluster ஏற்கனவே பயன்படுத்தும் அதே protocol-ஐ ஆதரிக்கும் ஒரு offsite சேமிப்பகமாகும். இதனால் முதல்முறை செய்யப்படும் backup-க்கு பிறகு, அடுத்தடுத்த backup-கள் அனைத்தும் incremental முறையில் அமையும். இவை guests-க்கு இடையே deduplicate செய்யப்பட்டு, உங்கள் இடத்திலிருந்து வெளியேறும் முன்பே encrypt செய்யப்படுகின்றன; மேலும், பின்னர் இவற்றை சரிபார்க்கவும் (verifiable) முடியும். நீங்கள் ஒரு block volume கொண்ட VPS-ஐ வாடகைக்கு எடுத்து, அதில் Debian 13-ஐ நிறுவி, அந்த volume-ல் ஒரு datastore-ஐ உருவாக்கி, அதை Proxmox VE-ல் pbs வகை storage-ஆகச் சேர்க்க வேண்டும். இந்த நிறுவல் பணி பத்து நிமிடங்களில் முடிந்துவிடும். இதற்குப் பிறகு நீங்கள் செய்யும் namespaces, garbage collection, key custody மற்றும் நீங்கள் உண்மையில் செய்து பார்த்த restore ஆகியவையே, ஓராண்டு கழித்து அந்த backup பயனுள்ளதாக இருக்குமா என்பதைத் தீர்மானிக்கின்றன.

வாடகை வட்டில் vzdump கோப்புகளை நகலெடுப்பதற்குப் பதிலாக PBS-ஐப் பயன்படுத்துவதற்கான காரணம் அதன் chunk store ஆகும். client ஒவ்வொரு guest disk-ஐயும் சுமார் 4 MiB அளவுள்ள chunks-ஆகப் பிரித்து, அவற்றிற்கு hash உருவாக்கி, datastore-ல் ஏற்கனவே இல்லாத chunks-ஐ மட்டுமே upload செய்கிறது. இயங்கிக்கொண்டிருக்கும் virtual machine-க்கு, முதல் backup-க்குப் பிறகு QEMU மாற்றப்பட்ட blocks-ஐ dirty bitmap மூலம் கண்காணிக்கிறது. எனவே, அடுத்தடுத்த backup-களில் local disk-லிருந்து அந்த மாற்றப்பட்ட blocks மட்டுமே வாசிக்கப்படும். ஒரு நாளைக்கு 3 GB மாற்றமடையும் 200 GB guest, தினமும் சுமார் 3 GB தரவை மட்டுமே அனுப்பும். இதுவே வீட்டு இணைய இணைப்பையும் வாடகை வட்டு சேமிப்பகத்தையும் ஒருங்கிணைந்து செயல்பட வைக்கிறது. நண்பரின் வீட்டில் இருக்கும் ஒரு spare drive-ஐ விட offsite backup target-ஆக VPS ஏன் சிறந்தது என்பதற்கான காரணம் இதுதான். hypervisor-ஐ எங்கு நிறுவுவது என்று நீங்கள் இன்னும் முடிவெடுக்கவில்லை என்றால், வீட்டில் Proxmox vs வாடகை VPS என்ற கட்டுரை அந்த வினாவிற்குத் தனித்தனியாகப் பதிலளிக்கிறது.

வாடகைக்கு எடுக்கும் முன் volume-ன் அளவைத் தீர்மானித்தல்

அளவு நிர்ணயம் என்பது உங்கள் சொந்த எண்களைக் கொண்டு செய்யப்படும் ஒரு கணக்கீடு ஆகும். ஒவ்வொரு guest-ம் உண்மையில் பயன்படுத்தும் இடத்தைக் கணக்கில் கொள்ளுங்கள்; அதன் virtual disk அளவை அல்ல. அதனுடன், ஒரு நாளைக்கு அந்த guest-ல் ஏற்படும் மாற்றங்களை, நீங்கள் தரவுகளைச் சேமித்து வைக்கும் நாட்களின் எண்ணிக்கையால் பெருக்கிச் சேர்த்துக் கொள்ளுங்கள். 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-ல் இரண்டாவது மற்றும் மூன்றாவது backups உருவான பிறகு, அவற்றின் அளவைக் கொண்டு தினசரி மாற்றத்தைக் கண்டறியுங்கள்.

இந்த உதாரணத்தில் உள்ள 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 பக்கத்திலேயே நடக்கின்றன: Proxmox VE node guest disks-ஐப் படித்து, chunking மற்றும் hashing செய்கிறது. VPS செய்வது என்னவென்றால், chunks-ஐ எழுதுவது மற்றும் garbage collection, verification ஆகிய இரண்டு கடினமான பணிகளை இயக்குவது மட்டுமே. Datastore-ஐ ஒரே பெரிய root disk-ஆக இல்லாமல், தனித்தனி block volume-ஆக வாடகைக்கு எடுங்கள். ஏனெனில், server-ஐ மீண்டும் உருவாக்காமலேயே பிற்காலத்தில் volume-ன் அளவை உங்களால் அதிகரிக்க முடியும்.

Debian 13-ல் Proxmox Backup Server-ஐ நிறுவுதல்

ஆகஸ்ட் 2026 நிலவரப்படி, தற்போதைய இணக்கம் Debian 13 (குறியீட்டுப் பெயர் trixie) இயங்குதளத்தில் Proxmox Backup Server 4 ஆகும். பழைய வழிகாட்டிகள் PBS 2-ஐ Debian 11-உடன் இணைக்கின்றன; repository வரையறையில் குறியீட்டுப் பெயர் இருப்பதால், பழைய suite பெயரைப் பயன்படுத்தினால் missing release file என்ற apt பிழை ஏற்படும். சுத்தமான Debian 13 image-லிருந்து தொடங்கவும். கீழே உள்ள அனைத்தையும் 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 என்பது நீங்கள் சரிபார்க்கப்படாத கையொப்பமிடப்பட்ட தொகுப்புகளை நிறுவப் போகிறீர்கள் என்று அர்த்தம்.

Support contract இல்லாத server-க்கு ஏற்ற, 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

இதன் இணைய இடைமுகம் (web interface) HTTPS port 8007-ல் பதிலளிக்கும். கணினியின் root கடவுச்சொல்லைப் பயன்படுத்தி root@pam ஆக உள்நுழையவும், ஏனெனில் PBS அந்தப் பயனரை PAM (pluggable authentication modules) மூலம் அங்கீகரிக்கிறது; இது இயங்குதளம் பயன்படுத்தும் அதே கணக்குகளாகும். இந்தச் சான்றிதழ் (certificate) சுய-கையொப்பமிடப்பட்டது (self-signed), எனவே உங்கள் உலாவி எச்சரிக்கை செய்யும். அந்தச் சான்றிதழின் fingerprint-ஐத்தான் Proxmox VE பின்னர் pin செய்யும், எனவே இந்த எச்சரிக்கை எதிர்பார்க்கப்படுவதுதான், இது சரிசெய்ய வேண்டிய பிழை அல்ல.

Port 8007 பொது இணையத்தில் ஒரு உள்நுழைவுப் படிவமாகும், எனவே இதை அனைவருக்கும் திறந்து வைக்க வேண்டாம். ஒரு nftables கோப்பு இதை நிர்வகிக்கும். /etc/nftables.conf-ஐ எழுதுவது தற்போதைய விதிகளை அழித்துவிடும் (flushes), எனவே இந்த இயந்திரத்தில் வேறேதேனும் firewall ஏற்கனவே இருந்தால் இதைத் தவிர்க்கவும்.

#!/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 session-ஐத் திறந்து வைத்திருக்கவும்: policy drop மற்றும் SSH விதியில் ஒரு தட்டச்சுப் பிழை (typo) ஏற்பட்டால், உங்கள் சொந்த server-லிருந்து நீங்கள் வெளியேற்றப்படுவீர்கள். 203.0.113.7-க்கு பதிலாக உங்கள் cluster-ன் முகவரியை இடவும். அந்த முகவரி dynamic ஆக இருந்தால், விதியை உங்கள் provider-ன் range-க்கு விரிவுபடுத்தவும் அல்லது tunnel மூலம் இணைப்பை முடிக்கவும். பெரும்பாலான VPS பேனல்களில் இயந்திரத்திற்கு முன்னால் ஒரு தனி network firewall இருக்கும், அதுவும் அதே port-ஐ அனுமதிக்க வேண்டும் என்பதை நினைவில் கொள்க.

Datastore-ஐ தனி volume-ல் வைக்கவும்

Datastore-ஐ root filesystem-ல் வைத்திருக்கக்கூடாது. ஒரு datastore பகிரப்பட்ட root filesystem-ஐ நிரப்பினால், backup தோல்வியடையும்; அதேபோல், ஏன் தோல்வியடைந்தது என்பதைக் கண்டறியத் தேவையான logging உட்பட server-ல் உள்ள மற்ற அனைத்தும் செயலிழக்கும். Block volume-ஐ இணைத்து, 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 point இல்லை என்றாலும் நீங்கள் 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

இது 0000 முதல் ffff வரை பெயரிடப்பட்ட 65536 subdirectories-ஐக் கொண்ட ஒரு .chunks directory-ஐ உருவாக்குகிறது. Datastore என்பது சில பெரிய கோப்புகள் அல்ல, மாறாக லட்சக்கணக்கான சிறிய கோப்புகள் ஆகும். இதிலிருந்து இரண்டு விஷயங்கள் தெளிவாகின்றன. சாதாரண file-level கருவியைப் பயன்படுத்தி datastore-ஐ நகலெடுப்பது மிகவும் மெதுவாக இருக்கும், எனவே அது பயனற்றது. மேலும், backups இயங்கிக்கொண்டிருக்கும்போது எடுக்கப்படும் provider volume snapshot, datastore-ன் சீரான நகலாக இருக்காது. இதனால்தான் snapshots backups-க்கு மாற்றாகாது என்பது எல்லா இடங்களிலும் பொருந்தும்.

Namespaces இரண்டு hosts ஒன்றோடொன்று மோதிக்கொள்வதைத் தடுக்கின்றன

ஒரு datastore இயல்பாகவே தட்டையான (flat) அமைப்பைக் கொண்டது. Backups vm/100, ct/101 மற்றும் host/<name> எனப் பெயரிடப்படுகின்றன. ID 100 கொண்ட guest-ஐக் கொண்ட இரண்டு clusters ஒரே குழுவில் எழுதினால், அவற்றின் snapshots ஒன்றோடொன்று கலந்துவிடும். ஒரு cluster-க்காக எழுதப்பட்ட 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-ன் ஒரு நகலை மட்டுமே சேமிக்கும். இதுவே ஒவ்வொரு host-க்கும் தனி datastore-க்கு பதிலாக, namespaces கொண்ட ஒரே datastore-ஐப் பயன்படுத்துவதற்கான காரணம்: தனித்தனி datastores என்பது தனித்தனி chunk pools-ஐக் குறிக்கும், தனித்தனி chunk pools என்பது ஒரே Debian install-க்கு பலமுறை சேமிப்பகச் செலவைச் செய்வதைக் குறிக்கும்.

ஒவ்வொரு source-க்கும் அதன் சொந்த namespace-க்குள் வரையறுக்கப்பட்ட தனி account-ஐ வழங்கவும். ஒரு API (application programming interface) token என்பது ஒரு பயனருக்குச் சொந்தமான மற்றும் அதன் சொந்த அனுமதிகளைக் கொண்ட ஒரு credential ஆகும்; திருடப்படக்கூடிய ஒரு 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-ஐ ஒரே ஒருமுறை மட்டுமே அச்சிடும்:

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

இப்போதே அதை நகலெடுக்கவும், ஏனெனில் PBS அதை மீண்டும் உங்களுக்குக் காட்ட முடியாது. Access control command-ஐ இருமுறை கவனிக்கவும். இது பயனருக்குப் பதிலாக backup@pbs!pve-home என்ற token-ஐக் குறிப்பிடுகிறது, ஏனெனில் token அனுமதிகள் அந்த token-ஐக் குறிப்பிடும் entries-லிருந்து மட்டுமே கணக்கிடப்படுகின்றன. backup@pbs-க்கான entry மட்டும் இருந்தால், அந்த token-க்கு எந்த அனுமதியும் இருக்காது, மேலும் முதல் backup network-ல் தெரியும் எதையும் விட, அனுமதிகள் (permissions) காரணமாகவே தோல்வியடையும். Path-ம் மிக முக்கியமானது: /datastore/store1/pve-home-க்கு வரையறுக்கப்பட்ட ஒரு token-ஆல் office namespace-ல் எதையும் படிக்கவோ அல்லது நீக்கவோ முடியாது, எனவே ஒரு compromised cluster மற்றொரு தளத்தின் வரலாற்றை அழிக்க முடியாது.

Proxmox VE-ல் VPS-ஐ backup storage-ஆக சேர்த்தல்

முதலில் PBS host-ல் உள்ள certificate fingerprint-ஐப் படிக்கவும்.

sudo proxmox-backup-manager cert info | grep Fingerprint

பின்பு, cluster-ன் ஏதேனும் ஒரு node-ல்:

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

மூன்றாவது வரியில் உள்ள placeholder-க்கு பதிலாக, cert info-ல் அச்சிடப்பட்ட மதிப்பை உள்ளிடவும். --password-ஐ மதிப்பு ஏதுமின்றி அனுப்பினால், pvesm அதை உள்ளிடுமாறு கேட்கும்; இதனால் token secret உங்கள் shell history-ல் சேமிக்கப்படாது. இது /etc/pve/priv/storage/pbs-offsite.pw-ல் சேமிக்கப்படுகிறது, மேலும் storage definition /etc/pve/storage.cfg-க்குச் செல்கிறது. இது cluster-ல் உள்ள அனைத்து node-களுக்கும் நகலெடுக்கப்படுவதால், முழு cluster-க்கும் இதை ஒருமுறை மட்டும் கட்டமைத்தால் போதும்.

--prune-backups keep-all=1 என்பது எதையும் நீக்க வேண்டாம் என்று Proxmox VE-க்குக் கட்டளையிடுகிறது. Retention கொள்கைகள் PBS பக்கமே இருக்க வேண்டும், இது கீழே விளக்கப்பட்டுள்ளது. இதற்கான காரணம் தெளிவானது: அப்போதுதான் நீக்குவதற்கான அனுமதி (permission) அந்த token-க்குத் தேவையில்லை. எனவே, ransomware தாக்குதலால் ஒரு cluster பாதிக்கப்பட்டாலும், அது தனது பாதுகாப்பிற்காக வைக்கப்பட்டிருக்கும் offsite history-ஐ அழிக்க முடியாது.

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

pvesm status கட்டளையானது status column-ல் active என்பதைக் காட்டும், அதனுடன் datastore-ன் மொத்த மற்றும் பயன்படுத்தப்பட்ட இடத்தின் அளவு இருக்கும். inactive என்பது, அந்த node-ஆல் port 8007-க்கு TLS (transport layer security) session-ஐ முடிக்க முடியவில்லை என்று பொருள். இது credential தொடர்பான சிக்கல் அல்ல, மாறாக firewall அல்லது fingerprint தொடர்பான சிக்கலாகும்.

முதல் backup அனைத்து தரவுகளையும் பதிவேற்றும், எனவே அதைத் தொடங்கும் முன் கணக்கீடுகளைச் சரிபார்க்கவும். 200 GB என்பது 1600 gigabits ஆகும். 100 Mbit uplink வினாடிக்கு 0.1 gigabit வேகத்தில் தரவை நகர்த்தும். எனவே, குறைந்தபட்சம் நான்கு அரை மணி நேரம் ஆகும், நடைமுறையில் இதைவிடக் கூடுதல் நேரம் எடுக்கலாம். உங்களுக்கு bandwidth தேவைப்படாத நேரத்தில் இதைத் தொடங்கவும். அதன் பிறகு நடக்கும் ஒவ்வொரு backup-ம் புதிய chunks-ஐ மட்டுமே அனுப்பும்.

Client-side encryption மற்றும் அதன் key இருக்கும் இடம்

VPS என்பது உங்களுக்குச் சொந்தமில்லாத ஒரு கணினி. Client-லேயே தரவை encrypt செய்யுங்கள்; அப்போதுதான், service provider-ஆல் படிக்க முடியாத தரவுத் துண்டுகளை (chunks) மட்டும் datastore வைத்திருக்கும்.

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

இது /etc/pve/priv/storage/pbs-offsite.enc-ல் ஒரு புதிய key-ஐ எழுதும். இதை root பயனர் மட்டுமே படிக்க முடியும், மேலும் இது /etc/pve-ன் மற்ற பகுதிகளுடன் சேர்த்து நகலெடுக்கப்படும். அடுத்த backup-லிருந்து, ஒவ்வொரு தரவுத் துண்டையும் client encrypt செய்த பிறகே அனுப்பும். server-ஆல் உங்கள் snapshots மற்றும் அவற்றின் அளவுகளைப் பட்டியலிட முடியுமே தவிர, அவற்றின் உள்ளடக்கத்தைப் படிக்க முடியாது.

இப்போது, இதை ஒரு backup-ஆக மாற்றும் முக்கியமான பகுதிக்கு வருவோம். உருவாக்கப்பட்ட key-க்கு passphrase கிடையாது, அது எந்த cluster-ஐப் பாதுகாக்கிறதோ அந்த cluster-ல் மட்டுமே இருக்கும். ஒருவேளை அந்த cluster திருடப்பட்டாலோ அல்லது யாராவது encrypt செய்தாலோ, VPS-ல் உள்ள தரவை யாராலும் திறக்க முடியாது. எனவே, key-ஐ உருவாக்கிய அன்றே அதை cluster-லிருந்து வெளியே நகலெடுத்து வையுங்கள்.

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-ஐ ஒரு ஆவணமாக அச்சிடும்; அதை காகிதத்தில் அச்சிட்டு பாதுகாப்பான இடத்தில் வைக்க வேண்டும். அந்த file-ஐ ஒரு ரகசியமாகவே கருதுங்கள், ஏனெனில் அதை வைத்திருப்பவர் அந்த key மூலம் உருவாக்கப்பட்ட அனைத்து backup-களையும் decrypt செய்ய முடியும். பெரிய அளவிலான அமைப்புகளுக்கு, PBS ஒரு master key-ஐயும் ஆதரிக்கிறது. இது proxmox-backup-client key create-master-key மூலம் உருவாக்கப்பட்ட ஒரு RSA (Rivest Shamir Adleman) key pair ஆகும். இதில், ஒவ்வொரு backup-ம் தனது சொந்த encryption key-ஐ public key மூலம் encrypt செய்து சேமிக்கும், அதே சமயம் private key மீட்புக்காக (recovery) offline-ல் பாதுகாப்பாக வைக்கப்படும்.

இந்த வடிவமைப்பின் ஒரு விளைவை, தொடங்குவதற்கு முன்பே தெரிந்துகொள்வது நல்லது. Encrypted backup-களுக்கு, plain text உள்ளடக்கத்தையும் encryption key-யையும் இணைத்தே chunk digest கணக்கிடப்படுகிறது. எனவே, வெவ்வேறு key-களால் encrypt செய்யப்பட்ட ஒரே மாதிரியான இரண்டு chunks வெவ்வேறு digest-களை உருவாக்கும், அவை ஒன்றோடொன்று deduplicate ஆகாது. Key-ஐ மாற்றினால், அடுத்த backup-ல் அனைத்து தரவுகளும் மீண்டும் upload செய்யப்படும்; பழைய chunks, அவற்றின் snapshots நீக்கப்பட்டு (pruned) சேகரிக்கப்படும் வரை அங்கேயே இருக்கும். எனவே, முதல் upload-க்கு முன்பே encryption குறித்து முடிவெடுங்கள்.

Prune marks, garbage collection reclaims

இந்த பகுதிதான் பெரும்பாலும் தவிர்க்கப்படுகிறது, இதுவே volume-ஐ நிரப்புகிறது. ஒரு snapshot-ஐ prune செய்வது அதன் metadata-வை மட்டுமே நீக்கும்: manifest, indexes, log மற்றும் notes. இது எந்த chunk-களையும் நீக்காது. Chunk-கள் பல snapshot-களுக்கு இடையே பகிரப்படுவதால், அனைத்து index-களும் வாசிக்கப்படும் வரை ஒரு chunk பயன்படுத்தப்படாதது என்று எதற்கும் தெரியாது; அந்த வேலையைச் செய்வதுதான் garbage collection. Prune schedule மட்டும் இருந்து, garbage collection schedule இல்லாத datastore எப்போதும் வளர்ந்து கொண்டே இருக்கும்.

இரண்டையும் அமைக்கவும். முதலில் retention, ஒரு namespace-க்கு ஒரு job:

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 schedule-ஐ அமைக்கவும். இது prune job-க்கு சில மணிநேரங்கள் கழித்தும், backup window-க்கு வெளியேயும் இருக்க வேண்டும்:

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

PBS host-ல் இந்த பிரிவினையை நீங்களே ஒருமுறை உறுதிப்படுத்திக் கொள்ளுங்கள்:

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

Prune job-ஐ இயக்கவும், பிறகு df-ஐப் பார்க்கவும், பயன்படுத்தப்பட்ட அளவு மாறாது. Garbage collection-ஐ இயக்கவும், பிறகு மீண்டும் df-ஐப் பார்க்கவும், இப்போது அளவு மாறும்.

Garbage collection இரண்டு கட்டங்களாக நடக்கும். முதல் கட்டம் datastore-ல் உள்ள ஒவ்வொரு index-ஐயும் சரிபார்த்து, அந்த index-கள் குறிப்பிடும் ஒவ்வொரு chunk-ன் access time-ஐயும் புதுப்பிக்கும். இரண்டாம் கட்டம், cutoff காலத்திற்கு முந்தைய chunk-களை நீக்கும். இந்த cutoff என்பது, run தொடங்கிய நேரத்திற்கு 24 மணிநேரம் 5 நிமிடங்களுக்கு முன்பு, அல்லது இன்னும் எழுதப்பட்டுக்கொண்டிருக்கும் பழைய backup-ன் தொடக்க நேரம் - இதில் எது முந்தையதோ அதுவாகும். இந்த கால இடைவெளி இருப்பதற்குக் காரணம், Linux இயல்பாகவே கோப்பு முறைமைகளை relatime மூலம் mount செய்வதாகும்; இது ஒவ்வொரு வாசிப்பிற்கும் பதிலாக, ஒரு நாளைக்கு ஒருமுறை மட்டுமே access time-ஐப் புதுப்பிக்கும். எனவே, ஒரு மணி நேரத்திற்கு முன்பு எழுதப்பட்ட chunk, எவராலும் பயன்படுத்தப்படவில்லை என்றாலும் நீக்கப்படாது. ஒரு prune மூலம் விடுவிக்கப்பட்ட இடம், அந்த chunk கடைசியாகத் தொடப்பட்ட ஒரு நாளுக்குப் பிறகு நடக்கும் முதல் collection-ல் மட்டுமே தெரியும். எதையும் மீட்டெடுக்காதது போலத் தோன்றும் datastore, பெரும்பாலும் இந்த கால இடைவெளிக்குள் இருக்கிறது என்று அர்த்தம்.

சிறிய VPS-களில் இதுவே மிகக் கடினமான பணியாகும், ஏனெனில் இது volume-ல் உள்ள ஒவ்வொரு chunk கோப்பையும் சரிபார்க்கும் (stats). Task log-ன் இறுதியில், என்ன நீக்கப்பட்டது மற்றும் grace period காரணமாக எது இன்னும் நிலுவையில் உள்ளது என்பதற்கான சுருக்கம் இருக்கும். அதிகப்படியானவை நிலுவையில் இருந்தால், அடுத்த நாள் மீண்டும் இயக்கவும். PBS ஆனது gc-atime-safety-check மற்றும் gc-atime-cutoff ஆகியவற்றை datastore tuning விருப்பங்களாக வழங்குகிறது, இவற்றை மாற்றாமல் அப்படியே விடுவது நல்லது: இவை access time-ஐப் பதிவு செய்ய முடியாத storage-களுக்காக உள்ளன. noatime மூலம் mount செய்யப்பட்ட கோப்பு முறைமையில் இந்த பாதுகாப்புச் சோதனையை (safety check) முடக்குவது, நேரடி snapshot-கள் பயன்படுத்தும் chunk-களை இழக்க வழிவகுக்கும்.

துண்டுகள் (chunks) இன்னும் வாசிக்கக்கூடிய நிலையில் இருப்பதை சரிபார்த்தல்

சரியாக பதிவேற்றப்பட்ட ஒரு backup, ஒரு வருடம் கழித்து வாசிக்க முடியாத நிலையில் இருக்கலாம். Verification என்பது துண்டுகளை மீண்டும் வாசித்து, index-ல் சேமிக்கப்பட்டுள்ள checksum-களுடன் ஒப்பிடும் செயல்முறையாகும். இதனால், restore செய்யும் போது சிக்கலை கண்டறிவதற்கு பதிலாக, முன்கூட்டியே திட்டமிட்டபடி சேதங்கள் கண்டறியப்படுகின்றன.

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

சிறிய VPS-களில் thread எண்ணிக்கையை குறைவாக வைத்திருக்கவும். Verification செயல்முறை disk மற்றும் CPU-வை அதிகம் பயன்படுத்தும் என்பதால், அது server-ல் இயங்கும் பிற பணிகளுடன் போட்டியிடும். ஒரு கால அட்டவணையை உருவாக்க, web interface-ல் உள்ள datastore-ன் Verify Jobs tab-ஐப் பயன்படுத்தவும்: வாராந்திர job ஒன்றை அமைத்து, ஏற்கனவே சரிபார்க்கப்பட்ட snapshots-ஐத் தவிர்த்து, 30 நாட்களுக்கு மேல் பழமையானவற்றை மீண்டும் சரிபார்க்கலாம். இது வேலையை மீண்டும் மீண்டும் செய்யாமல், காலப்போக்கில் முழு datastore-ஐயும் சரிபார்க்க உதவும்.

Verification தோல்வியடையும் ஒரு snapshot, datastore பார்வையில் failed எனக் குறிக்கப்படும். இதை அலட்சியப்படுத்த வேண்டாம். துண்டுகள் பகிரப்படுவதால், ஒரு base image-ல் உள்ள ஒரு சேதமடைந்த துண்டு, அதைக் குறிப்பிடும் அனைத்து snapshots-களையும் தோல்வியடையச் செய்யும். தோல்வியடைந்த snapshots-ஐ நீக்கிவிட்டு (forget), புதிய backup-ஐ எடுப்பதே இதற்கான தீர்வாகும்; இது விடுபட்ட துண்டுகளை மீண்டும் பதிவேற்றும். தொடர்ந்து தோல்விகள் ஏற்பட்டால், datastore-க்கு அடியில் உள்ள storage-ஐச் சந்தேகிக்கவும். எனவே, VPS-ல் disk health monitoring அமைப்பை ஏற்படுத்தவும், இதன் மூலம் verify job கண்டறிவதற்கு முன்பே drive உங்களுக்கு எச்சரிக்கை செய்யும்.

மீட்புச் சோதனையைச் செய்யவும், பின்னர் cluster இல்லாமல் அதைச் சோதிக்கவும்

நீங்கள் ஒரு backup-ஐ மீட்டெடுக்கும் வரை, அது சரியாக வேலை செய்கிறதா என்பது உங்களுக்குத் தெரியாது. இரண்டு சோதனைகள் உள்ளன, அவை வெவ்வேறு விஷயங்களைச் சரிபார்க்கின்றன.

முழு விருந்தினர் (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-ம் அடங்கும், எனவே உதாரணத்தைத் தட்டச்சு செய்வதற்குப் பதிலாக உங்களுடையதை நகலெடுக்கவும். பயன்படுத்தப்படாத ஒரு guest ID-ல் மற்றும் வேறொரு storage-ல் மீட்டெடுக்கவும், பின்னர் அதன் network interface-ஐத் துண்டித்துவிட்டு அதைத் தொடங்கவும். இயங்கிக்கொண்டிருக்கும் ஒரு guest-ன் மீது ஒருபோதும் மீட்டெடுக்க வேண்டாம், ஏனெனில் பாதியில் தோல்வியடையும் ஒரு மீட்பு, ஏற்கனவே வேலை செய்யும் நகலையும் அழித்துவிடும்.

இரண்டாவது சோதனை யாரும் செய்யாத ஒன்று. cluster இருக்கும் கட்டிடம் அழிந்துவிட்டதாகக் கருதி, அதன் ஒரு பகுதியாக இல்லாத ஒரு machine-லிருந்து மீட்டெடுக்கவும். ஏதேனும் ஒரு Debian 13 கணினியில், 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

மேற்கோள் காட்டப்பட்ட மூன்று placeholders-ல் உங்கள் சொந்த மதிப்புகளை நிரப்பவும், கடைசி வரியில் உள்ள archive பெயரை snapshot files வெளியிட்டதிலிருந்து எடுக்கவும். முதல் சோதனையால் நிரூபிக்க முடியாததை இது நிரூபிக்கிறது: உங்கள் key file-ன் நகல் உண்மையான தரவை decrypt செய்கிறது என்பதையும், உங்கள் cluster-ன் configuration-ஐ ஒருபோதும் கொண்டிராத ஒரு machine-லிருந்து client-ஐ இயக்க முடியும் என்பதையும் இது உறுதிப்படுத்துகிறது. அதற்குத் தேவையான நான்கு மதிப்புகளை, அதாவது repository string, token secret, fingerprint மற்றும் key file ஆகியவற்றை எழுதி வைத்துக்கொள்ளுங்கள், மேலும் அவற்றை உங்கள் பேரிடர் மீட்புத் திட்டத்தில் (disaster plan) குறிப்பிட்டுள்ள இடத்தில் பாதுகாப்பாக வைக்கவும்.

Deduplication உங்கள் disk கட்டணத்தில் என்ன செய்கிறது, என்ன செய்யாது

Deduplication என்பது உண்மையானது, இது முழு datastore-க்கும் பொருந்தும். பத்து Debian guests-கள் அவற்றின் base system-ன் ஒரு நகலைப் பகிர்ந்து கொள்கின்றன, எனவே இரண்டாவது ஒரே மாதிரியான guest-ஐச் சேமிக்க கிட்டத்தட்ட செலவே இல்லை. இது upload bandwidth-ஐயும் மிச்சப்படுத்துகிறது, ஏனெனில் server-ல் ஏற்கனவே உள்ள எந்தவொரு chunk-க்கும் client தரவுக்குப் பதிலாக checksum-ஐ மட்டுமே அனுப்புகிறது.

இது எதைச் செய்யாது என்பதைத் தெளிவாகப் புரிந்துகொள்வது அவசியம்.

• இது மாறும் தரவைச் சுருக்காது. ஒவ்வொரு இரவும் தனது கோப்புகளின் பெரும் பகுதிகளை மீண்டும் எழுதும் database, ஒவ்வொரு இரவும் புதிய chunks-களை உருவாக்குகிறது, மேலும் retention அவற்றை பலமடங்காக அதிகரிக்கிறது.
• இது மேலே குறிப்பிட்டது போல, encryption key எல்லைகளைத் தாண்டிச் செயல்படாது.
• இது datastore எல்லைகளைத் தாண்டிச் செயல்படாது, இதுவே namespaces-க்கான முழுமையான வாதமாகும்.
• இது volume நிரம்புவதைத் தடுக்காது. Datastore நிரம்பிவிட்டால், backups தோல்வியடையும், இதற்குப் பெரிய volume அல்லது குறைந்த retention காலமே தீர்வாகும்.

இதற்கு அடியில் மற்றொரு deduplication அடுக்கைச் சேர்க்க வேண்டாம். Chunks ஏற்கனவே client-ஆல் deduplicate செய்யப்பட்டு compress செய்யப்பட்டு வருகின்றன, எனவே datastore-க்கு அடியில் ZFS deduplication-ஐப் பயன்படுத்துவது, ஏற்கனவே நீக்கப்பட்ட தரவுகளைத் தேடி RAM-ஐ வீணடிக்கும். இந்தச் சூழலுக்கு plain ext4 அல்லது xfs-ஐப் பயன்படுத்துவதே சரியான தேர்வாகும்.

Web interface, datastore-க்கான deduplication factor-ஐக் காட்டுகிறது. அந்த எண் உங்கள் guests-களை விவரிக்கிறது, திட்டமிடுவதற்கு அது மட்டுமே நம்பகமானது, ஏனெனில் வெளியிடப்பட்ட விகிதங்கள் மற்றவர்களின் தரவை அடிப்படையாகக் கொண்டவை. Proxmox guests அல்லாத பிற இயந்திரங்களின் file-level backups உங்களுக்குத் தேவைப்பட்டால், அவற்றை அதே VPS-ல் பக்கவாட்டில் இயக்கவும்: PBS என்பது முழு guests-களுக்கான hypervisor-aware இலக்காகும், அதே சமயம் restic மற்றும் BorgBackup கோப்பகங்களை (directories) குறிவைக்கின்றன, மேலும் restic backups to a VPS, PBS-ன் நோக்கத்திற்கு அப்பாற்பட்ட laptops மற்றும் standalone servers-க்கு ஏற்றதாக இருக்கும்.

தோல்வி முறைகளும் நீங்கள் காண்பவை

சேமிப்பகம் (storage) inactive எனக் காட்டுகிறது. pvesm status --storage pbs-offsite, போர்ட் 8007-க்கு TLS அமர்வை (session) முடிக்க முடியாதபோது inactive-ஐ அச்சிடும். VPS-ல் உள்ள firewall-ஐயும், அதைத் தொடர்ந்து வழங்குநரின் தனிப்பட்ட network firewall-ஐயும், பின்னர் fingerprint-ஐயும் சரிபார்க்கவும். சான்றிதழுடன் (certificate) பொருந்தாத fingerprint, தடுக்கப்பட்ட போர்ட் போலவே அதே பிழையைக் காட்டும்; சான்றிதழ் மாற்றப்படும்போதெல்லாம் இதுவும் மாறும்.

முதல் backup அனுமதிகள் (permissions) காரணமாகத் தோல்வியடைகிறது. அணுகல் கட்டுப்பாட்டு உள்ளீடு (access control entry) பயனருக்குப் பதிலாக token-ஐக் குறிப்பிட வேண்டும், மேலும் அது சேமிப்பகம் சுட்டிக்காட்டும் namespace-ஐ உள்ளடக்கியிருக்க வேண்டும். வேறு எங்கும் பார்ப்பதற்கு முன், web interface-ல் உள்ள datastore-ன் permissions tab-ல் இரண்டையும் உறுதிப்படுத்தவும்.

Garbage collection தொடங்க மறுக்கிறது. அணுகல் நேர பாதுகாப்புச் சரிபார்ப்பு (access time safety check) தோல்வியடைந்தது; இதற்கு datastore filesystem noatime என mount செய்யப்பட்டிருப்பதே பெரும்பாலும் காரணமாக இருக்கும். இதை உறுதிப்படுத்த findmnt -no OPTIONS /mnt/datastore/store1-ஐ இயக்கவும், /etc/fstab-ல் உள்ள விருப்பத்தைச் சரிசெய்து, மீண்டும் mount செய்யவும். இதைத் தவிர்க்கச் சரிபார்ப்பை முடக்க வேண்டாம்.

Datastore அளவு மட்டும் அதிகரிக்கிறது. Prune பணிகள் இயங்குகின்றன, ஆனால் எதுவும் மீட்கப்படவில்லை. Garbage collection கால அட்டவணை (schedule) இல்லாமலோ அல்லது ஒவ்வொரு சேகரிப்பும் backup முடிந்த உடனேயே நடப்பதால் 24 மணிநேர அவகாச காலத்திற்குள் (grace window) விழுவதாலோ இது நிகழலாம். proxmox-backup-manager datastore show store1 மூலம் கால அட்டவணையைச் சரிபார்க்கவும்.

முன்பு விரைவாக நடந்த backup இப்போது பல மணிநேரம் எடுக்கிறது. நிறுத்தப்பட்ட, இடம்பெயர்ந்த (migrated) அல்லது மீட்டெடுக்கப்பட்ட (restored) guest அதன் dirty bitmap-ஐ இழக்கிறது. எனவே, அடுத்த முறை இயங்கும்போது மிகக் குறைந்த அளவே upload செய்தாலும், cluster பக்கத்தில் முழு வட்டும் (disk) வாசிக்கப்படுகிறது. பணிப் பதிவேடு (task log) நீண்ட கால அளவையும் சிறிய upload அளவையும் காட்டும், அடுத்தடுத்த இயக்கம் மீண்டும் விரைவாக இருக்கும். VPS-ல் உள்ள அனைத்துப் பணிகளும் மெதுவாக இருந்தால், அதற்கு datastore-க்கு வெளியே ஏதோ ஒன்று காரணமாக இருக்கும்; 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 நீக்கும் வரை அவை disk-லேயே இருக்கும். 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-க்கு எவ்வளவு disk தேவைப்படும்?

ஒவ்வொரு guest-உம் உண்மையில் பயன்படுத்தும் இடத்தைக் கணக்கிடுங்கள், அதனுடன் ஒவ்வொரு guest-ன் தினசரி மாற்றத்தையும் நீங்கள் தரவுகளைச் சேமித்து வைக்கும் நாட்களின் எண்ணிக்கையையும் பெருக்கிச் சேர்க்கவும். compression மற்றும் deduplication ஆகிய இரண்டும் உங்களுக்குச் சாதகமாகச் செயல்படுவதால், அந்த மொத்த அளவு ஒரு உச்சவரம்பாகவே இருக்கும். indexes மற்றும் செயல்பாட்டு இடத்திற்காக சுமார் ஐந்தில் ஒரு பங்கு கூடுதலாகச் சேர்க்கவும், பின்னர் நீங்கள் வாங்கக்கூடிய volume அளவிற்கு அதைத் திருத்தவும். முதல் backup-க்கு முன் செய்யப்படும் கணிப்பு எப்போதும் ஏதோ ஒரு திசையில் தவறாகவே இருக்கும் என்பதால், இரண்டு வாரங்களுக்குப் பிறகு datastore view-ல் உள்ள உண்மையான பயன்பாட்டுடன் ஒப்பிட்டு மீண்டும் சரிபார்க்கவும்.

Backup encryption key-ஐ எங்கே சேமிக்க வேண்டும்?

அது பாதுகாக்கும் cluster-ல் மட்டும் சேமிக்க வேண்டாம். Proxmox VE அதை /etc/pve/priv/storage/<storage>.enc-ல் வைத்திருக்கிறது, இது ஒவ்வொரு node-க்கும் நகலெடுக்கப்படுவதால் cluster-உடன் சேர்ந்து அதுவும் இழக்கப்படும். முதல் நாளிலேயே அதை வெளியே நகலெடுக்கவும், proxmox-backup-client key paperkey மூலம் அதை அச்சிடவும், அந்த நகலை வேறொரு கட்டிடத்தில் பாதுகாப்பாக வைக்கவும். இந்த key chunk digest-ன் ஒரு பகுதியாகச் செயல்படுகிறது என்பதையும் கவனத்தில் கொள்க; எனவே, பிற்காலத்தில் அதை மாற்றினால், அடுத்த backup-ன் போது அனைத்தும் மீண்டும் upload செய்யப்படும்.

ஒவ்வொரு Proxmox host-க்கும் ஒரு datastore தேவையா அல்லது namespaces போதுமா?

ஒவ்வொரு source host அல்லது cluster-க்கும் ஒரு datastore மற்றும் ஒரு namespace போதுமானது. Deduplication என்பது datastore-களுக்கு இடையே செயல்படாது, ஒரு datastore-க்குள் மட்டுமே செயல்படும். எனவே, host வாரியாகப் பிரிப்பது ஒரே மாதிரியான base images-களைப் பலமுறை சேமிக்க வழிவகுக்கும். Namespaces backup groups-களைத் தனித்தனியாக வைத்திருக்கின்றன, இதனால் ID 100 கொண்ட guest-ஐக் கொண்ட இரண்டு host-கள் ஒன்றோடொன்று மோதிக்கொள்ளாது. மேலும், /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-களின் எண்ணிக்கையைக் குறைவாக வைத்திருக்கவும். இரண்டு பணிகளையும் backup window-க்கு வெளியே திட்டமிடுங்கள். ஒருவேளை அவை disk-ன் வேகத்திற்குத் தேவையான நேரத்தை விட மிக நீண்ட நேரம் எடுத்துக்கொண்டால், பெரிய plan-ஐ வாங்குவதற்கு முன் steal time-ஐ அளவிடவும்.