VPS-এ Proxmox Backup Server সেটআপ করার নিয়ম

VPS-এ Proxmox Backup Server ব্যবহারের সুবিধা

VPS-এ Proxmox Backup Server (PBS) ব্যবহার করলে আপনি একটি অফসাইট ব্যাকআপ টার্গেট পান, যা আপনার Proxmox VE (virtual environment) ক্লাস্টারের সাথে সরাসরি কাজ করে। ফলে প্রথম ব্যাকআপের পর প্রতিটি ব্যাকআপ ইনক্রিমেন্টাল হয়, বিভিন্ন গেস্টের মধ্যে ডেটা ডিডুপ্লিকেট করা থাকে, আপনার নেটওয়ার্ক ছাড়ার আগেই এনক্রিপ্ট হয় এবং পরবর্তীতে তা যাচাইযোগ্য থাকে। আপনি একটি ব্লক ভলিউমসহ VPS ভাড়া নিয়ে তাতে Debian 13-এর ওপর PBS ইনস্টল করবেন, সেই ভলিউমে একটি ডেটাস্টোর তৈরি করবেন এবং Proxmox VE-তে pbs টাইপের স্টোরেজ হিসেবে তা যুক্ত করবেন। ইনস্টলেশন সম্পন্ন করতে দশ মিনিট সময় লাগে। এর পরবর্তী সবকিছু, যেমন—নেমস্পেস, গার্বেজ কালেকশন, কি কাস্টডি এবং আপনার নিজের হাতে করা রিস্টোর টেস্ট—ই নির্ধারণ করবে যে এক বছর পর আপনার এই ব্যাকআপ কোনো কাজে আসবে কি না।

ভাড়া করা ডিস্কে সরাসরি vzdump ফাইল কপি না করে PBS ব্যবহারের মূল কারণ হলো এর চাঙ্ক স্টোর। ক্লায়েন্ট প্রতিটি গেস্ট ডিস্ককে প্রায় 4 MiB-এর ছোট ছোট চাঙ্কে বিভক্ত করে, সেগুলোর হ্যাশ তৈরি করে এবং শুধুমাত্র সেই চাঙ্কগুলোই আপলোড করে যা ডেটাস্টোরে আগে থেকে নেই। চলমান ভার্চুয়াল মেশিনের ক্ষেত্রে, প্রথম ব্যাকআপের পর QEMU একটি ডার্টি বিটম্যাপে পরিবর্তিত ব্লকগুলো ট্র্যাক করে, ফলে পরবর্তী ব্যাকআপে শুধুমাত্র সেই ব্লকগুলোই লোকাল ডিস্ক থেকে পড়া হয়। একটি 200 GB-এর গেস্ট মেশিন, যাতে প্রতিদিন 3 GB ডেটা পরিবর্তিত হয়, তা প্রতিদিন মাত্র 3 GB ডেটাই পাঠাবে। এই কার্যপদ্ধতির কারণেই একটি হোম আপলিংক এবং ভাড়া করা ভলিউম একসাথে কার্যকরভাবে কাজ করতে পারে। আর ঠিক এই কারণেই অফসাইট ব্যাকআপ টার্গেট হিসেবে VPS বন্ধুর বাড়িতে রাখা অতিরিক্ত ড্রাইভের চেয়ে বেশি কার্যকর। আপনি যদি এখনো সিদ্ধান্ত না নিয়ে থাকেন যে হাইপারভাইজারটি কোথায় রাখা উচিত, তবে বাড়িতে Proxmox বনাম ভাড়া করা VPS বিষয়টি আলাদাভাবে সেই প্রশ্নের উত্তর দেয়।

ভাড়া নেওয়ার আগে ভলিউমের আকার নির্ধারণ করুন

আকার নির্ধারণ হলো আপনার নিজস্ব ডেটার ওপর করা একটি গাণিতিক হিসাব। প্রতিটি গেস্ট প্রকৃতপক্ষে যে পরিমাণ জায়গা ব্যবহার করে তা নিন, ভার্চুয়াল ডিস্কের আকার নয়। এরপর প্রতিদিন যে পরিমাণ পরিবর্তন হয়, তার সাথে আপনি কত দিনের ডেটা সংরক্ষণ করবেন তা গুণ করুন। কমপ্রেশন এবং ডিডুপ্লিকেশন উভয়ই এই হিসাবকে উন্নত করে, তাই প্রাপ্ত ফলাফলকে সর্বোচ্চ সীমা হিসেবে ধরুন, লক্ষ্যমাত্রা হিসেবে নয়।

[
  {
    "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। ইনডেক্স, মেটাডেটা এবং গারবেজ কালেকশনের জন্য প্রয়োজনীয় বাড়তি জায়গার কথা মাথায় রেখে এর সাথে আরও এক-পঞ্চমাংশ যোগ করুন, যা নির্দেশ করে যে আপনার একটি 1 TB ভলিউম প্রয়োজন।

পরিকল্পনার বাকি অংশটি ছোট। PBS-এর জন্য 2 GB RAM যথেষ্ট এবং 4 GB RAM হলে এটি স্বাচ্ছন্দ্যে চলে, কারণ মূল কাজগুলো ক্লাস্টার সাইডে সম্পন্ন হয়: Proxmox VE নোড গেস্টের ডিস্কগুলো পড়ে এবং সেগুলোকে চাঙ্কিং ও হ্যাশিং করে। VPS-এর কাজ হলো চাঙ্কগুলো লেখা এবং দুটি ভারী কাজ—গারবেজ কালেকশন ও ভেরিফিকেশন—সম্পাদন করা। ডেটাস্টোরটিকে একটি বড় রুট ডিস্কের পরিবর্তে আলাদা ব্লক ভলিউম হিসেবে ভাড়া নিন, কারণ সার্ভার নতুন করে তৈরি না করেই আপনি পরবর্তীতে ভলিউমের আকার বাড়াতে পারবেন।

Debian 13-এ Proxmox Backup Server ইনস্টল করা

2026 সালের আগস্ট মাস অনুযায়ী, বর্তমান সংস্করণটি হলো Debian 13 (কোডনেম trixie)-এর ওপর ভিত্তি করে তৈরি Proxmox Backup Server 4। পুরনো নির্দেশিকাগুলোতে PBS 2-এর সাথে Debian 11-এর ব্যবহারের কথা বলা হয়েছে। যেহেতু রিপোজিটরি সংজ্ঞায় কোডনেমটি অন্তর্ভুক্ত থাকে, তাই পুরনো কোনো সুইট নাম কপি করলে আপনি একটি apt error পাবেন যেখানে 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

সাম (sum) অবশ্যই 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 port 8007-এ কাজ করে। root@pam হিসেবে সিস্টেমের root পাসওয়ার্ড দিয়ে লগ ইন করুন, কারণ PBS এই ব্যবহারকারীকে PAM (pluggable authentication modules)-এর মাধ্যমে যাচাই করে, যা অপারেটিং সিস্টেমের ব্যবহৃত একই অ্যাকাউন্ট। সার্টিফিকেটটি self-signed হওয়ায় আপনার ব্রাউজার সতর্কবার্তা দেখাবে। সেই সার্টিফিকেটের ফিঙ্গারপ্রিন্টটিই হলো সেই মান যা Proxmox VE পরবর্তীতে পিন (pin) করে, তাই এই সতর্কবার্তাটি প্রত্যাশিত এবং এটি কোনো সমস্যা নয়।

Port 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-কে আলাদা ভলিউমে রাখুন

Datastore-কে কখনোই root filesystem-এ রাখা উচিত নয়। যখন একটি Datastore শেয়ার করা root filesystem পূর্ণ করে ফেলে, তখন ব্যাকআপ ব্যর্থ হয় এবং সার্ভারের অন্যান্য সবকিছুও অচল হয়ে পড়ে, এমনকি সমস্যাটি খুঁজে বের করার জন্য প্রয়োজনীয় লগিংও তখন আর কাজ করে না। প্রথমে একটি block volume সংযুক্ত করুন, সেটিকে ফরম্যাট করুন, মাউন্ট করুন এবং তারপর মাউন্ট পয়েন্টের ভেতরে Datastore তৈরি করুন।

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

lsblk থেকে ডিভাইসের নাম নিন। বেশিরভাগ KVM ইমেজে এটি /dev/vdb এবং অন্যগুলোতে /dev/sdb হিসেবে থাকে, তাই অনুমান করা নিরাপদ নয়। /etc/fstab-এ লেবেল ব্যবহার করে মাউন্ট পয়েন্টটি যোগ করুন, যাতে রিবুটের পরে ডিভাইসের নাম পরিবর্তিত হলেও Datastore ভুল ডিস্কে পয়েন্ট না করে:

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 সহ অপশনগুলো প্রদর্শন করবে। এই একটি লাইনেই দুটি ব্যর্থতার সম্ভাবনা লুকিয়ে থাকে। যদি মাউন্ট পয়েন্টটি সেখানে না থাকে এবং আপনি তবুও Datastore তৈরি করেন, তবে PBS মাউন্ট পয়েন্টের নিচে root filesystem-এ ডেটা লিখতে শুরু করবে। পরবর্তীতে যখন মাউন্টটি সফল হবে, তখন সেটি আগের ডেটাগুলোকে আড়াল করে ফেলবে কিন্তু মুছে ফেলবে না: ফলে Datastore-কে খালি মনে হবে এবং root filesystem পূর্ণই থেকে যাবে। যদি অপশনগুলোতে noatime থাকে, তবে PBS কাজ করতে অস্বীকার করবে, কারণ Datastore তৈরির সময় এবং প্রতিবার গার্বেজ কালেকশনের সময় এটি access time-এর একটি নিরাপত্তা পরীক্ষা চালায়।

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

এটি একটি .chunks ডিরেক্টরি তৈরি করে যার ভেতরে 65536টি সাব-ডিরেক্টরি থাকে, যেগুলোর নাম 0000 থেকে ffff পর্যন্ত। একটি Datastore মানে হলো কয়েক লক্ষ ছোট ছোট ফাইল, কয়েকটি বড় ফাইল নয়। এর থেকে দুটি বিষয় বোঝা যায়। সাধারণ ফাইল-লেভেল টুল দিয়ে Datastore কপি করা এতটাই ধীর যে তা অকার্যকর, এবং ব্যাকআপ চলাকালীন নেওয়া প্রোভাইডার ভলিউম স্ন্যাপশট এর একটি সামঞ্জস্যপূর্ণ কপি নয়। ঠিক এই কারণেই স্ন্যাপশট ব্যাকআপের বিকল্প হতে পারে না।

Namespaces দুটি হোস্টের মধ্যে সংঘর্ষ রোধ করে

একটি datastore ডিফল্টভাবে ফ্ল্যাট বা সমতল থাকে। ব্যাকআপগুলোর নাম হয় vm/100, ct/101 এবং host/<name>। দুটি ক্লাস্টারের প্রতিটিতে যদি ID 100 বিশিষ্ট একটি guest থাকে এবং তারা একই গ্রুপে লেখে, তবে তাদের স্ন্যাপশটগুলো একে অপরের সাথে মিশে যায় এবং একটির জন্য লেখা retention rule অন্যটির স্ন্যাপশটকেও গণনা করে। Namespaces প্রতিটি সোর্সকে একটি datastore-এর ভেতরে নিজস্ব ট্রি (tree) প্রদান করে।

এগুলো PBS হোস্টে তৈরি করুন। --repository আর্গুমেন্টটির ফরম্যাট হলো [[auth-id@]server[:port]:]datastore, তাই একটি লোকাল নেমস্পেসের ক্ষেত্রে এটি root@pam@localhost:store1 হিসেবে পড়তে হয় এবং কমান্ডটি root পাসওয়ার্ড চায়।

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

এই বিভাজনের ফলে Deduplication-এর ওপর কোনো প্রভাব পড়ে না। Chunks পুরো datastore জুড়ে শেয়ার করা হয়, তাই তিনটি namespace-এ ছড়িয়ে থাকা দশটি Debian guest-এর ক্ষেত্রেও বেস সিস্টেমের মাত্র একটি কপিই জমা থাকে। প্রতি হোস্টের জন্য আলাদা datastore-এর পরিবর্তে namespace-সহ একটি datastore ব্যবহারের যুক্তি এটাই: আলাদা datastore মানে আলাদা chunk pool, আর আলাদা chunk pool মানে একই Debian ইন্সটলেশনের জন্য বারবার জায়গা খরচ করা।

প্রতিটি সোর্সকে তার নিজস্ব namespace-এর আওতাভুক্ত নিজস্ব অ্যাকাউন্ট দিন। একটি API (application programming interface) token হলো এমন একটি credential যা একজন ব্যবহারকারীর অধীনে থাকে এবং এর নিজস্ব অনুমতি (permissions) থাকে, যা এমন কোনো মেশিনের জন্য প্রয়োজন যা চুরি হওয়ার ঝুঁকি থাকে।

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 কমান্ডটি secret-টি শুধুমাত্র একবারই প্রদর্শন করে:

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

এটি এখনই কপি করে রাখুন, কারণ PBS-এর কাছে এর কোনো কপি থাকে না যা আপনাকে পরবর্তীতে আবার দেখাতে পারে। access control কমান্ডটি দুইবার দেখুন। এটি token-এর নাম backup@pbs!pve-home উল্লেখ করে, ব্যবহারকারীর নাম নয়, কারণ token-এর অনুমতি শুধুমাত্র সেই এন্ট্রিগুলো থেকেই নির্ধারিত হয় যেখানে token-এর নাম সরাসরি থাকে। শুধুমাত্র backup@pbs-এর জন্য একটি এন্ট্রি থাকলে token-এর কোনো অ্যাক্সেস থাকে না এবং প্রথম ব্যাকআপটি নেটওয়ার্কে দৃশ্যমান কোনো সমস্যার পরিবর্তে permission সংক্রান্ত ত্রুটির কারণে ব্যর্থ হয়। পাথ (path) বা পথের গুরুত্বও সমান: /datastore/store1/pve-home-এর আওতাভুক্ত কোনো token 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-কে কোনো কিছু ডিলিট না করার নির্দেশ দেয়। রিটেনশন পলিসি 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 গিগাবিট ডেটা স্থানান্তর করে। অর্থাৎ, সর্বনিম্ন সময় লাগবে প্রায় সাড়ে চার ঘণ্টা এবং বাস্তবে এর চেয়ে বেশি সময় লাগতে পারে। যখন আপনার ব্যান্ডউইথ ব্যবহারের প্রয়োজন নেই, তখন ব্যাকআপ শুরু করুন। পরবর্তী প্রতিটি রান শুধুমাত্র নতুন অংশগুলো (chunks) পাঠাবে।

ক্লায়েন্ট-সাইড এনক্রিপশন এবং কি (key) যেখানে থাকে

VPS হলো এমন একটি কম্পিউটার যার মালিক আপনি নন। তাই ক্লায়েন্ট সাইডেই এনক্রিপশন করুন, যাতে ডেটাস্টোরে এমন সব অংশ জমা থাকে যা প্রোভাইডার পড়তে পারে না।

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

এটি /etc/pve/priv/storage/pbs-offsite.enc-এ একটি নতুন কি (key) লেখে, যা শুধুমাত্র root ব্যবহারকারী পড়তে পারেন এবং এটি /etc/pve-এর বাকি অংশের সাথে রেপ্লিকেট হয়। পরবর্তী ব্যাকআপ থেকে, ক্লায়েন্ট প্রতিটি অংশ পাঠানোর আগেই তা এনক্রিপ্ট করে নেয়। সার্ভার আপনার স্ন্যাপশট এবং সেগুলোর আকার দেখতে পেলেও, সেগুলোর ভেতরের তথ্য পড়তে পারে না।

এখন সেই অংশটি, যা এটিকে একটি দায়বদ্ধতার বদলে প্রকৃত ব্যাকআপে পরিণত করে। একটি জেনারেট করা কি-এর কোনো পাসফ্রেজ থাকে না এবং এটি শুধুমাত্র সেই ক্লাস্টারে থাকে যা এটি সুরক্ষিত করে। যদি সেই ক্লাস্টারটি চুরি হয়ে যায় বা অন্য কেউ এনক্রিপ্ট করে ফেলে, তবে VPS-এ এমন ডেটা থাকবে যা কেউ খুলতে পারবে না। কি (key) তৈরি করার দিনই সেটি ক্লাস্টার থেকে কপি করে অন্য কোথাও রাখুন।

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)-টিকে এমন একটি ডকুমেন্ট হিসেবে প্রিন্ট করে যা কাগজে ছাপিয়ে অন্য কোথাও রাখা যায়। ফাইলটিকে অত্যন্ত গোপনীয় হিসেবে গণ্য করুন, কারণ যার কাছে এটি থাকবে সে এই কি (key) দিয়ে তৈরি প্রতিটি ব্যাকআপ ডিক্রিপ্ট করতে পারবে। বড় কোনো সেটআপের জন্য, PBS একটি মাস্টার কি (master key) সমর্থন করে, যা proxmox-backup-client key create-master-key দিয়ে তৈরি একটি RSA (Rivest Shamir Adleman) কি পেয়ার। এক্ষেত্রে প্রতিটি ব্যাকআপ তার নিজস্ব এনক্রিপশন কি-কে পাবলিক হাফ দিয়ে এনক্রিপ্ট করে রাখে, আর প্রাইভেট হাফটি রিকভারির জন্য অফলাইনে রাখা হয়।

এই ডিজাইনের একটি পরিণতির কথা কাজ শুরু করার আগেই জেনে রাখা ভালো। এনক্রিপ্ট করা ব্যাকআপের ক্ষেত্রে, চাঙ্ক ডাইজেস্ট (chunk digest) হিসাব করা হয় প্লেইন টেক্সট কন্টেন্ট এবং এনক্রিপশন কি-এর সমন্বয়ে। ফলে ভিন্ন ভিন্ন কি (key) দিয়ে এনক্রিপ্ট করা দুটি অভিন্ন চাঙ্ক ভিন্ন ভিন্ন ডাইজেস্ট তৈরি করে এবং কখনোই একে অপরের সাথে ডিডুপ্লিকেট (deduplicate) হয় না। কি (key) পরিবর্তন করার অর্থ হলো পরবর্তী ব্যাকআপে সবকিছু পুনরায় আপলোড হবে এবং পুরনো চাঙ্কগুলো ততক্ষণ পর্যন্ত থেকে যাবে যতক্ষণ না সেগুলোর স্ন্যাপশট প্রুন (prune) বা ডিলিট করা হয়। তাই প্রথমবার আপলোড করার আগেই এনক্রিপশন সম্পর্কে সিদ্ধান্ত নিন।

Prune মার্ক এবং গারবেজ কালেকশন রিক্লেইম

এই অংশটি সাধারণত এড়িয়ে যাওয়া হয়, অথচ এটিই ভলিউম পূর্ণ হওয়ার মূল কারণ। একটি snapshot prune করলে এর মেটাডেটা মুছে যায়: যেমন manifest, index, log এবং notes। এটি কোনো chunk মুছে ফেলে না। যেহেতু snapshot-গুলোর মধ্যে chunk শেয়ার করা থাকে, তাই প্রতিটি index পড়া না হওয়া পর্যন্ত কোনো chunk অব্যবহৃত কি না তা নিশ্চিত হওয়া সম্ভব নয়, আর এই পড়ার কাজটিই গারবেজ কালেকশন করে। একটি datastore-এ যদি prune-এর সময়সূচী থাকে কিন্তু গারবেজ কালেকশনের সময়সূচী না থাকে, তবে সেটি কেবল বাড়তেই থাকে।

উভয়ই সেট করুন। প্রথমে 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-এ কালেকশনের সময়সূচী নির্ধারণ করুন, যা 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 কমান্ড দিন, দেখবেন ব্যবহৃত জায়গার পরিমাণে কোনো পরিবর্তন হয়নি। এরপর গারবেজ কালেকশন চালান এবং পুনরায় df কমান্ড দিন, এবার পরিবর্তন দেখতে পাবেন।

গারবেজ কালেকশন দুটি ধাপে সম্পন্ন হয়। প্রথম ধাপে datastore-এর প্রতিটি index পরীক্ষা করা হয় এবং সেই index-গুলো যে chunk-কে রেফার করে, সেগুলোর access time আপডেট করা হয়। দ্বিতীয় ধাপে সেই chunk-গুলো মুছে ফেলা হয় যেগুলোর access time কাট-অফ সময়ের চেয়ে পুরনো। এই কাট-অফ সময় হলো রান শুরু হওয়ার 24 ঘণ্টা 5 মিনিট আগে, অথবা বর্তমানে চলমান সবচেয়ে পুরনো backup-এর শুরুর সময়—যেটি আগে ঘটে। এই মার্জিনটি থাকার কারণ হলো, Linux ডিফল্টভাবে filesystem-কে relatime দিয়ে mount করে, যা প্রতিবার পড়ার পরিবর্তে দিনে একবার access time আপডেট করে। তাই এক ঘণ্টা আগে লেখা কোনো chunk মুছে ফেলা হয় না, এমনকি যদি সেটি কেউ রেফার না-ও করে। ফলে prune করার পর জায়গা খালি হতে সেই সময়ের প্রয়োজন হয়, যা chunk-টি সর্বশেষ ব্যবহারের একদিন পর প্রথম কালেকশন রান করার সময় দেখা যায়। কোনো datastore-এ যদি মনে হয় জায়গা খালি হয়নি, তবে বুঝতে হবে সেটি এই সময়ের সীমার মধ্যেই আছে।

একটি ছোট VPS-এ এটিই সবচেয়ে ভারী কাজ, কারণ এটি ভলিউমের প্রতিটি chunk ফাইল stat করে। task log-এর শেষে কী মুছে ফেলা হয়েছে এবং grace period-এর কারণে কী এখনো পেন্ডিং আছে তার একটি সারাংশ থাকে। যদি অনেক কিছু পেন্ডিং থাকে, তবে পরের দিন আবার এটি চালান। PBS datastore টিউনিং অপশন হিসেবে gc-atime-safety-check এবং gc-atime-cutoff প্রদান করে, তবে এগুলো পরিবর্তন না করাই ভালো। এগুলো এমন স্টোরেজের জন্য রাখা হয়েছে যা access time রেকর্ড করতে পারে না। noatime দিয়ে mount করা filesystem-এ এই নিরাপত্তা চেক বন্ধ করে দিলে এমন chunk মুছে যাওয়ার ঝুঁকি থাকে যা এখনো কোনো live snapshot রেফার করছে।

যাচাইকরণ নিশ্চিত করে যে চাঙ্কগুলো এখনো পাঠযোগ্য

একটি ব্যাকআপ সফলভাবে আপলোড হওয়ার এক বছর পরেও তা পাঠযোগ্য নাও থাকতে পারে। যাচাইকরণ প্রক্রিয়া চাঙ্কগুলো পুনরায় পড়ে সেগুলোকে ইনডেক্সে সংরক্ষিত চেকসামের সাথে তুলনা করে। ফলে রিস্টোর করার সময় নয়, বরং নিয়মিত সময়সূচী অনুযায়ী ডেটার ক্ষতি শনাক্ত করা সম্ভব হয়।

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

ছোট VPS-এর ক্ষেত্রে থ্রেড সংখ্যা কম রাখুন। যাচাইকরণ প্রক্রিয়াটি ডিস্ক এবং CPU-এর ক্ষমতার ওপর নির্ভরশীল, তাই এটি সার্ভারের অন্যান্য কাজের সাথে প্রতিযোগিতায় লিপ্ত হতে পারে। সময়সূচীর জন্য ওয়েব ইন্টারফেসের datastore-এর Verify Jobs ট্যাব ব্যবহার করুন: একটি সাপ্তাহিক জব সেট করুন যা ইতিমধ্যে যাচাই করা স্ন্যাপশটগুলো এড়িয়ে যাবে এবং 30 দিনের বেশি পুরনো যেকোনো কিছু পুনরায় যাচাই করবে। এতে বাড়তি কাজ ছাড়াই পুরো স্টোরটি সময়ের সাথে যাচাই করা সম্ভব হয়।

যে স্ন্যাপশট যাচাইকরণে ব্যর্থ হয়, সেটিকে datastore ভিউতে failed হিসেবে চিহ্নিত করা হয়। এটিকে উপেক্ষা করবেন না। যেহেতু চাঙ্কগুলো শেয়ার করা থাকে, তাই একটি বেস ইমেজ থেকে একটি ক্ষতিগ্রস্ত চাঙ্ক সাধারণত সেই ইমেজকে রেফারেন্স করা প্রতিটি স্ন্যাপশটকে ব্যর্থ করে দেয়। এর প্রতিকার হলো ব্যর্থ স্ন্যাপশটগুলোকে forget করা এবং নতুন করে ব্যাকআপ চালানো, যা হারিয়ে যাওয়া চাঙ্কগুলোকে পুনরায় আপলোড করবে। যদি বারবার ব্যর্থতা দেখা দেয়, তবে datastore-এর নিচের স্টোরেজটিকে সন্দেহ করুন এবং VPS-এ ডিস্ক হেলথ মনিটরিং সেট আপ করুন, যাতে ভেরিফাই জব শনাক্ত করার আগেই ড্রাইভ আপনাকে সতর্ক করতে পারে।

একটি রিস্টোর পরীক্ষা করুন, তারপর ক্লাস্টার ছাড়া সেটি পরীক্ষা করুন

একটি ব্যাকআপ কার্যকর কি না তা আপনি নিশ্চিতভাবে জানতে পারবেন না যতক্ষণ না আপনি সেটি রিস্টোর করছেন। দুটি ভিন্ন পরীক্ষা করুন, কারণ এগুলো ভিন্ন ভিন্ন বিষয় যাচাই করে।

পুরো গেস্ট, ক্লাস্টারের ওপর:

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

pvesm list-এর প্রথম কলামটি হলো ভলিউম আইডি এবং টাইমস্ট্যাম্প এর অংশ, তাই উদাহরণ টাইপ না করে আপনারটি কপি করুন। একটি অব্যবহৃত গেস্ট আইডিতে এবং ভিন্ন স্টোরেজে রিস্টোর করুন, তারপর এর নেটওয়ার্ক ইন্টারফেস বিচ্ছিন্ন রেখে এটি চালু করুন। ব্যাকআপ কাজ করছে কি না তা যাচাই করার জন্য কখনোই চলমান কোনো গেস্টের ওপর রিস্টোর করবেন না, কারণ রিস্টোর মাঝপথে ব্যর্থ হলে আপনার কাছে থাকা কার্যকর কপিটিও নষ্ট হয়ে যেতে পারে।

দ্বিতীয় পরীক্ষাটি কেউ করে না। ধরে নিন যে ভবনে ক্লাস্টারটি ছিল সেটি আর নেই, এবং এমন একটি মেশিন থেকে রিস্টোর করুন যা কখনোই এর অংশ ছিল না। যেকোনো 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 guest তাদের মধ্যে base system-এর একটি কপি শেয়ার করে, তাই দ্বিতীয় একই ধরনের guest সংরক্ষণ করতে প্রায় কোনো খরচই হয় না। এটি upload bandwidth-ও সাশ্রয় করে, কারণ সার্ভারে ইতিমধ্যে থাকা কোনো chunk-এর জন্য client ডেটার পরিবর্তে শুধু একটি checksum পাঠায়।

এটি কী করে না, তা স্পষ্টভাবে জেনে রাখা প্রয়োজন।

• এটি পরিবর্তিত ডেটার আকার ছোট করে না। যে database প্রতি রাতে তার ফাইলের বড় অংশ নতুন করে লেখে, তা প্রতি রাতে নতুন chunk তৈরি করে এবং retention সেগুলোকে বহুগুণ বাড়িয়ে দেয়।
• এটি encryption key-এর সীমানা অতিক্রম করতে পারে না, যা উপরে আলোচনা করা হয়েছে।
• এটি datastore-এর সীমানা অতিক্রম করতে পারে না, যা namespaces ব্যবহারের মূল কারণ।
• এটি volume পূর্ণ হওয়া রোধ করতে পারে না। যখন datastore পূর্ণ হয়ে যায়, তখন backup ব্যর্থ হয় এবং এর একমাত্র সমাধান হলো বড় volume ব্যবহার করা অথবা retention কমিয়ে আনা।

এর নিচে অন্য কোনো deduplication স্তর যুক্ত করবেন না। Chunks ইতিমধ্যে client দ্বারা deduplicated এবং compressed হয়ে আসে, তাই datastore-এর নিচে ZFS deduplication ব্যবহার করলে RAM অকারণে এমন সব মিল খুঁজতে ব্যয় হয় যা লেখার আগেই সরিয়ে ফেলা হয়েছে। এই ক্ষেত্রে volume-এ সাধারণ ext4 বা xfs ব্যবহার করাই সঠিক সিদ্ধান্ত।

Web interface-এ datastore-এর জন্য একটি deduplication factor দেখানো হয়। সেই সংখ্যাটি আপনার guest-গুলোর ওপর ভিত্তি করে তৈরি এবং পরিকল্পনা করার জন্য কেবল এটিই নির্ভরযোগ্য, কারণ প্রকাশিত অনুপাতগুলো অন্য কারো ডেটার ওপর ভিত্তি করে তৈরি। যদি আপনার Proxmox guest নয় এমন মেশিনের file-level backup-এর প্রয়োজন হয়, তবে একই VPS-এ সেগুলো পাশাপাশি চালান: PBS হলো পুরো guest-এর জন্য একটি hypervisor-aware target, যেখানে restic and BorgBackup ডিরেক্টরিগুলোকে লক্ষ্য করে কাজ করে এবং restic backups to a VPS সেইসব laptop ও standalone server-এর জন্য উপযুক্ত, যেগুলোর জন্য PBS তৈরি করা হয়নি।

ব্যর্থতার ধরন এবং যা আপনি দেখতে পাবেন

স্টোরেজটি inactive হিসেবে দেখায়। যখন কোনো নোড 8007 পোর্টে TLS সেশন সম্পন্ন করতে পারে না, তখন pvesm status --storage pbs-offsite আউটপুট হিসেবে inactive প্রদর্শন করে। প্রথমে VPS-এর ফায়ারওয়াল এবং এরপর প্রোভাইডারের আলাদা নেটওয়ার্ক ফায়ারওয়াল পরীক্ষা করুন, সবশেষে ফিঙ্গারপ্রিন্ট যাচাই করুন। যদি ফিঙ্গারপ্রিন্ট সার্টিফিকেটের সাথে না মেলে, তবে তা পোর্ট ব্লক থাকার মতোই ব্যর্থতা দেখায়; সার্টিফিকেট প্রতিস্থাপন করা হলে ফিঙ্গারপ্রিন্টও পরিবর্তিত হয়।

প্রথম ব্যাকআপটি পারমিশনজনিত কারণে ব্যর্থ হয়। অ্যাক্সেস কন্ট্রোল এন্ট্রিতে ব্যবহারকারীর পরিবর্তে টোকেনের নাম থাকতে হবে এবং এটি সেই নেমস্পেসকে কভার করতে হবে যার দিকে স্টোরেজ নির্দেশ করে। অন্য কোথাও খোঁজার আগে ওয়েব ইন্টারফেসের datastore-এর permissions ট্যাবে এই দুটি বিষয় নিশ্চিত করুন।

গার্বেজ কালেকশন শুরু হতে অস্বীকার করে। অ্যাক্সেস টাইম সেফটি চেক ব্যর্থ হয়েছে, যার অর্থ প্রায় সবসময়ই datastore ফাইলসিস্টেমটি noatime মোডে মাউন্ট করা আছে। এটি নিশ্চিত করতে findmnt -no OPTIONS /mnt/datastore/store1 চালান, /etc/fstab-এ অপশনটি ঠিক করুন এবং পুনরায় মাউন্ট করুন। এই সমস্যা এড়ানোর জন্য চেকটি ডিজেবল করবেন না।

datastore শুধুমাত্র বাড়তেই থাকে। প্রুন জব (prune jobs) চলার পরেও কোনো জায়গা খালি হয় না। এর কারণ হতে পারে কোনো গার্বেজ কালেকশন শিডিউল নেই, অথবা প্রতিটি কালেকশন 24 ঘণ্টার গ্রেস উইন্ডোর মধ্যে পড়ে যাচ্ছে কারণ এটি ব্যাকআপের পরপরই চলে। proxmox-backup-manager datastore show store1 দিয়ে শিডিউলটি পরীক্ষা করুন।

যে ব্যাকআপটি আগে দ্রুত হতো তা এখন কয়েক ঘণ্টা সময় নেয়। কোনো গেস্ট যদি বন্ধ, মাইগ্রেট বা রিস্টোর করা হয়, তবে সেটি তার dirty bitmap হারিয়ে ফেলে। ফলে ক্লাস্টার সাইডে পরবর্তী রান পুরো ডিস্ক রিড করে, যদিও খুব সামান্য ডেটা আপলোড হয়। টাস্ক লগে দেখা যায় যে কাজের সময়কাল অনেক বেশি কিন্তু আপলোডের পরিমাণ খুব কম, এবং এর পরের রানটি আবার দ্রুত হয়। যদি VPS-এর প্রতিটি কাজই ধীরগতির হয়, তবে এর কারণ সাধারণত datastore-এর বাইরে থাকে এবং এক্ষেত্রে noisy neighbour থেকে CPU steal time পরিমাপ করা প্রথম কাজ।

FAQ

প্রুন (prune) জব চলার পরেও আমার Proxmox Backup Server-এর ডেটাস্টোর কেন ক্রমাগত বড় হচ্ছে?

কারণ প্রুনিং শুধুমাত্র স্ন্যাপশট মেটাডেটা মুছে ফেলে: যেমন ম্যানিফেস্ট, ইনডেক্স, লগ এবং নোট। কোনো ইনডেক্স আর রেফারেন্স করে না এমন চাঙ্ক (chunk) গুলো গারবেজ কালেকশন (garbage collection) দ্বারা মুছে না ফেলা পর্যন্ত সেগুলো ডিস্কেই থেকে যায়। ডেটাস্টোরে proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' দিয়ে একটি শিডিউল সেট করুন এবং proxmox-backup-manager garbage-collection start store1 চালানোর আগে ও পরে ডেটাস্টোর পাথে df -h চালিয়ে তা যাচাই করুন। অন্তত একদিনের বিলম্ব আশা করুন, কারণ গারবেজ কালেকশনের দ্বিতীয় ধাপে শুধুমাত্র সেই চাঙ্কগুলোই মুছে ফেলা হয় যেগুলোর অ্যাক্সেস টাইম 24 ঘণ্টা 5 মিনিটের বেশি পুরনো।

একটি Proxmox Backup Server VPS-এর জন্য কতটুকু ডিস্ক প্রয়োজন?

প্রতিটি গেস্ট প্রকৃতপক্ষে যে পরিমাণ জায়গা ব্যবহার করে তার যোগফল বের করুন, তারপর প্রতিদিনের পরিবর্তনের পরিমাণকে আপনি যতদিনের ব্যাকআপ রাখতে চান সেই সংখ্যা দিয়ে গুণ করে যোগ করুন। কম্প্রেশন এবং ডিডুপ্লিকেশন আপনার পক্ষে কাজ করায় এই মোট পরিমাণটি একটি সর্বোচ্চ সীমা হিসেবে কাজ করবে। ইনডেক্স এবং কাজের সুবিধার জন্য এর সাথে আরও এক-পঞ্চমাংশ জায়গা যোগ করুন, তারপর আপনার কেনা সম্ভব এমন একটি ভলিউম সাইজে রাউন্ড আপ করুন। দুই সপ্তাহ পর ডেটাস্টোর ভিউতে প্রকৃত ব্যবহারের সাথে এটি পুনরায় যাচাই করুন, কারণ প্রথম ব্যাকআপের আগে করা অনুমান সবসময়ই কোনো না কোনো দিকে ভুল হয়।

ব্যাকআপ এনক্রিপশন কি (encryption key) কোথায় রাখা উচিত?

যে ক্লাস্টারটিকে এটি সুরক্ষা দেয়, সেটি ছাড়া অন্য যেকোনো জায়গায় রাখুন। Proxmox VE এটিকে /etc/pve/priv/storage/<storage>.enc-এ রাখে, যা প্রতিটি নোডে রেপ্লিকেট হয় এবং তাই ক্লাস্টার নষ্ট হয়ে গেলে এটিও হারিয়ে যায়। প্রথম দিনেই এটি কপি করে নিন, proxmox-backup-client key paperkey ব্যবহার করে প্রিন্ট করুন এবং সেই কপিটি অন্য কোনো ভবনে রাখুন। মনে রাখবেন, কি-টি চাঙ্ক ডাইজেস্টের অংশ হিসেবে কাজ করে, তাই পরবর্তীতে এটি পরিবর্তন করলে পরবর্তী ব্যাকআপে সবকিছু পুনরায় আপলোড করতে হবে।

আমার কি প্রতিটি Proxmox হোস্টের জন্য একটি করে ডেটাস্টোর প্রয়োজন, নাকি নেমস্পেস (namespaces) ব্যবহার করব?

প্রতিটি সোর্স হোস্ট বা ক্লাস্টারের জন্য একটি ডেটাস্টোর এবং একটি নেমস্পেস ব্যবহার করুন। ডিডুপ্লিকেশন একটি ডেটাস্টোরের ভেতরে কাজ করে, কিন্তু একাধিক ডেটাস্টোরের মধ্যে নয়; তাই হোস্ট অনুযায়ী আলাদা করলে একই বেস ইমেজ বারবার জমা হয়। নেমস্পেস ব্যাকআপ গ্রুপগুলোকে আলাদা রাখে, ফলে দুটি হোস্টের একই আইডি 100 বিশিষ্ট গেস্ট থাকলেও কোনো সংঘর্ষ হয় না। এছাড়া /datastore/store1/pve-home ফরম্যাটের অ্যাক্সেস কন্ট্রোল পাথ প্রতিটি হোস্টের API টোকেনকে শুধুমাত্র তার নিজস্ব নেমস্পেসের মধ্যে সীমাবদ্ধ রাখে।

একটি ছোট VPS কি Proxmox ব্যাকআপ সার্ভার হিসেবে কার্যকর হবে?

সাধারণত হোম ল্যাবের জন্য এটি কার্যকর, কারণ চাঙ্কিং এবং হ্যাশিংয়ের কাজ Proxmox VE নোডেই সম্পন্ন হয়, ব্যাকআপ সার্ভারে নয়। VPS শুধুমাত্র চাঙ্কগুলো লেখে এবং দুটি ভারী কাজ—গারবেজ কালেকশন ও ভেরিফিকেশন—সম্পাদন করে। এটিকে 4 GB RAM দিন এবং ভেরিফিকেশন থ্রেডের সংখ্যা কম রাখুন। উভয় জবই ব্যাকআপ উইন্ডোর বাইরে শিডিউল করুন। যদি এরপরও ডিস্কের সক্ষমতার তুলনায় এগুলো অনেক বেশি সময় নেয়, তবে বড় প্ল্যান কেনার আগে স্টিল টাইম (steal time) মেপে দেখুন।