VPS کو off-site backup target کے طور پر استعمال کریں

اصل off-site backup target کیا ہوتا ہے

off-site backup target ایک دوسری مشین ہوتی ہے جو آپ کے ڈیٹا کی نقل محفوظ رکھتی ہے اور اصل مشین سے آزادانہ طور پر ناکام ہو سکتی ہے۔ کسی دوسرے provider کا VPS زیادہ تر قارئین کے لیے دستیاب کم ترین لاگت والا انتخاب ہوتا ہے۔ عملی طور پر 3 صورتیں عام ہیں: VPS پر Proxmox Backup Server چلانا، SSH یا S3 کے ذریعے حاصل کیے جانے والے restic repository کا استعمال، یا ایسا rsync mirror جسے backup host خود pull کرے۔ مناسب انتخاب اس بات پر منحصر ہے کہ آپ کیا restore کرنا چاہتے ہیں اور اسے کتنی تیزی سے واپس دستیاب کرنا ضروری ہے۔ باقی فیصلے اس امر سے طے ہوتے ہیں کہ copy کو delete کرنے کی اجازت کس کے پاس ہے۔

off-site کا مطلب مختلف failure domain ہے۔ اس کے لیے مختلف provider اور ایسا account درکار ہے جس کا login آپ کا server چلانے والے account سے مشترک نہ ہو۔ اسی provider کے دوسرے region میں موجود دوسرا server ایک عمارت میں لگنے والی آگ سے محفوظ رہ سکتا ہے۔ لیکن اگر control panel کا login compromised ہو جائے تو یہ دونوں copies محفوظ نہیں رہتیں، کیونکہ ایک ہی account دونوں کو control کرتا ہے۔

آپ کے provider کا snapshot اس دوسری copy کا متبادل نہیں ہے۔ وہ اسی panel password کے پیچھے موجود ہوتا ہے، اس لیے جس شخص کو وہ password مل جائے وہ ایک ہی session میں server اور اس کے snapshots دونوں delete کر سکتا ہے۔ Snapshot services فی gigabyte فی ماہ چارج بھی لیتی ہیں، اور ان کی شرح عام disk سے کہیں زیادہ ہوتی ہے۔ اس لیے 90 دن تک snapshots محفوظ رکھنا مہنگا پڑتا ہے۔ VPS snapshots اور backups کے درمیان فرق پر انحصار کرنے سے پہلے اسے پڑھنا مفید ہے۔

آپ کے لیے تین شکلوں میں سے کون سی مناسب ہے

• Proxmox Backup Server (PBS): ماخذ Proxmox VE (virtual environment) ہوتا ہے، اور آپ پوری virtual machine بحال کرتے ہیں۔ یہ disk-image سطح پر backup لیتا ہے، جبکہ اس کے verify jobs target پر موجود data کو دوبارہ پڑھتے ہیں۔
• restic repository: ماخذ ایک یا متعدد Linux hosts ہوتے ہیں، اور آپ directory یا database dump بحال کرتے ہیں۔ یہ client پر encryption کرتا ہے، اور SSH، S3، نیز اپنے REST protocol کے ذریعے کام کرتا ہے۔
• rsync over SSH، جسے backup host pull کرتا ہے: آپ target پر files کو ordinary files کی صورت میں رکھنا چاہتے ہیں، جنہیں ls اور cat کے ذریعے پڑھا جا سکے، اور انہیں واپس حاصل کرنے کے لیے client software کی ضرورت نہ ہو۔

اگر فیصلہ نہ کر سکیں تو restic استعمال کریں۔ یہ machine سے کوئی بھی data باہر جانے سے پہلے اسے encrypt کرتا ہے، اور target پر SSH account اور disk کے علاوہ کسی چیز کی ضرورت نہیں ہوتی۔ VPS پر restic backups ترتیب دینا client side کو مزید تفصیل سے بیان کرتا ہے، جبکہ restic اور BorgBackup کا بالمقابل جائزہ اس صورت میں انتخاب واضح کرتا ہے جب آپ پہلے ہی Borg چلا رہے ہوں۔

ہدف کا حجم مقرر کرنا: ایک ماہ کی retention کی لاگت

Deduplication کی وجہ سے یہ اعداد توقع سے کم ہوتے ہیں۔ restic اور PBS دونوں فائلوں کو متغیر حجم کے chunks میں تقسیم کرتے ہیں اور ہر chunk کا hash بناتے ہیں۔ ہر منفرد chunk صرف ایک بار محفوظ ہوتا ہے۔ 500 GB کے dataset کا دوسرا backup مزید 500 GB شامل نہیں کرتا۔ اس میں صرف تبدیل ہونے والے chunks شامل ہوتے ہیں۔

اس لیے repository کا حجم snapshots کی تعداد کے بجائے قدیم ترین snapshot کی عمر کے مطابق بڑھتا ہے۔ فرض کریں کہ 500 GB کا data ہے اور روزانہ 5 GB نیا منفرد data شامل ہوتا ہے۔ اس صورت میں repository میں 500 GB کا base موجود ہوگا، اس کے علاوہ policy میں برقرار رکھے گئے قدیم ترین snapshot تک ہر دن کے لیے تقریباً 5 GB شامل ہوگا۔

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Dollar والا کالم اس repository کی قیمت 10 US dollars فی TB فی ماہ کے حساب سے ظاہر کرتا ہے۔ یہ صرف حساب سمجھانے کے لیے placeholder ہے، کسی provider کی پیش کردہ قیمت نہیں۔ اس لیے جس plan پر آپ غور کر رہے ہیں، اس کی اصل فی TB قیمت استعمال کریں۔ روزانہ backups کی ایک ہفتے کی مدت میں تقریباً 535 GB محفوظ ہوں گے۔ پورے سال کی history میں 2,325 GB محفوظ ہوں گے، جس کی ماہانہ قیمت $23.25 بنتی ہے، جبکہ ایک ہفتے کے لیے یہ قیمت $5.35 ہے۔ History سستی ہے۔ اصل لاگت base copy کی ہے۔

Deduplication پہلے سے compressed یا encrypted شکل میں آنے والے data پر مؤثر نہیں ہوتی۔ ایک gzipped database dump ہر run میں مکمل طور پر بدل جاتا ہے، اس لیے ہر dump نئے chunks کے طور پر محفوظ ہوتا ہے اور repository ہر رات ایک مکمل dump کے حجم کے برابر بڑھتی ہے۔ Dump کو uncompressed لکھیں اور backup tool کو اسے compress کرنے دیں، کیونکہ restic نے 0.14 سے compressed repositories کو support کیا ہے، اور version 0.19 نے fastest اور better zstd modes شامل کیے ہیں۔ Photo اور video libraries بھی اسی وجہ سے کم deduplicate ہوتی ہیں۔ اس لیے ان کا حجم اوپر دیے گئے rows کے بجائے ان کی حقیقی growth rate کی بنیاد پر مقرر کریں۔

یہاں آپ CPU کے بجائے idle disk خرید رہے ہیں، اور یہی وہ صورت ہے جس میں storage VPS عام VPS سے بہتر ہوتا ہے۔

بینڈوڈتھ اور بحالی کا وقت منصوبہ کیوں طے کرتے ہیں

ڈسک سستا حصہ ہے۔ پہلی اپ لوڈ اور بعد کی بحالی مہنگے مراحل ہیں۔ 500 GB میں 4 ٹریلین bits ہوتے ہیں، اس لیے اسے link speed سے تقسیم کرنے پر معلوم ہوتا ہے کہ مکمل بحالی میں کم از کم کتنا وقت لگ سکتا ہے۔

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

یہ اعداد protocol overhead کے بغیر line-rate پر مبنی ہیں، اس لیے انہیں بہترین ممکنہ صورت سمجھیں۔ 100 Mbit/s پر مکمل بحالی کے لیے کسی بھی data پر کام شروع کرنے سے پہلے 11.1 گھنٹے درکار ہیں۔ 40 Mbit/s کے home upload پر اس کے لیے 27.8 گھنٹے درکار ہیں۔ 1 Gbit/s port پر یہی بحالی 1.1 گھنٹے لیتی ہے۔ بہت سی چھوٹی files کی رفتار حسابی اندازے سے کم ہوتی ہے، کیونکہ files کا سائز چند سو kilobytes سے کم ہونے پر فی file overhead غالب آ جاتا ہے۔

اس سے دو باتیں واضح ہوتی ہیں۔ اگر آپ کا recovery time objective (RTO)، یعنی وہ outage جسے آپ برداشت کر سکتے ہیں، چار گھنٹے ہے، تو 100 Mbit/s link پر 500 GB کی بحالی پہلے ہی اس حد سے باہر ہے؛ سستی disk اس مسئلے کو حل نہیں کرتی۔ زیادہ تر VPS plans outbound transfer کی پیمائش کرتے ہیں، اس لیے ایک مکمل بحالی backup host کے ماہانہ allowance میں سے 0.5 TB استعمال کر دیتی ہے۔ Data درکار ہونے سے پہلے یہ allowance چیک کریں، اور یہ بھی معلوم کریں کہ اس حد سے تجاوز کرنے پر provider کیا کرتا ہے۔

پہلا backup پورا dataset ہوتا ہے اور یہی سب سے سست run ہوتا ہے۔ اسے جمعہ کو شروع کریں، اور rate-limit لگائیں تاکہ source کا uplink مکمل طور پر مصروف نہ ہو: restic --limit-upload KiB فی second لیتا ہے، جبکہ rsync --bwlimit لیتا ہے۔

شکل 1: Proxmox Backup Server بطور remote datastore

PBS اس وقت موزوں ہے جب source، Proxmox VE ہو اور restore کی unit، virtual machine ہو۔ VPS، Proxmox ISO سے boot نہیں ہو سکتا، اس لیے Debian کے اوپر PBS install کریں۔ August 2026 تک Version 4.2 موجودہ version ہے اور Debian 13 (trixie) پر مبنی ہے۔

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

اس checksum کا موازنہ Proxmox package repositories page پر شائع کردہ value سے کریں۔ apt repository صرف اتنی ہی قابلِ اعتماد ہوتی ہے جتنی وہ key جس کی آپ نے تصدیق کی ہو۔ پھر /etc/apt/sources.list.d/proxmox.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
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Datastore کے لیے اپنا filesystem یا اپنا volume مختص کریں۔ مکمل بھر جانے والا datastore backups روک دیتا ہے، جبکہ root filesystem کے ساتھ shared datastore بھرنے پر پورا server بند ہو جاتا ہے۔

اگلا مرحلہ وہ account بنانا ہے جسے source استعمال کرے گا، اور اسے password کے بجائے token دینا ہے۔

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Token secret صرف ایک بار دکھائی دیتا ہے اور بعد میں دوبارہ نہیں پڑھا جا سکتا، اس لیے ظاہر ہوتے ہی اسے محفوظ کریں۔ Role بھی token جتنا ہی اہم ہے۔ DatastoreBackup اپنے backups create اور restore کر سکتا ہے، اور اس کے پاس Datastore.Prune privilege نہیں ہوتا، اس لیے یہ token اپنے لکھے ہوئے snapshot کو delete نہیں کر سکتا۔

PBS میں retention کے دو حصے ہیں، اور لوگ دوسرے حصے کو اکثر چھوڑ دیتے ہیں۔ Prune snapshots کو remove کرتا ہے۔ Garbage collection ان chunks کو remove کرتا ہے جن کا حوالہ کسی باقی رہنے والے snapshot میں موجود نہ ہو۔ Free space، prune کے بعد نہیں بلکہ garbage collection کے بعد ظاہر ہوتی ہے۔

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

جب remove کیے جانے والے snapshots کی فہرست درست معلوم ہو تو --dry-run چلائیں۔ Garbage collection دو phases میں چلتا ہے: پہلے یہ ہر اس chunk کا access time update کرتا ہے جس کا حوالہ اب بھی موجود ہو، پھر ان chunks کو delete کرتا ہے جن کا access time cutoff سے پرانا ہو۔ یہ cutoff run شروع ہونے سے 24 hours اور 5 minutes پہلے کا وقت ہوتا ہے۔ یہ grace period اس لیے موجود ہے تاکہ جاری backup کے ذریعے لکھے جانے والا chunk دورانِ عمل delete نہ ہو جائے۔ Datastore پر prune کو روزانہ اور garbage collection کو ہفتہ وار schedule کریں، اور ایک verify job بھی شامل کریں تاکہ target اپنے chunks دوبارہ پڑھے اور restore سے پہلے disk پر موجود corruption کی اطلاع دے۔

اگر source خود PBS instance ہو تو off-site box، push کیے جانے کے بجائے pull کر سکتا ہے۔

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

اس sync job کو VPS پر default pull direction میں چلائیں۔ VPS، home datastore تک رسائی حاصل کرتا ہے، جس کا مطلب ہے کہ home box پر ایسا کوئی credential موجود نہیں رہتا جو off-site copy کو متاثر کر سکے۔

شکل 2: SSH یا S3 پر restic repository

Debian اور Ubuntu دونوں restic کو package کرتے ہیں، لیکن دونوں upstream سے پیچھے ہیں۔ August 2026 تک موجودہ version 0.19.1 ہے۔ source host پر official binary install کریں۔

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version version اور وہ Go compiler دکھاتا ہے جس سے یہ build کیا گیا تھا۔ بعد کی upgrades کے لیے sudo restic self-update استعمال کریں۔ یہ official binaries پر کام کرتا ہے، لیکن apt سے install کی گئی copy پر نہیں۔

backup VPS پر ایسا account بنائیں جس کی ملکیت میں کوئی دوسری چیز نہ ہو، پھر source host کی public key کو /home/resticsrv/.ssh/authorized_keys میں copy کریں۔

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

source سے SFTP کے ذریعے repository initialise کریں۔

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

اس password کو ایسی جگہ محفوظ کریں جو نہ یہ server ہو اور نہ backup target۔ اسے کھو دینے پر repository ناقابلِ مطالعہ ہو جائے گی، اور recovery کا کوئی راستہ نہیں ہوگا۔ client-side encryption کے ساتھ یہی ذمہ داری آپ پر آتی ہے۔

Retention ایک command سے ہوتی ہے، اور اس کا دوسرا حصہ disk خالی کرتا ہے۔

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget snapshots delete کرتا ہے۔ prune ان pack files کو delete کرتا ہے جن کا حوالہ صرف انہی snapshots میں تھا، اور --prune اسے خودکار طور پر چلاتا ہے جب واقعی کچھ حذف کیا گیا ہو۔ اس کے بغیر repository کبھی چھوٹی نہیں ہوتی۔ restic check repository structure کی تصدیق کرتا ہے، اور --read-data-subset=10% pack files کے دسویں حصے کو دوبارہ پڑھ کر re-hash کرتا ہے۔ اس سے ہر چیز پڑھنے کی لاگت کے بغیر target پر corruption کا پتا چل جاتا ہے۔ دوسری صورت، --read-data-subset=1/10، ہر بار ایک ہی مقررہ دسویں حصے کو check کرتی ہے۔ اس لیے ہر ہفتے پہلے number کو بڑھانے سے دس ہفتوں میں پوری repository cover ہو جاتی ہے۔

اگر کوئی run ختم کر دیا جائے تو اگلا run repository is already locked exclusively by PID کے ساتھ رک جاتا ہے۔ تصدیق کریں کہ کوئی backup نہیں چل رہا، پھر اسے restic unlock سے clear کریں۔

Object storage کے لیے repository string s3:https://s3.example.net/web1 بن جاتی ہے، جبکہ credentials AWS_ACCESS_KEY_ID اور AWS_SECRET_ACCESS_KEY میں ہوتے ہیں۔ باقی سب کچھ یکساں رہتا ہے۔ اسی طرح restic اسی VPS پر چلنے والے self-hosted MinIO object store سے بات کرتا ہے۔

شکل 3: pull-only key کے ساتھ SSH پر rsync

اس شکل کی security property سمت ہے۔ backup VPS source سے connect کرتا ہے اور data پڑھتا ہے۔ source پر کوئی key موجود نہیں ہوتی اور backup host تک کوئی route بھی نہیں ہوتا، اس لیے source کے breach ہونے کی صورت میں بھی backups تک رسائی ممکن نہیں رہتی۔

backup VPS پر key pair بنائیں، پھر forced command کے ساتھ اس کا public حصہ source پر install کریں۔

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync، Debian 13 اور Ubuntu 24.04 پر /usr/bin/rrsync میں rsync package کے ساتھ شامل ہوتا ہے۔ -ro صرف reading کی اجازت دیتا ہے اور -no-del کو بھی شامل کرتا ہے، اس لیے یہ key source پر کچھ لکھ یا delete نہیں کر سکتی۔ restrict ان SSH features کو بند کرتا ہے جن کی یہاں ضرورت نہیں، جن میں port forwarding اور pty شامل ہیں۔ اس لیے یہ key interactive login کے لیے استعمال نہیں ہو سکتی۔ اس کے بعد paths اس directory کے لحاظ سے relative ہوتے ہیں جس کا آپ نے نام دیا ہے۔ لہذا remote path /، source پر /srv کو ظاہر کرتا ہے۔

pull، hardlinks کے ذریعے history محفوظ رکھتا ہے۔ نئی tree میں unchanged files، پچھلی tree کے hardlinks ہوتی ہیں۔ اس لیے دوسری copy کے بجائے صرف ایک directory entry درکار ہوتی ہے۔

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

آخر میں کیا جانے والا rename dated directory کو قابلِ اعتماد بناتا ہے۔ نام صرف اس وقت ظاہر ہوتا ہے جب rsync کا exit status 0 ہو۔ اس لیے interrupted transfer مکمل snapshot کے طور پر ظاہر نہیں ہوتا۔ پرانی trees کو ایک ہی line سے expire کریں اور تیسریس رکھیں۔

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

اس شکل کی لاگت کے بارے میں حقیقت پسند رہیں۔ Hardlinks صرف مکمل files کو deduplicate کرتے ہیں۔ اس لیے 4 GB disk image کے اندر ایک byte تبدیل ہونے پر پورے 4 GB کی copy بنتی ہے، جبکہ restic اور PBS چند تبدیل شدہ chunks محفوظ کرتے ہیں۔ target پر آپ کی files plaintext میں بھی موجود ہوتی ہیں۔ لہذا backup VPS پر root رکھنے والا کوئی بھی شخص انہیں پڑھ سکتا ہے۔

کلائنٹ سائیڈ encryption، تاکہ target کو plaintext نظر نہ آئے

backup VPS کو ایسی مشین سمجھیں جس پر آپ کا مکمل کنٹرول نہیں ہے۔ اس کا ایک provider ہے، اور اس provider کے ایسے staff بھی ہیں جو عمارت سے باہر لے جانے والی ناکام disks تبدیل کرتے ہیں۔

restic ہر chunk کو source پر بھیجنے سے پہلے encrypt کرتا ہے۔ اس لیے repository میں ciphertext کے ساتھ sizes اور timing سے متعلق metadata رہتا ہے۔ PBS میں encryption opt-in ہوتی ہے: ایک key بنائیں، پھر ہر backup کے ساتھ اسے فراہم کریں۔

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

paper key کو print کریں اور اسے کسی محفوظ physical جگہ پر رکھیں۔ Proxmox کی documentation اس معاملے کی اہمیت واضح کرتی ہے: اس key کے بغیر backed up files تک رسائی ممکن نہیں رہتی۔ key کو backup target سے الگ رکھیں، کیونکہ ciphertext کے ساتھ رکھی ہوئی key کسی کو تحفظ نہیں دیتی۔

rsync mirrors میں اس کا کوئی متبادل موجود نہیں۔ files بطور files target پر پہنچتی ہیں۔ اگر data حساس ہے تو یا تو یہ قبول کریں کہ target اسے پڑھ سکتا ہے، یا باقی دو طریقوں میں سے کوئی ایک استعمال کریں۔

اپنے backups مٹانے والے breached source کو روکیں

جو attacker source پر قبضہ کر لیتا ہے، وہ اگلے مرحلے میں backups تلاش کرتا ہے، اور انہیں upload کرنے والی credential اسی machine پر موجود ہوتی ہے۔ اگر وہ credential backups delete بھی کر سکتی ہو تو attacker اسے استعمال کرے گا۔

PBS اس مسئلے کو roles کے ذریعے حل کرتا ہے۔ صرف DatastoreBackup رکھنے والا token نئے snapshots لکھ سکتا ہے اور اپنے snapshots restore کر سکتا ہے، لیکن وہ prune نہیں کر سکتا، کیونکہ کسی snapshot کو delete کرنے کے لیے الگ Datastore.Prune privilege درکار ہوتی ہے۔ Retention کو PBS کی طرف سے چلائیں، تاکہ source کے پاس ایسی credential کبھی نہ ہو جو کچھ delete کر سکے۔

SFTP کے ذریعے restic میں یہ تقسیم موجود نہیں ہے، کیونکہ repository میں لکھنے والی SSH key اس سے data delete بھی کر سکتی ہے۔ اس کا حل REST backend ہے۔ Backup VPS پر rest-server کو --append-only کے ساتھ چلائیں۔ اس سے نئے backups بنائے جا سکتے ہیں، لیکن موجودہ backups کو delete یا modify نہیں کیا جا سکتا۔ پھر client کو rest:https://backup.example.net:8000/web1 پر RESTIC_REST_USERNAME اور RESTIC_REST_PASSWORD استعمال کرتے ہوئے point کریں۔ Source سے کی گئی restic forget --prune ناکام ہو جائے گی، اور یہی مطلوبہ نتیجہ ہے۔ اس کے بعد retention دوسری machine سے اپنی الگ credential کے ذریعے چلائیں۔ restic manual append-only repositories پر count-based policies کے بجائے --keep-within کی بھی سفارش کرتا ہے، کیونکہ اگر attacker repository میں junk snapshots کی بڑی تعداد شامل کر دے تو وہ --keep-last window سے آپ کے حقیقی snapshots کو باہر کر سکتے ہیں۔

rsync اسی مسئلے کو pull کے ذریعے حل کرتا ہے، کیونکہ source کے پاس target کے لیے کوئی credential موجود نہیں ہوتی۔

تینوں صورتوں کے لیے ایک ہی اصول کافی ہے: backups delete کرنے والی credential ایسی machine پر ہونی چاہیے جو backup کیے جانے والے system سے الگ ہو۔

بحالی کی مشق کیلنڈر میں درج کریں

جس backup کو آپ نے کبھی restore نہیں کیا، وہ صرف ایک مفروضہ ہے۔ ہر سہ ماہی میں ایک گھنٹہ مقرر کریں اور اس کی جانچ کریں۔

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r کا کوئی output نہ دینا اس بات کی نشاندہی کرتا ہے کہ بحال کیا گیا tree فعال tree سے مطابقت رکھتا ہے۔ PBS میں یہی مشق proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/ ہے، اس کے علاوہ ایک scheduled verify job بھی چلتی ہے جو target پر chunks دوبارہ پڑھتی ہے اور checksum failures کی رپورٹ دیتی ہے۔

مشق سے صرف bytes کے درست ہونے کا ثبوت نہیں ملنا چاہیے، بلکہ اس سے زیادہ ثابت ہونا چاہیے۔

• restore کسی تیسرے machine سے کریں، source سے نہیں، کیونکہ source ہی وہ چیز ہے جس کے ختم ہونے کا آپ مفروضہ قائم کر رہے ہیں۔ اس کا مطلب ہے کہ repository password یا PBS key اس machine کے بغیر قابل رسائی ہونی چاہیے۔
• restore کا وقت ناپ کر درج کریں، پھر اسے اپنے اعلان کردہ RTO سے موازنہ کریں۔ اوپر دیا گیا chart transfer کی کم از کم مدت بتاتا ہے۔ حقیقی وقت میں decrypt کرنے اور disk پر لکھنے کا وقت بھی شامل ہوتا ہے، نیز یہ طے کرنے میں صرف ہونے والا وقت بھی کہ آپ کو کون سا snapshot درکار تھا۔
• کسی state والی چیز کو restore کریں، مثلاً database dump، جسے بعد میں scratch instance میں load کیا جائے۔ صرف اس بات سے کہ tar file extract ہو جاتی ہے، یہ ثابت نہیں ہوتا کہ application start ہو جاتی ہے۔

دنیا کی سب سے سستی disk بھی اس وقت تک بے فائدہ ہے جب تک آپ اس سے ایک بار restore نہ کر لیں۔

FAQ

کیا میرے VPS provider کا snapshot، off-site backup ہوتا ہے؟

نہیں۔ Provider snapshot اسی account میں، اسی panel login کے تحفظ میں، اور اسی invoice پر موجود ہوتا ہے جس پر اس server کی copy ہوتی ہے۔ جس شخص کو وہ login مل جائے، وہ ایک ہی session میں server اور اس کے تمام snapshots delete کر سکتا ہے۔ Snapshots کسی خطرناک upgrade سے پہلے فوری rollback کے لیے مفید ہیں، لیکن یہ دوسری location نہیں ہوتے۔ Off-site copy کسی مختلف account کے تحت، بہتر ہے کہ کسی مختلف provider پر، موجود ہوتی ہے؛ اس کے credentials source machine کے پاس نہیں ہونے چاہییں۔

ایک ماہ تک محفوظ رہنے والے backups کے لیے مجھے کتنی disk درکار ہے؟

اس کا اندازہ snapshots کی تعداد کے بجائے اپنے قدیم ترین snapshot کی عمر سے لگائیں۔ Deduplicating tool ہر unique chunk صرف ایک بار store کرتا ہے، اس لیے repository کا حجم تقریباً source کے حجم میں روزانہ بننے والے نئے unique data کو برقرار رکھنے کے دنوں کی تعداد سے ضرب دے کر حاصل ہوتا ہے۔ 500 GB data میں روزانہ 5 GB تبدیلی کے لیے، روزانہ بننے والے backups کا ایک ہفتہ تقریباً 535 GB ہوگا، جبکہ پورے سال کی history 2,325 GB ہوگی۔ اس کے علاوہ اضافی گنجائش رکھیں، کیونکہ مکمل disk کی صورت میں اگلا backup ناکام ہو جاتا ہے، اور restic's prune کو pack files دوبارہ ترتیب دینے کے لیے free space درکار ہوتی ہے، اس سے پہلے کہ وہ جگہ واپس دے سکے۔

کیا breached server اپنے off-site backups بھی delete کر سکتا ہے؟

ہاں، اگر آپ نے اس خطرے کے خلاف design نہ کیا ہو۔ عام SSH یا SFTP repository میں جو key data لکھ سکتی ہے، وہ اسے delete بھی کر سکتی ہے۔ Source کو ایسا credential دیں جو data remove نہ کر سکے: PBS API token جس کے پاس صرف DatastoreBackup role ہو اور جس میں Datastore.Prune privilege موجود نہ ہو، یا restic کو ایسے rest-server کے خلاف چلائیں جو --append-only کے ساتھ start کیا گیا ہو؛ یہ موجودہ backups کو delete یا modify کرنے سے انکار کرتا ہے۔ Pull design اس سے بھی زیادہ محفوظ ہے، کیونکہ اس صورت میں source کے پاس backup host کا کوئی credential نہیں ہوتا۔ Retention اس جانب سے چلائیں جو source نہیں ہے۔

کیا مجھے backup VPS پر Proxmox Backup Server یا restic چلانا چاہیے؟

Tool کا انتخاب اس unit کے مطابق کریں جسے آپ restore کرنا چاہتے ہیں۔ اگر source Proxmox VE ہے اور آپ پوری virtual machine واپس چاہتے ہیں تو PBS چلائیں، کیونکہ یہ disk-image level پر backup بناتا ہے اور ایک step میں VM restore کر دیتا ہے۔ اگر source Linux host ہے اور آپ files اور database dumps واپس چاہتے ہیں تو restic چلائیں؛ اسے target پر صرف SSH account درکار ہوتا ہے اور یہ data بھیجنے سے پہلے encrypt کرتا ہے۔ دونوں چلانا معمول کی بات ہے: hypervisor کے لیے PBS اور اس پر موجود نہ ہونے والے servers کے لیے restic۔

VPS backup سے restore میں کتنا وقت لگتا ہے؟

کم از کم وقت معلوم کرنے کے لیے data size کو link speed سے تقسیم کریں، پھر decryption اور writing کا وقت شامل کریں۔ 100 Mbit/s link پر 500 GB کو line rate پر منتقل کرنے میں 11.1 گھنٹے لگتے ہیں، جبکہ 1 Gbit/s port پر یہی restore 1.1 گھنٹے لیتا ہے۔ بہت سی چھوٹی files اس حساب سے کم رفتار سے منتقل ہوتی ہیں، کیونکہ ہر file کا الگ overhead ہوتا ہے۔ ایک حقیقی restore کا وقت ناپیں اور اسی measured number کو استعمال کریں، کیونکہ recovery plan صرف اسی عدد پر قابلِ اعتماد طور پر انحصار کر سکتا ہے۔