Restic یا BorgBackup: کس کو استعمال کریں؟

Restic بمقابلہ BorgBackup، ایک پیراگراف میں

Restic اور BorgBackup دونوں ایک ہی بنیادی کام کرتے ہیں: Linux server کے deduplicated، encrypted اور incremental backups بنانا۔ انتخاب کا فیصلہ کرنے والا فرق یہ ہے کہ backup کہاں محفوظ ہوتا ہے۔ Restic مقامی طور پر S3 اور دیگر object storage APIs استعمال کرتا ہے، اس لیے bucket ایک first-class target ہوتا ہے اور remote سرے پر کچھ بھی install کرنے کی ضرورت نہیں ہوتی۔ Borg کے لیے repository رکھنے والی machine پر borg program install ہونا ضروری ہے، کیونکہ Borg repository کسی filesystem یا API کے ذریعے نہیں بلکہ ایک process کے ذریعے فراہم کی جاتی ہے۔ اگر آپ کا target object storage ہے تو فیصلہ واضح ہے۔ اگر target دوسرا Linux box ہے جس کا انتظام آپ خود کرتے ہیں تو Borg قابلِ استعمال ہے اور اکثر زیادہ تیز ہوتا ہے۔

باقی تمام فرق نسبتاً معمولی ہیں۔ دونوں content-defined chunking کے ذریعے files کو تقسیم کرتے ہیں، اس لیے 200 MB تبدیل ہونے والی 40 GB directory تقریباً 200 MB upload کرتی ہے۔ دونوں client پر encryption کرتے ہیں۔ دونوں FUSE (filesystem in userspace) کے ذریعے snapshot mount کرتے ہیں، تاکہ آپ اس میں سے ایک file copy کر سکیں۔ July 2026 تک restic کا version 0.19.1 ہے، جبکہ Borg کی stable series 1.4 ہے اور موجودہ release 1.4.5 ہے۔ Borg 2.0 کئی سال سے beta میں ہے اور اب بھی صرف testing کے لیے نشان زد ہے، اس لیے آج 1.4 ہی deploy کریں۔

اصل فرق repository ماڈل میں ہے

restic repository فائلوں کی ایک directory ہوتی ہے: config، keys/، snapshots/، index/، اور data/، جن میں pack files موجود ہوتی ہیں۔ اسے پڑھنے کے لیے کسی اور چیز کی ضرورت نہیں ہوتی۔ اسی لیے restic اتنے زیادہ backends کے ساتھ کام کر سکتا ہے۔ جو بھی storage blobs کو upload، download، list اور delete کر سکتی ہو، وہ restic repository رکھ سکتی ہے۔ اسی طریقے سے ایک ہی binary local paths، SFTP، اپنے REST server، S3، Backblaze B2، Azure، Google Cloud Storage، اور rclone کے ذریعے دستیاب کسی بھی storage کو support کرتی ہے۔

Borg repository بھی disk پر فائلوں کی صورت میں ہوتی ہے، لیکن Borg اس سے کسی سادہ transport کے ذریعے براہ راست بات نہیں کرتا۔ remote repository کے لیے Borg SSH کے ذریعے دوسری طرف borg serve شروع کرتا ہے اور اس process کے ساتھ اپنا protocol استعمال کرتا ہے۔ server side اصل کام انجام دیتا ہے: وہ repository رکھتا ہے، transaction apply کرتا ہے، اور index سے متعلق سوالات کے جواب دیتا ہے۔ اسی وجہ سے Borg میں S3 backend نہیں ہے اور project نے اسے شامل بھی نہیں کیا۔ bucket کے اندر چلانے کے لیے کوئی process موجود نہیں ہوتا۔

صرف یہ design حقیقت ہی ذیل میں بیان کیے گئے زیادہ تر عملی فرق پیدا کرتی ہے۔

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Encryption: ان میں سے ایک کو بند کیا جا سکتا ہے

Restic ہمیشہ encrypted ہوتا ہے۔ اس میں unencrypted mode موجود نہیں ہے۔ restic init پاس ورڈ طلب کرتا ہے، scrypt کے ذریعے اس سے key اخذ کرتا ہے، اور اس کے بعد لکھی جانے والی ہر pack file encrypted اور authenticated ہوتی ہے۔ پاس ورڈ ضائع ہو جائے تو data بھی ضائع ہو جاتا ہے، کیونکہ design کے لحاظ سے recovery path موجود نہیں ہے۔

Borg میں repository بناتے وقت encryption کا انتخاب کیا جاتا ہے، اور یہ انتخاب مستقل ہوتا ہے۔ borg init --encryption=repokey encrypted key کو repository کے اندر محفوظ رکھتا ہے، اس لیے صرف passphrase سے restore کیا جا سکتا ہے۔ --encryption=keyfile key کو client پر ~/.config/borg/keys/ میں محفوظ رکھتا ہے، اس لیے پوری repository چرانے والے کے پاس بھی کچھ نہیں ہوتا۔ تاہم آپ کو اس key file کا الگ backup رکھنا ہوگا، ورنہ archives ناقابلِ مطالعہ ہو جائیں گے۔ ہر mode میں -blake2 variant بھی موجود ہے، جو HMAC-SHA256 کے بجائے BLAKE2b سے authentication کرتا ہے۔ SHA acceleration کے بغیر hardware پر یہ زیادہ تیز ہوتا ہے۔ --encryption=none بھی موجود ہے، اور جب repository آپ کی ملکیت والی encrypted disk پر ہو تو یہ ایک حقیقی انتخاب ہے۔

عملی اصول یہ ہے: عام server backup کے لیے repokey-blake2، جب repository ایسی جگہ ہو جس پر آپ کو مکمل اعتماد نہ ہو تو keyfile، اور rented machine پر کبھی بھی none استعمال نہ کریں۔

Compression، اور restic میں یہ سہولت دیر سے کیوں آئی

Borg نے ابتدا ہی سے compression فراہم کی ہے۔ اس کی default قدر lz4 ہے، جسے اس لیے منتخب کیا گیا ہے کہ یہ اتنی تیز ہے کہ اسے ہر جگہ فعال رکھا جا سکے۔ zstd میں 1 سے 22 تک levels قبول ہوتے ہیں اور default قدر 3 ہے۔ zlib اور lzma ان صورتوں کے لیے ہیں جہاں آپ وقت کے مقابلے میں bytes کم کرنے کو زیادہ اہمیت دیتے ہیں۔ auto ہر chunk پر ایک heuristic چلاتا ہے، تاکہ پہلے سے compressed data کو دوبارہ compress نہ کیا جائے۔

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

restic میں repository format 2 تک compression بالکل موجود نہیں تھی۔ اس کے لیے restic 0.14.0 یا اس کے بعد کا ورژن درکار ہے۔ نئی repository کے لیے اب format 2 default ہے، اور compression کو --compression کے ذریعے auto، off یا max values پر set کیا جاتا ہے۔ پرانی format 1 repository اس وقت تک uncompressed رہتی ہے جب تک آپ اسے migrate نہ کریں۔ لہذا اگر آپ کی restic repository 0.14 سے پہلے کی ہے اور آپ نے اسے کبھی migrate نہیں کیا، تو text، logs اور database dumps کے لیے اب بھی مکمل size ادا کر رہے ہیں۔

ریموٹ targets: S3 بمقابلہ SSH

یہیں عموماً انتخاب کیا جاتا ہے۔

Restic کو S3 تک رسائی کے لیے environment میں credentials درکار ہوتے ہیں، اور کہیں بھی کوئی اضافی سروس چلانے کی ضرورت نہیں ہوتی۔ یہی طریقہ اس bucket کے ساتھ بھی کام کرتا ہے جسے آپ خود host کرتے ہیں۔ یہ ایک عام امتزاج ہے: اپنے VPS پر S3 API کے لیے MinIO چلائیں اور restic کو اس کی طرف point کریں۔

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Borg کو remote repository تک رسائی کے لیے SSH اور دوسری جانب Borg کی installation درکار ہوتی ہے۔ دوسری جانب موجود version کا client کے ساتھ compatible ہونا بھی ضروری ہے۔ اگر دوسری جانب والا server آپ کے انتظام میں نہ ہو تو یہ اضافی پیچیدگی ہے۔ اگر وہ دوسرا server ہو جسے آپ پہلے سے administer کرتے ہیں تو یہ کوئی مسئلہ نہیں، اور اس سے ransomware کے خلاف دونوں tools میں دستیاب سب سے مضبوط control ملتا ہے: append-only SSH key۔ اس key کو borg serve چلانے کے لیے محدود کریں۔ اس طرح client archives شامل کر سکتا ہے، لیکن انہیں delete نہیں کر سکتا۔ لہذا compromised machine اپنی سابقہ history مٹا نہیں سکتی۔

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic میں اس کا equivalent صرف اسی وقت دستیاب ہوتا ہے جب آپ اس کا اپنا REST server چلائیں، جو append-only mode support کرتا ہے۔ سادہ S3 کے ساتھ یہی اثر bucket policy یا object lock سے حاصل ہوتا ہے۔ یہ provider کی ذمہ داری ہے، restic کی نہیں۔ Transport کو بھی مکمل طور پر محدود کریں، کیونکہ SSH کا حصہ کسی بھی دوسرے login کی طرح احتیاط کا تقاضا کرتا ہے: backup account پر restricted authorized_keys entry کے ساتھ صرف key والا SSH لاگو کریں۔

رفتار: ہر ڈیزائن کے عملی اثرات

کوئی بھی پروجیکٹ ایسا benchmark شائع نہیں کرتا جس پر آپ اپنے ڈیٹا کے لیے اعتماد کر سکیں، اس لیے mechanism کی بنیاد پر نتیجہ اخذ کریں۔

تاخیر والے network link پر Borg over SSH تیز ہوتا ہے، کیونکہ server side ذہین ہے۔ client ایک سوال بھیجتا ہے، remote borg serve process repository index سے اس کا جواب دیتا ہے، اور transaction ایک ہی مقام پر commit ہوتا ہے۔ Chunk lookups ہر چھوٹی file کے لیے network round trip میں تبدیل نہیں ہوتے۔

Object storage پر Restic کا کوئی server side نہیں ہوتا، اس لیے اسے HTTP کے ذریعے حاصل کی جانے والی index files اور pack files سے اپنا data model بنانا پڑتا ہے۔ Request count کو قابلِ انتظام رکھنے کے لیے یہ upload سے پہلے بہت سے چھوٹے chunks کو بڑی pack files میں شامل کرتا ہے، اور ~/.cache/restic میں local cache رکھتا ہے تاکہ اگلی run میں پورا index دوبارہ fetch نہ کرنا پڑے۔ یہ cache حذف کر دیں تو اگلا backup سست ہوگا، کیونکہ cache دوبارہ بنانا پڑے گا۔ Millions of small files والے high-latency link پر یہی صورتِ حال ہے جس میں اسی data پر Restic، Borg کے مقابلے میں سست محسوس ہوتا ہے۔

Local disk یا fast LAN پر یہ فرق بڑی حد تک ختم ہو جاتا ہے، اور دونوں tools کی رفتار بالآخر اس بات سے محدود ہوتی ہے کہ وہ source کو کتنی تیزی سے read اور hash کر سکتے ہیں۔

لاک کرنا اور متعدد مشینوں کا بیک اپ لینا

Borg 1.4 پوری کارروائی کے دوران repository پر exclusive lock رکھتا ہے۔ ایک ہی repository میں بیک وقت لکھنے والے دو clients کام نہیں کرتے: دوسرا client انتظار کرتا ہے، پھر lock timeout کے ساتھ ناکام ہو جاتا ہے۔ معاونت یافتہ طریقہ یہ ہے کہ ہر client کے لیے الگ repository استعمال کی جائے۔ اس کا مطلب یہ بھی ہے کہ deduplication صرف ایک مشین کی repository کے اندر ہوتی ہے، لہذا تقریباً یکساں دس servers ایک ہی base system کی دس copies محفوظ کرتے ہیں۔

Restic متعدد clients کو بیک وقت ایک ہی repository میں بیک اپ لینے کی اجازت دیتا ہے، کیونکہ بیک اپ shared lock لیتا ہے اور صرف maintenance کام، جیسے prune، exclusive lock لیتے ہیں۔ ایک ہی restic repository کی طرف اشارہ کرنے والے دس ملتے جلتے servers ایک دوسرے کے ڈیٹا کے خلاف deduplicate کرتے ہیں، اور عموماً دوسرا server بہت کم ڈیٹا محفوظ کرتا ہے۔ اس کی قیمت blast radius ہے: ایک password اور ایک repository میں سب کچھ موجود ہوتا ہے، اس لیے password ضائع ہونے پر تمام دس machines کا ڈیٹا ضائع ہو جاتا ہے۔

Retention: بھولنا اور prune، بمقابلہ prune اور compact

دونوں tools یہ فیصلہ کرنے کو کہ کیا برقرار رکھنا ہے، جگہ واپس لینے کے عمل سے الگ رکھتے ہیں، اور دونوں میں آپ کو دوسرا مرحلہ خود چلانا ہوتا ہے۔

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

دونوں tools میں مسئلہ ایک ہی ہے، اور اسے واضح طور پر بیان کرنا ضروری ہے۔ Borg میں، borg prune archives کو حذف کرتا ہے، لیکن خود سے disk space خالی نہیں کرتا۔ جگہ اس وقت واپس آتی ہے جب borg compact چلتا ہے۔ اس لیے ایسا cron job جو prune چلاتا ہے لیکن compact نہیں چلاتا، repository کو ہمیشہ بڑھاتا رہتا ہے، جبکہ archive list مختصر رہتی ہے۔ restic میں، forget کو --prune کے بغیر چلانے سے صرف snapshot references ختم ہوتے ہیں، اور data اس وقت تک موجود رہتا ہے جب تک prune نہ چلایا جائے۔

Pruning کے بعد restic check چلائیں۔ یہ repository structures کی تصدیق کرتا ہے اور بتاتا ہے کہ آیا کوئی چیز خراب ہے۔ یہ اس بات کا پتا restore کے دوران چلنے کے مقابلے میں کہیں پہلے دے دیتا ہے۔

بحالی، اور یہی واحد آزمائش ہے جو شمار ہوتی ہے

دونوں tools snapshot کو mount کرتے ہیں تاکہ آپ اسے browse کر سکیں۔ کسی ایک file کو واپس لانے کا یہ سب سے تیز طریقہ ہے۔

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

borg extract میں path کی شکل نوٹ کریں۔ Archive کے اندر paths ابتدائی slash کے بغیر محفوظ ہوتے ہیں، اس لیے etc/nginx درست ہے۔ /etc/nginx کسی چیز سے match نہیں کرتا اور کچھ extract نہیں کرتا، جبکہ وجہ بتانے والی کوئی error بھی نہیں آتی۔ Extraction موجودہ working directory میں بھی لکھتی ہے، اس لیے پہلے کسی scratch directory میں جائیں، ورنہ پرانی files live files کو overwrite کر دیں گی۔

ایسی restore جو error کے بغیر مکمل ہو جائے، پھر بھی ثبوت نہیں ہوتی، کیونکہ اس کے اوپر چلنے والی application کے نزدیک مکمل restore کی اپنی تعریف ہوتی ہے۔ Postgres data directory کی copy سے دوبارہ بنایا گیا Immich server disk پر موجود ہر photo کے ساتھ واپس آ سکتا ہے، لیکن timeline خالی دکھا سکتی ہے۔ یہی وہ failure ہے جس سے Immich کی backup اور restore کو نمٹنا ہوتا ہے۔

آپ جو بھی tool منتخب کریں، schedule کام کا صرف نصف حصہ ہے۔ Scratch directory میں restore کو ایسے timer پر چلائیں جسے آپ واقعی monitor کرتے ہوں، بالکل اسی طرح جیسے VPS کے لیے restic backup guide کے مکمل walkthrough میں systemd timer کے ذریعے کیا گیا ہے۔

کس کام کے لیے کون سا ٹول بہتر ہے

restic کا انتخاب اس وقت کریں جب ہدف object storage ہو، جب آپ صرف ایک binary استعمال کرنا چاہتے ہوں اور دوسری طرف کوئی software انسٹال نہ کرنا چاہتے ہوں، جب متعدد machines کو ایک دوسرے کے ساتھ deduplication کرنا ہو، یا جب restore کرنے والا شخص ممکن ہے کہ آپ نہ ہوں۔ یہ repository کے URL کے ساتھ ایک single static binary ہے، اور operational اعتبار سے اس کا مقابلہ کرنا مشکل ہے۔

Borg کا انتخاب اس وقت کریں جب ہدف آپ کے زیر انتظام Linux box ہو، جب link میں latency ہو اور dataset میں millions of small files ہوں، جب آپ ransomware کے خلاف control کے طور پر append-only SSH key چاہتے ہوں، یا جب آپ ہر job کے لیے compression کو الگ tune کرنا چاہتے ہوں۔ یہ پرانا tool ہے، اس کی stable series آہستہ تبدیل ہوتی ہے، اور backup software میں یہ ایک خوبی ہے۔

دونوں درست انتخاب ہیں۔ غلط انتخاب وہ ہے جسے آپ کبھی test نہ کریں۔ اگر آپ پہلے ہی application-level dumps لیتے ہیں تو انہیں جاری رکھیں: database dumps کے ساتھ Nextcloud on Docker setup میں بیان کردہ طریقہ دونوں tools پر لاگو ہوتا ہے، کیونکہ کسی live database file کو بے ترتیب وقت پر copy کرنا database کا backup نہیں ہوتا۔

FAQ

کیا restic یا BorgBackup زیادہ تیز ہے؟

مقامی disk یا تیز رفتار LAN پر دونوں کی رفتار تقریباً یکساں ہوتی ہے، اور دونوں میں source کی read اور hash speed بڑی حد تک حد مقرر کرتی ہے۔ بہت زیادہ چھوٹی files کے ساتھ high-latency SSH link پر Borg عموماً بہتر کارکردگی دکھاتا ہے، کیونکہ دور موجودہ borg serve process ہر chunk کے لیے network round trip کے بغیر index سے متعلق سوالات کا جواب دیتا ہے۔ جب target object storage ہو تو restic عموماً بہتر رہتا ہے، کیونکہ Borg وہاں براہِ راست کام نہیں کر سکتا۔

کیا BorgBackup کو S3 یا Backblaze B2 میں backup کیا جا سکتا ہے؟

براہِ راست نہیں۔ Borg repository کو SSH کے ذریعے borg serve process فراہم کرتا ہے، اور bucket کے اندر ایسا کوئی process نہیں چلتا۔ اس کے متبادل کے طور پر کچھ لوگ rclone کے ذریعے object storage کو filesystem کے طور پر mount کرتے ہیں۔ Borg project اس طریقے کی سفارش نہیں کرتا، کیونکہ transaction کے دوران mount کا رابطہ منقطع ہو جائے تو repository خراب ہو سکتی ہے۔ اگر آپ کو object storage درکار ہے تو restic استعمال کریں۔

کیا میں دونوں tools کو ایک ہی data کے خلاف چلا سکتا ہوں؟

ہاں، اور کچھ لوگ ایسا کرتے ہیں: تیز local restore کے لیے Borg کو دوسرے server پر، اور offsite copy کے لیے restic کو object storage پر۔ دونوں ایک دوسرے کے ساتھ کچھ share نہیں کرتے، اس لیے read اور hash کی لاگت دو مرتبہ ادا کرنی پڑتی ہے، اور محفوظ طریقے سے رکھنے کے لیے دو passwords درکار ہوتے ہیں۔ یہ صرف اسی صورت کریں جب آپ نے دونوں restores کی جانچ کر لی ہو۔

اگر repository password ضائع ہو جائے تو کیا ہوتا ہے؟

دونوں tools میں data ناقابلِ بازیافت ہو جاتا ہے۔ restic scrypt کے ذریعے password سے اپنی key بناتا ہے، اور اسے bypass کرنے کا کوئی طریقہ نہیں ہے۔ Borg کے repokey mode میں encrypted key repository کے اندر محفوظ ہوتی ہے، اس لیے صرف passphrase سے restore کیا جا سکتا ہے۔ keyfile mode میں ~/.config/borg/keys/ کی key file بھی درکار ہوتی ہے۔ Password کو ایسے password manager میں محفوظ رکھیں جو اس server پر موجود نہ ہو جس کا backup لیا جا رہا ہے، اور اگر آپ keyfile استعمال کرتے ہیں تو borg key export کے ذریعے Borg key export کریں۔

کیا مجھے Borg 2.0 کا انتظار کرنا چاہیے؟

نہیں۔ July 2026 تک Borg 2.0 اب بھی beta ہے، اس کا version 2.0.0b22 ہے، اور project اسے صرف testing کے لیے قرار دیتا ہے۔ مستحکم series 1.4 ہے، اور موجودہ version 1.4.5 ہے۔ ابھی 1.4 سے آغاز کریں۔ Borg 2 repository format تبدیل کرتا ہے اور upgrade کا documented راستہ فراہم کرتا ہے، اس لیے آج آغاز کرنے سے آپ بعد میں پھنس نہیں جائیں گے۔