VPS پر Proxmox Backup Server کیسے انسٹال کریں

VPS پر Proxmox Backup Server آپ کو اصل میں کیا فراہم کرتا ہے

VPS پر Proxmox Backup Server (PBS) ایک آف سائٹ ٹارگٹ ہے جو اسی پروٹوکول پر کام کرتا ہے جسے آپ کا Proxmox VE (ورچوئل انوائرمنٹ) کلسٹر پہلے ہی استعمال کر رہا ہے۔ اس لیے پہلے بیک اپ کے بعد ہر بیک اپ انکریمنٹل ہوتا ہے، گیسٹس کے درمیان ڈیڈپلیکیٹڈ (deduplicated) ہوتا ہے، آپ کی عمارت سے نکلنے سے پہلے انکرپٹ ہوتا ہے، اور بعد میں قابل تصدیق ہوتا ہے۔ آپ ایک بلاک والیوم کے ساتھ VPS کرائے پر لیتے ہیں، Debian 13 پر PBS انسٹال کرتے ہیں، اس والیوم پر ایک ڈیٹا اسٹور بناتے ہیں، اور اسے Proxmox VE میں pbs قسم کی اسٹوریج کے طور پر شامل کرتے ہیں۔ انسٹالیشن میں 10 منٹ لگتے ہیں۔ اس کے بعد کی ہر چیز، جیسے کہ نیم اسپیسز، گاربیج کلیکشن، کی کسٹڈی اور وہ ریسٹور جسے آپ نے حقیقت میں رن کیا ہو، یہ فیصلہ کرتی ہے کہ آیا ایک سال بعد یہ بیک اپ کسی کام کا ہوگا یا نہیں۔

کرائے کی ڈسک پر vzdump فائلیں کاپی کرنے کے بجائے PBS استعمال کرنے کی وجہ اس کا چنک اسٹور (chunk store) ہے۔ کلائنٹ ہر گیسٹ ڈسک کو تقریباً 4 MiB کے چنکس میں تقسیم کرتا ہے، ان کا ہیش بناتا ہے، اور صرف وہی چنکس اپ لوڈ کرتا ہے جو ڈیٹا اسٹور میں پہلے سے موجود نہیں ہوتے۔ چلتی ہوئی ورچوئل مشین کے لیے، QEMU پہلے بیک اپ کے بعد dirty bitmap میں تبدیل شدہ بلاکس کو ٹریک کرتا ہے، لہذا اگلی بار صرف وہی بلاکس لوکل ڈسک سے پڑھے جاتے ہیں۔ ایک 200 GB کا گیسٹ جو روزانہ 3 GB تبدیل کرتا ہے، وہ تقریباً 3 GB روزانہ ہی بھیجتا ہے۔ یہی وہ چیز ہے جو ہوم اپ لنک اور کرائے کے والیوم کو ایک ساتھ کام کرنے کے قابل بناتی ہے، اور یہی وجہ ہے کہ آف سائٹ بیک اپ ٹارگٹ کے طور پر VPS کسی دوست کے گھر پر موجود فالتو ڈرائیو سے بہتر ہے۔ اگر آپ ابھی بھی یہ فیصلہ کر رہے ہیں کہ ہائپر وائزر کو خود کہاں ہونا چاہیے، تو گھر پر Proxmox بمقابلہ کرائے کا VPS اس سوال کا الگ سے احاطہ کرتا ہے۔

کرایہ پر لینے سے پہلے والیوم کا سائز طے کریں

سائزنگ ایک حسابی عمل ہے جو آپ اپنے اعداد و شمار پر کرتے ہیں۔ ہر گیسٹ (guest) جتنی جگہ درحقیقت استعمال کرتا ہے اسے لیں، نہ کہ اس کی ورچوئل ڈسک کا سائز، پھر اس میں روزانہ ہونے والی تبدیلی کو ان دنوں کی تعداد سے ضرب دے کر شامل کریں جتنے دن آپ بیک اپ رکھنا چاہتے ہیں۔ کمپریشن (compression) اور ڈیڈپلیکیشن (deduplication) دونوں اس اعداد و شمار کو بہتر بناتے ہیں، لہذا نتیجے کو ایک حد (ceiling) سمجھیں، ہدف نہیں۔

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

یہ قطاریں ایک کام کی مثال ہیں، پیمائش نہیں۔ ہر گیسٹ کے اندر df -h سے استعمال شدہ جگہ پڑھیں، اور PBS ٹاسک لاگ میں دوسرے اور تیسرے بیک اپ کے سائز سے روزانہ کی تبدیلی معلوم کریں، جب وہ موجود ہوں۔

مثال میں موجود میل گیسٹ 120 GB استعمال کرتا ہے اور روزانہ تقریباً 3.0 GB تبدیل ہوتا ہے، لہذا تیس روزانہ اسنیپ شاٹس کے لیے تقریباً 210 GB درکار ہیں: ایک مکمل کاپی جمع تیس دن کی تبدیلی۔ تمام 3 گیسٹس کے لیے آخری کالم کو جمع کریں تو کل تقریباً 619 GB بنتا ہے۔ انڈیکسز، میٹا ڈیٹا اور گاربیج کلیکشن (garbage collection) کے لیے درکار جگہ کے لیے اس میں پانچواں حصہ مزید شامل کریں، جو 1 TB والیوم کی طرف اشارہ کرتا ہے۔

باقی منصوبہ چھوٹا ہے۔ PBS کو 2 GB RAM کے ساتھ کوئی مسئلہ نہیں ہوتا اور 4 GB کے ساتھ یہ آرام سے چلتا ہے، کیونکہ بھاری کام کلسٹر کی طرف ہوتا ہے: Proxmox VE نوڈ گیسٹ ڈسکس کو پڑھتا ہے اور چنکنگ (chunking) اور ہیشنگ (hashing) کرتا ہے۔ VPS کا کام چنکس کو لکھنا اور دو بھاری کام چلانا ہے: گاربیج کلیکشن اور ویریفیکیشن۔ ڈیٹا اسٹور کو ایک بڑے روٹ ڈسک کے بجائے الگ بلاک والیوم کے طور پر کرایہ پر لیں، کیونکہ آپ سرور کو دوبارہ بنائے بغیر بعد میں والیوم کو بڑھا سکتے ہیں۔

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 امیج سے شروعات کریں۔ نیچے دی گئی تمام کمانڈز 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 کا مطلب ہے کہ آپ ایسے پیکیجز انسٹال کرنے والے ہیں جن پر کسی ایسی چیز کے دستخط ہیں جس کی آپ نے تصدیق نہیں کی۔

/etc/apt/sources.list.d/pbs.sources کو no-subscription repository کے ساتھ لکھیں، جو کہ سپورٹ کنٹریکٹ کے بغیر سرور کے لیے درست انتخاب ہے:

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 بعد میں پن (pin) کرتا ہے، لہذا یہ وارننگ متوقع ہے نہ کہ کوئی ایسی پریشانی جسے حل کرنے کی ضرورت ہو۔

پورٹ 8007 عوامی انٹرنیٹ پر ایک لاگ ان فارم ہے، لہذا اسے ہر کسی کے لیے کھلا نہ چھوڑیں۔ ایک nftables فائل اس کا احاطہ کرتی ہے۔ /etc/nftables.conf لکھنے سے موجودہ رولز سیٹ صاف (flush) ہو جاتا ہے، لہذا اگر اس مشین پر فائر وال کو کوئی اور چیز مینیج کر رہی ہے تو اسے چھوڑ دیں۔

#!/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 کی جگہ وہ ایڈریس لکھیں جہاں سے آپ کا کلسٹر نکلتا ہے۔ اگر وہ ایڈریس متحرک (dynamic) ہے، تو یا تو رول کو اپنے پرووائیڈر کی رینج تک وسیع کریں یا کنکشن کو ٹنل میں ختم کریں، اور یاد رکھیں کہ زیادہ تر VPS پینلز میں مشین کے سامنے ایک الگ نیٹ ورک فائر وال ہوتی ہے جسے اسی پورٹ کی اجازت دینی چاہیے۔

Datastore کو اس کے اپنے volume پر رکھیں

Datastore کو root filesystem پر نہیں ہونا چاہیے۔ جب ایک datastore مشترکہ root filesystem کو بھر دیتا ہے، تو backup ناکام ہو جاتا ہے اور سرور پر موجود ہر دوسری چیز بھی، بشمول وہ لاگز جن کی آپ کو وجہ تلاش کرنے کے لیے ضرورت ہوتی ہے۔ Block volume منسلک کریں، اسے 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 کو پرنٹ کرنا چاہیے۔ اس ایک لائن میں دو ناکامیاں چھپی ہوتی ہیں۔ اگر mount وہاں موجود نہ ہو اور آپ پھر بھی datastore بنا دیں، تو PBS mount point کے نیچے root filesystem میں لکھنا شروع کر دیتا ہے، اور اگلا کامیاب mount اس ڈیٹا کو حذف کیے بغیر چھپا دیتا ہے: تب 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 ڈائریکٹری بناتا ہے جس میں 65536 ذیلی ڈائریکٹریاں ہوتی ہیں، جن کے نام 0000 سے ffff تک ہوتے ہیں۔ ایک datastore لاکھوں چھوٹی فائلوں پر مشتمل ہوتا ہے، نہ کہ چند بڑی فائلوں پر۔ اس سے دو نتائج نکلتے ہیں۔ کسی عام file-level ٹول کے ساتھ datastore کو کاپی کرنا اتنا سست ہے کہ بے کار ہے، اور بیک اپ چلتے وقت لیا گیا provider volume snapshot اس کی مستقل کاپی نہیں ہوتا، یہی وجہ ہے کہ snapshots بیک اپ کا متبادل نہیں ہوتے، کہیں اور بھی۔

Namespaces دو hosts کو آپس میں ٹکرانے سے روکتے ہیں

ڈیٹا اسٹور بائی ڈیفالٹ فلیٹ (flat) ہوتا ہے۔ بیک اپس کے نام vm/100، ct/101 اور host/<name> ہوتے ہیں۔ اگر دو کلسترز میں سے ہر ایک کے پاس ID 100 والا گیسٹ ہو اور وہ ایک ہی گروپ میں لکھیں، تو ان کے اسنیپ شاٹس آپس میں مل جائیں گے، اور ایک کے لیے لکھا گیا ریٹینشن رول دوسرے کے اسنیپ شاٹس کو بھی شمار کر لے گا۔ Namespaces ہر سورس کو ایک ہی ڈیٹا اسٹور کے اندر اپنی الگ ٹری (tree) فراہم کرتی ہیں۔

انہیں PBS ہوسٹ پر بنائیں۔ --repository آرگومنٹ کی شکل [[auth-id@]server[:port]:]datastore ہوتی ہے، لہذا ایک لوکل نیم اسپیس root@pam@localhost:store1 کہلائے گی، اور کمانڈ روٹ پاس ورڈ مانگے گی۔

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

ڈی ڈپلیکیشن (deduplication) اس تقسیم سے متاثر نہیں ہوتی۔ چنکس (chunks) پورے ڈیٹا اسٹور میں شیئر ہوتے ہیں، لہذا تین مختلف نیم اسپیسز میں پھیلے ہوئے دس Debian گیسٹس بھی بیس سسٹم کی صرف ایک کاپی اسٹور کریں گے۔ یہی وجہ ہے کہ فی ہوسٹ ایک ڈیٹا اسٹور کے بجائے نیم اسپیسز کے ساتھ ایک ڈیٹا اسٹور کو ترجیح دی جاتی ہے: الگ الگ ڈیٹا اسٹورز کا مطلب الگ الگ چنک پولز ہیں، اور الگ چنک پولز کا مطلب ایک ہی Debian انسٹال کی قیمت کئی بار ادا کرنا ہے۔

ہر سورس کو اپنا اکاؤنٹ دیں، جو صرف اس کی اپنی نیم اسپیس تک محدود ہو۔ ایک API (ایپلیکیشن پروگرامنگ انٹرفیس) ٹوکن ایک ایسی اسناد (credential) ہے جو صارف سے منسلک ہوتی ہے اور اس کے اپنے پرمیشنز ہوتے ہیں، جو کہ ایسی مشین پر ضروری ہے جس کے چوری ہونے کا خدشہ ہو۔

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'

ٹوکن کمانڈ سیکرٹ کو صرف ایک بار پرنٹ کرتی ہے:

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

اسے ابھی کاپی کریں، کیونکہ PBS کے پاس اس کی کوئی ایسی شکل نہیں ہوتی جسے وہ آپ کو دوبارہ دکھا سکے۔ ایکسس کنٹرول کمانڈ کو دو بار دیکھیں۔ یہ ٹوکن کا نام backup@pbs!pve-home بتاتی ہے، نہ کہ صارف کا، کیونکہ ٹوکن کے پرمیشنز صرف ان اندراجات سے شمار ہوتے ہیں جن میں ٹوکن کا اپنا نام ہو۔ صرف backup@pbs کے لیے اندراج ٹوکن کو بغیر کسی رسائی کے چھوڑ دیتا ہے، اور پھر پہلا بیک اپ نیٹ ورک میں نظر آنے والی کسی چیز کے بجائے پرمیشنز کی وجہ سے ناکام ہو جاتا ہے۔ پاتھ (path) بھی اتنی ہی اہمیت رکھتا ہے: /datastore/store1/pve-home تک محدود ٹوکن آفس نیم اسپیس میں کچھ بھی پڑھ یا ڈیلیٹ نہیں کر سکتا، لہذا ایک متاثرہ کلستر کسی دوسری سائٹ کی ہسٹری کو تباہ نہیں کر سکتا۔

Proxmox VE میں VPS کو بطور بیک اپ اسٹوریج شامل کرنا

سب سے پہلے PBS ہوسٹ پر certificate fingerprint پڑھیں۔

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 آپ سے اس کا مطالبہ کرے گا، تاکہ token secret آپ کی شیل ہسٹری میں محفوظ نہ ہو۔ یہ /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 کا مطلب ہے کہ نوڈ port 8007 پر TLS (ٹرانسپورٹ لیئر سیکیورٹی) سیشن مکمل نہیں کر سکا، جو کہ credential کے بجائے firewall یا fingerprint کا مسئلہ ہے۔

پہلا بیک اپ سب کچھ اپ لوڈ کرتا ہے، لہذا اسے شروع کرنے سے پہلے حساب کتاب کر لیں۔ 200 GB کا مطلب 1600 گیگا بٹس ہے، اور 100 Mbit اپ لنک 0.1 گیگا بٹ فی سیکنڈ منتقل کرتا ہے، لہذا کم از کم وقت ساڑھے چار گھنٹے ہے اور حقیقت میں یہ اس سے زیادہ ہوگا۔ اسے تب شروع کریں جب آپ کو بینڈوتھ کی ضرورت نہ ہو۔ اس کے بعد ہر رن صرف نئے چنکس (chunks) بھیجتا ہے۔

کلائنٹ سائیڈ انکرپشن، اور کلید کہاں رہتی ہے

VPS ایک ایسا کمپیوٹر ہے جس کے آپ مالک نہیں ہیں۔ کلائنٹ پر انکرپشن کریں، اور ڈیٹا اسٹور ایسے ٹکڑے (chunks) محفوظ کرتا ہے جنہیں فراہم کنندہ (provider) پڑھ نہیں سکتا۔

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

یہ /etc/pve/priv/storage/pbs-offsite.enc میں ایک نئی کلید لکھتا ہے، جسے صرف root پڑھ سکتا ہے، اور اسے /etc/pve کے باقی حصوں کے ساتھ نقل (replicate) کیا جاتا ہے۔ اگلے بیک اپ سے، کلائنٹ ہر ٹکڑے کو باہر بھیجنے سے پہلے انکرپٹ کرتا ہے۔ سرور اب بھی آپ کے اسنیپ شاٹس اور ان کے سائز کی فہرست بنا سکتا ہے، لیکن یہ ان کے مواد کو پڑھ نہیں سکتا۔

اب وہ حصہ جو اسے ایک ذمہ داری کے بجائے بیک اپ بناتا ہے۔ تیار کردہ کلید کا کوئی پاس فریز (passphrase) نہیں ہوتا، اور یہ صرف اسی کلسٹر پر موجود ہوتی ہے جس کی یہ حفاظت کرتی ہے۔ اگر وہ کلسٹر چوری ہو جائے یا کوئی اور اسے انکرپٹ کر دے، تو 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 کلید کو ایک ایسے دستاویز کے طور پر پرنٹ کرتا ہے جسے کاغذ پر چھاپ کر کہیں اور رکھا جانا چاہیے۔ فائل کو خود ایک راز سمجھیں، کیونکہ اسے رکھنے والا کوئی بھی شخص اس کے ساتھ بنائے گئے ہر بیک اپ کو ڈکرپٹ (decrypt) کر سکتا ہے۔ بڑے سیٹ اپ کے لیے، PBS ایک ماسٹر کلید کو بھی سپورٹ کرتا ہے، جو proxmox-backup-client key create-master-key کے ساتھ تیار کردہ ایک RSA (Rivest Shamir Adleman) کلید کا جوڑا ہے، جہاں ہر بیک اپ اپنی انکرپشن کلید کو پبلک ہاف (public half) کے ساتھ انکرپٹ کر کے محفوظ کرتا ہے، جبکہ پرائیویٹ ہاف (private half) بحالی کے لیے آف لائن رہتا ہے۔

ڈیزائن کا ایک نتیجہ ایسا ہے جسے شروع کرنے کے بعد جاننے کے بجائے پہلے جان لینا بہتر ہے۔ انکرپٹڈ بیک اپس کے لیے، ٹکڑے کا ڈائجسٹ (chunk digest) سادہ متن کے مواد کو انکرپشن کلید کے ساتھ ملا کر شمار کیا جاتا ہے، لہذا مختلف کلیدوں کے تحت انکرپٹ کیے گئے دو ایک جیسے ٹکڑے مختلف ڈائجسٹ تیار کرتے ہیں اور کبھی بھی ایک دوسرے کے ساتھ ڈی ڈپلیکیٹ (deduplicate) نہیں ہوتے۔ کلید تبدیل کرنے کا مطلب ہے کہ اگلا بیک اپ سب کچھ دوبارہ اپ لوڈ کرے گا، اور پرانے ٹکڑے تب تک وہاں موجود رہیں گے جب تک کہ ان کے اسنیپ شاٹس کو ہٹا (prune) اور جمع نہ کر لیا جائے۔ پہلی اپ لوڈ سے پہلے انکرپشن کے بارے میں فیصلہ کر لیں۔

Prune marks اور garbage collection کی بازیابی

یہ وہ سیکشن ہے جسے نظر انداز کر دیا جاتا ہے، اور یہی وہ وجہ ہے جس سے volume بھر جاتا ہے۔ Snapshot کو prune کرنے سے اس کا metadata ہٹ جاتا ہے: یعنی manifest، indexes، log اور notes۔ یہ کسی بھی chunk کو حذف نہیں کرتا۔ Chunks کو snapshots کے درمیان شیئر کیا جاتا ہے، اس لیے جب تک تمام باقی ماندہ indexes کو پڑھ نہ لیا جائے، یہ معلوم نہیں ہو سکتا کہ کوئی chunk غیر استعمال شدہ ہے یا نہیں۔ Garbage collection وہ عمل ہے جو ان indexes کو پڑھتا ہے۔ ایک ایسا 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 کٹ آف (cutoff) سے پرانا ہو، جو کہ رن شروع ہونے سے 24 گھنٹے اور 5 منٹ پہلے کا وقت ہے، یا پھر سب سے پرانے جاری بیک اپ کا آغاز، جو بھی پہلے ہو۔ یہ مارجن اس لیے موجود ہے کیونکہ Linux فائل سسٹمز کو بائی ڈیفالٹ relatime کے ساتھ ماؤنٹ کرتا ہے، جو ہر ریڈ (read) کے بجائے دن میں تقریباً ایک بار access time کو اپ ڈیٹ کرتا ہے۔ لہذا ایک گھنٹہ پہلے لکھا گیا chunk کبھی حذف نہیں ہوتا، چاہے فی الحال کوئی بھی اس کا حوالہ نہ دے رہا ہو، اور prune سے خالی ہونے والی جگہ اس پہلی collection کے بعد ظاہر ہوتی ہے جو chunk کے آخری بار ٹچ ہونے کے ایک دن بعد چلتی ہے۔ ایک datastore جس میں ایسا لگے کہ کچھ بھی بازیاب نہیں ہوا، وہ اکثر اسی ونڈو کے اندر ہوتا ہے۔

ایک چھوٹے VPS پر یہ سب سے بھاری جاب ہوتی ہے، کیونکہ یہ volume پر موجود ہر chunk فائل کا اسٹیٹ (stat) لیتا ہے۔ ٹاسک لاگ اس خلاصے کے ساتھ ختم ہوتا ہے کہ کیا حذف کیا گیا اور کیا grace period کی وجہ سے ابھی باقی ہے۔ اگر بہت کچھ باقی ہے، تو اسے اگلے دن دوبارہ چلائیں۔ PBS datastore کو ٹیون کرنے کے لیے gc-atime-safety-check اور gc-atime-cutoff کے آپشنز دیتا ہے، اور دونوں کو اپنی حالت پر چھوڑ دینا چاہیے: یہ ان اسٹوریج کے لیے موجود ہیں جو access times کو ریکارڈ نہیں کر سکتے، اور noatime ماؤنٹ شدہ فائل سسٹم پر حفاظتی چیک کو بند کرنے کا مطلب ان chunks کو کھونا ہے جن کا حوالہ لائیو snapshots دے رہے ہوتے ہیں۔

تصدیق یہ ثابت کرتی ہے کہ چنکس اب بھی قابلِ مطالعہ ہیں

ایک بیک اپ جو کامیابی سے اپ لوڈ ہوا ہو، ایک سال بعد ناقابلِ مطالعہ ہو سکتا ہے۔ تصدیق (Verification) چنکس کو دوبارہ پڑھتی ہے اور ان کا موازنہ ان چیک سمز (checksums) سے کرتی ہے جو انڈیکس میں محفوظ ہوتے ہیں، تاکہ خرابی کا پتہ بحالی (restore) کے وقت کے بجائے ایک شیڈول کے مطابق چل سکے۔

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

ایک چھوٹے VPS پر تھریڈز کی تعداد کم رکھیں۔ تصدیق کا عمل ڈسک اور CPU کی صلاحیت تک محدود ہوتا ہے، اور بصورتِ دیگر یہ سرور پر چلنے والے دیگر کاموں کے ساتھ وسائل کے لیے مقابلہ کرے گا۔ شیڈول کے لیے، ویب انٹرفیس میں datastore کے Verify Jobs ٹیب کا استعمال کریں: ایک ہفتہ وار جاب جو پہلے سے تصدیق شدہ اسنیپ شاٹس کو چھوڑ دے اور 30 دن سے پرانے کسی بھی ڈیٹا کو دوبارہ تصدیق کرے، یہ کام دہرائے بغیر پورے اسٹور کا احاطہ کر لیتی ہے۔

جو اسنیپ شاٹ تصدیق میں ناکام ہو جائے اسے datastore کے منظر میں ناکام (failed) کے طور پر نشان زد کیا جاتا ہے۔ اسے نظر انداز نہ کریں۔ چنکس مشترک ہوتے ہیں، اس لیے ایک بنیادی امیج کا ایک خراب چنک عام طور پر ہر اس اسنیپ شاٹ کو ناکام بنا دیتا ہے جو اس کا حوالہ دیتا ہے۔ اس کی مرمت کا طریقہ یہ ہے کہ ناکام اسنیپ شاٹس کو حذف (forget) کر دیں اور ایک نیا بیک اپ چلائیں، جو گمشدہ چنکس کو دوبارہ اپ لوڈ کر دے گا۔ اگر ناکامیاں مسلسل ظاہر ہوتی رہیں، تو datastore کے نیچے موجود اسٹوریج پر شک کریں، اور VPS پر ڈسک ہیلتھ مانیٹرنگ سیٹ اپ کریں تاکہ ڈرائیو آپ کو verify جاب سے پہلے ہی مطلع کر دے۔

ایک ریسٹور کا ٹیسٹ کریں، پھر اسے کلسٹر کے بغیر ٹیسٹ کریں

آپ کو اس وقت تک معلوم نہیں ہوتا کہ بیک اپ کام کر رہا ہے جب تک آپ اسے ریسٹور نہ کر لیں۔ دو ٹیسٹ کریں، اور یہ مختلف چیزوں کی جانچ کرتے ہیں۔

مکمل گیسٹ، کلسٹر پر:

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

pvesm list کا پہلا کالم والیوم 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 نے پرنٹ کیا تھا۔ یہ وہ ثابت کرتا ہے جو پہلا ٹیسٹ نہیں کر سکتا: کہ آپ کی کی فائل (key file) اصلی ڈیٹا کو ڈکرپٹ (decrypt) کرتی ہے، اور یہ کہ آپ کلائنٹ کو ایسی مشین سے چلا سکتے ہیں جس میں کبھی آپ کے کلسٹر کی کنفیگریشن نہیں تھی۔ ان چار اقدار کو لکھ لیں جن کی ضرورت تھی، ریپوزٹری اسٹرنگ، ٹوکن سیکرٹ، فنگر پرنٹ اور کی فائل، اور انہیں اس جگہ محفوظ رکھیں جہاں آپ کا ڈیزاسٹر پلان (disaster plan) نشاندہی کرتا ہے۔

Deduplication آپ کے ڈسک بل پر کیا اثر ڈالتی ہے اور کیا نہیں

Deduplication ایک حقیقت ہے، اور یہ پورے datastore پر کام کرتی ہے۔ دس Debian گیسٹس اپنے درمیان base system کی ایک ہی کاپی شیئر کرتے ہیں، لہذا دوسرے ایک جیسے گیسٹ کو اسٹور کرنے پر تقریباً کوئی خرچ نہیں آتا۔ یہ اپ لوڈ بینڈوڈتھ کی بھی بچت کرتی ہے، کیونکہ کلائنٹ کسی بھی ایسے chunk کے لیے ڈیٹا کے بجائے checksum بھیجتا ہے جو سرور کے پاس پہلے سے موجود ہو۔

یہ کیا نہیں کرتی، اس بارے میں واضح ہونا ضروری ہے۔

• یہ تبدیل ہونے والے ڈیٹا کو چھوٹا نہیں کرتی۔ ایک ڈیٹا بیس جو ہر رات اپنی فائلوں کے بڑے حصے دوبارہ لکھتا ہے، ہر رات نئے chunks پیدا کرتا ہے، اور retention انہیں ضرب دے دیتی ہے۔
• یہ encryption key کی حدود سے باہر کام نہیں کرتی، جیسا کہ اوپر بیان کیا گیا ہے۔
• یہ datastore کی حدود سے باہر کام نہیں کرتی، جو کہ namespaces کے لیے بنیادی دلیل ہے۔
• یہ کسی volume کو بھرنے سے نہیں روکتی۔ جب datastore بھر جاتا ہے، تو بیک اپ ناکام ہو جاتے ہیں، اور واحد حل ایک بڑا volume یا مختصر retention ہے۔

اس کے نیچے deduplication کی کوئی اور تہہ (layer) نہ لگائیں۔ Chunks کلائنٹ کی طرف سے پہلے ہی deduplicate اور compress ہو کر آتے ہیں، اس لیے datastore کے نیچے ZFS deduplication ایسی مماثلتیں تلاش کرنے میں RAM ضائع کرتی ہے جنہیں لکھے جانے سے پہلے ہی ہٹا دیا گیا تھا۔ یہاں volume پر سادہ ext4 یا xfs کا استعمال درست انتخاب ہے۔

ویب انٹرفیس datastore کے لیے ایک deduplication factor رپورٹ کرتا ہے۔ یہ نمبر آپ کے گیسٹس کی عکاسی کرتا ہے، اور منصوبہ بندی کے لیے صرف یہی قابلِ غور ہے، کیونکہ شائع شدہ تناسب کسی اور کے ڈیٹا کے بارے میں ہوتے ہیں۔ اگر آپ کو ایسی مشینوں کے file-level بیک اپ کی بھی ضرورت ہے جو Proxmox گیسٹس نہیں ہیں، تو انہیں اسی VPS پر ساتھ چلائیں: PBS مکمل گیسٹس کے لیے ایک hypervisor-aware ہدف ہے، جبکہ restic and BorgBackup ڈائریکٹریز کی طرف اشارہ کرتے ہیں، اور restic backups to a VPS ان لیپ ٹاپس اور اسٹینڈ الون سرورز کے لیے موزوں ہیں جنہیں کور کرنا PBS کا مقصد کبھی نہیں تھا۔

ناکام ہونے کے طریقے اور آپ کو کیا نظر آئے گا

اسٹوریج غیر فعال (inactive) دکھائی دیتی ہے۔ جب نوڈ port 8007 پر TLS سیشن مکمل نہیں کر پاتا تو pvesm status --storage pbs-offsite، inactive پرنٹ کرتا ہے۔ VPS پر firewall چیک کریں، پھر فراہم کنندہ (provider) کی علیحدہ نیٹ ورک firewall، اور آخر میں fingerprint دیکھیں۔ اگر fingerprint سرٹیفکیٹ سے میل نہیں کھاتا تو یہ بالکل اسی طرح ناکام ہوتا ہے جیسے کوئی port بلاک ہو، اور جب بھی سرٹیفکیٹ تبدیل ہوتا ہے تو یہ بھی بدل جاتا ہے۔

پہلا بیک اپ اجازت ناموں (permissions) کی وجہ سے ناکام ہو جاتا ہے۔ رسائی کنٹرول انٹری (access control entry) میں صارف کے بجائے ٹوکن کا نام ہونا چاہیے، اور اسے اس namespace کا احاطہ کرنا چاہیے جس کی طرف اسٹوریج اشارہ کر رہی ہے۔ کہیں اور دیکھنے سے پہلے ویب انٹرفیس میں datastore کے permissions ٹیب پر دونوں کی تصدیق کریں۔

گاربیج کلیکشن (garbage collection) شروع ہونے سے انکار کر دیتی ہے۔ رسائی کے وقت کی حفاظتی جانچ (access time safety check) ناکام ہو گئی ہے، جس کا مطلب تقریباً ہمیشہ یہ ہوتا ہے کہ datastore کا فائل سسٹم noatime ماؤنٹ ہوا ہے۔ تصدیق کے لیے findmnt -no OPTIONS /mnt/datastore/store1 چلائیں، /etc/fstab میں آپشن کو درست کریں، اور دوبارہ ماؤنٹ کریں۔ اس سے بچنے کے لیے چیک کو غیر فعال نہ کریں۔

datastore صرف بڑھتا ہی جاتا ہے۔ پرن (prune) جابز چلتی ہیں لیکن کچھ بھی ریکلیم (reclaim) نہیں ہوتا۔ یا تو گاربیج کلیکشن کا کوئی شیڈول نہیں ہے، یا پھر ہر کلیکشن 24 گھنٹے کی گریس ونڈو کے اندر آتی ہے کیونکہ یہ بیک اپ کے فوراً بعد چلتی ہے۔ proxmox-backup-manager datastore show store1 کے ساتھ شیڈول چیک کریں۔

جو بیک اپ پہلے تیز ہوتا تھا اب گھنٹوں لیتا ہے۔ کوئی گیسٹ جو رک گیا ہو، منتقل (migrate) ہوا ہو یا بحال (restore) ہوا ہو، وہ اپنا dirty bitmap کھو دیتا ہے، اس لیے اگلی بار کلستر کی جانب سے پوری ڈسک پڑھی جاتی ہے حالانکہ اپ لوڈ بہت کم ہوتا ہے۔ ٹاسک لاگ میں طویل دورانیہ اور چھوٹا اپ لوڈ فگر نظر آتا ہے، اور اگلی بار یہ دوبارہ تیز ہو جاتا ہے۔ اگر VPS پر ہر جاب سست ہے، تو اس کی وجہ عام طور پر datastore سے باہر ہوتی ہے، اور شور مچانے والے پڑوسی سے CPU steal time پیمائش کرنے کے لیے پہلی چیز ہے۔

FAQ

جب prune job چلتا ہے تو میرا Proxmox Backup Server datastore کیوں بڑھتا رہتا ہے؟

کیونکہ pruning صرف snapshot metadata کو ہٹاتا ہے: یعنی manifest، indexes، log اور نوٹس۔ Chunks ڈسک پر تب تک رہتے ہیں جب تک garbage collection ان chunks کو حذف نہ کر دے جنہیں اب کوئی انڈیکس ریفرنس نہیں کرتا۔ Datastore کے لیے proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27' کے ساتھ ایک شیڈول ترتیب دیں، اور datastore پاتھ پر proxmox-backup-manager garbage-collection start store1 چلانے سے پہلے اور بعد میں df -h چلا کر اس کی تصدیق کریں۔ کم از کم ایک دن کے وقفے کی توقع رکھیں، کیونکہ فیز ٹو صرف ان chunks کو ہٹاتا ہے جن کا access time 24 گھنٹے اور 5 منٹ سے زیادہ پرانا ہو۔

Proxmox Backup Server VPS کو کتنی ڈسک کی ضرورت ہوتی ہے؟

ہر گیسٹ (guest) کے اصل استعمال شدہ ڈیٹا کو جمع کریں، پھر ہر گیسٹ کے روزانہ کے تبدیلی کے ڈیٹا کو ان دنوں کی تعداد سے ضرب دیں جتنے دن آپ بیک اپ رکھنا چاہتے ہیں۔ یہ کل حجم ایک حد (ceiling) ہے، کیونکہ compression اور deduplication دونوں آپ کے حق میں کام کرتے ہیں۔ انڈیکسز اور ورکنگ اسپیس کے لیے تقریباً پانچواں حصہ مزید شامل کریں، پھر اسے خریدے جا سکنے والے والیوم سائز تک راؤنڈ اپ کر لیں۔ دو ہفتوں بعد datastore ویو میں اصل استعمال کے مطابق دوبارہ چیک کریں، کیونکہ پہلے بیک اپ سے پہلے لگایا گیا اندازہ ہمیشہ کسی نہ کسی سمت میں غلط ہوتا ہے۔

بیک اپ انکرپشن کی (encryption key) کہاں محفوظ ہونی چاہیے؟

اس کلسٹر کے علاوہ کہیں بھی جسے یہ محفوظ کرتی ہے۔ Proxmox VE اسے /etc/pve/priv/storage/<storage>.enc پر رکھتا ہے، جو ہر نوڈ پر ریپلیکیٹ ہوتا ہے اور اس لیے کلسٹر کے ساتھ ہی ضائع ہو جاتا ہے۔ پہلے دن ہی اس کی کاپی نکالیں، اسے proxmox-backup-client key paperkey کے ساتھ پرنٹ کریں، اور اس کاپی کو کسی دوسری عمارت میں رکھیں۔ یہ بھی نوٹ کریں کہ یہ کی (key) chunk digest کا حصہ بنتی ہے، لہذا اسے بعد میں تبدیل کرنے کا مطلب ہے کہ اگلا بیک اپ سب کچھ دوبارہ اپ لوڈ کرے گا۔

کیا مجھے ہر Proxmox ہوسٹ کے لیے ایک datastore چاہیے، یا namespaces؟

ہر سورس ہوسٹ یا کلسٹر کے لیے ایک datastore اور ایک namespace کافی ہے۔ Deduplication ایک datastore کے اندر کام کرتی ہے، نہ کہ مختلف datastores کے درمیان، اس لیے ہوسٹ کے لحاظ سے تقسیم کرنے سے ایک ہی بیس امیجز کئی بار اسٹور ہو جاتی ہیں۔ Namespaces بیک اپ گروپس کو الگ رکھتی ہیں، تاکہ دو ہوسٹس جن میں 100 ID والا گیسٹ موجود ہو، آپس میں نہ ٹکرائیں، اور /datastore/store1/pve-home کی شکل میں access control پاتھ ہر ہوسٹ کے API ٹوکن کو صرف اس کے اپنے namespace تک محدود رکھتا ہے۔

کیا ایک چھوٹا VPS بطور Proxmox بیک اپ سرور کام کر سکتا ہے؟

عام طور پر، ہوم لیب کے لیے ایسا ممکن ہے، کیونکہ chunking اور hashing کا عمل Proxmox VE نوڈ پر ہوتا ہے نہ کہ بیک اپ سرور پر۔ VPS صرف chunks لکھتا ہے اور دو بھاری کام، یعنی garbage collection اور verification انجام دیتا ہے۔ اسے 4 GB RAM دیں اور verification تھریڈز کی تعداد کم رکھیں۔ دونوں کاموں کو بیک اپ ونڈو کے باہر شیڈول کریں، اور اگر پھر بھی انہیں ڈسک کی صلاحیت سے کہیں زیادہ وقت لگے، تو بڑا پلان خریدنے سے پہلے steal time کی پیمائش کریں۔