Restic یا BorgBackup: کون سا backup چلائیں؟

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

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

باقی تمام فرق نسبتاً معمولی ہیں۔ دونوں files کو content-defined chunking کے ذریعے تقسیم کرتے ہیں، اس لیے 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 ہے اور موجودہ version 1.4.5 ہے۔ Borg 2.0 کئی سال سے beta میں ہے اور اب بھی صرف testing کے لیے marked ہے، اس لیے آج آپ کو 1.4 deploy کرنا چاہیے۔

ریپوزٹری کا ماڈل ہی اصل فرق ہے

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

Borg ریپوزٹری بھی disk پر موجود files ہوتی ہے، لیکن Borg کسی سادہ transport کے ذریعے اس سے رابطہ نہیں کرتا۔ Remote repository کے لیے Borg SSH کے ذریعے دوسری جانب borg serve شروع کرتا ہے اور اس process کے ساتھ اپنا protocol استعمال کرتا ہے۔ Server side حقیقی کام کرتی ہے: یہ ریپوزٹری رکھتی ہے، transaction نافذ کرتی ہے، اور 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 password طلب کرتا ہے، scrypt کے ذریعے اس سے key بناتا ہے، اور اس کے بعد لکھی جانے والی ہر pack file encrypted اور authenticated ہوتی ہے۔ password کھو جائے تو 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 unreadable ہوں گے۔ ہر mode کا -blake2 variant بھی موجود ہے، جو HMAC-SHA256 کے بجائے BLAKE2b سے authentication کرتا ہے۔ SHA acceleration کے بغیر hardware پر یہ زیادہ تیز ہوتا ہے۔ --encryption=none بھی موجود ہے، اور جب repository آپ کی ملکیت والی encrypted disk پر ہو تو یہ ایک حقیقی انتخاب ہے۔

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

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

Borg نے ابتدا ہی سے کمپریشن فراہم کی ہے۔ پہلے سے منتخب شدہ آپشن lz4 ہے، کیونکہ یہ اتنا تیز ہے کہ اسے ہر جگہ فعال رکھا جا سکتا ہے۔ zstd میں 1 سے 22 تک levels دستیاب ہیں اور default level 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 بالکل موجود نہیں تھی۔ اس format کے لیے restic 0.14.0 یا اس کے بعد کا ورژن درکار ہے۔ اب نئی repository کے لیے format 2 default ہے، اور compression کو --compression کے ذریعے auto، off یا max values پر set کیا جاتا ہے۔ پرانی format 1 repository کو migrate کرنے تک وہ uncompressed رہتی ہے۔ لہذا اگر آپ کی restic repository 0.14 سے پہلے کی ہے اور آپ نے اسے migrate نہیں کیا، تو text، logs اور database dumps اب بھی اپنی مکمل size استعمال کر رہے ہیں۔

دور دراز targets: S3 بمقابلہ SSH

عام طور پر انتخاب یہیں کیا جاتا ہے۔

restic کو S3 تک رسائی کے لیے environment میں credentials درکار ہوتے ہیں، اور کہیں بھی کوئی اضافی سروس چلانے کی ضرورت نہیں ہوتی۔ یہی طریقہ آپ کے اپنے host کردہ bucket کے ساتھ بھی کام کرتا ہے۔ یہ ایک عام امتزاج ہے: اپنے 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 ہو جسے آپ پہلے ہی administer کرتے ہیں تو یہ مسئلہ نہیں، اور اس سے ransomware کے خلاف دونوں tools میں دستیاب مضبوط ترین control ملتا ہے: append-only SSH key۔ key کو borg serve چلانے پر مجبور کریں۔ اس سے client archives شامل کر سکتا ہے، لیکن انہیں delete نہیں کر سکتا۔ یوں breached machine اپنی backup history ختم نہیں کر سکتی۔

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

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

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

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

Borg over SSH تاخیر والے link پر تیز ہے، کیونکہ 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 سے اپنی صورتِ حال بنانی پڑتی ہے۔ Request count کو قابلِ انتظام رکھنے کے لیے یہ upload سے پہلے بہت سے چھوٹے chunks کو بڑی pack files میں جمع کرتا ہے، اور ~/.cache/restic میں local cache رکھتا ہے تاکہ اگلی run میں پورا index دوبارہ حاصل نہ کرنا پڑے۔ یہ cache delete کر دیں تو اگلا backup سست ہوگا، کیونکہ اسے cache دوبارہ بنانا پڑے گا۔ زیادہ latency والے link پر millions of small files کے ساتھ یہی وہ صورت ہے جس میں اسی data پر restic، Borg کے مقابلے میں سست محسوس ہوتا ہے۔

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

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

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

Restic کئی clients کو ایک ہی repository میں بیک وقت backup لینے دیتا ہے، کیونکہ backup کے دوران shared lock لیا جاتا ہے اور صرف maintenance کا کام، مثلاً prune، exclusive lock لیتا ہے۔ ایک ہی restic repository کی طرف بھیجے گئے یکساں دس servers ایک دوسرے کے data کے خلاف deduplication کرتے ہیں، اور دوسرے server کے بعد عموماً بہت کم data محفوظ ہوتا ہے۔ اس کا نقصان blast radius ہے: ایک password اور ایک repository میں موجود تمام data؛ اس لیے password ضائع ہونے پر تمام دس servers کا data ضائع ہو جاتا ہے۔

Retention: forget اور 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 کو مسلسل بڑا کرتا رہتا ہے، جبکہ archives کی فہرست مختصر رہتی ہے۔ restic میں، --prune کے بغیر forget صرف snapshot references ہٹاتا ہے، جبکہ data اس وقت تک موجود رہتا ہے جب تک prune نہ چلایا جائے۔

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

بحالی، اور یہی واحد ٹیسٹ ہے جو اہمیت رکھتا ہے

دونوں ٹولز snapshot mount کرتے ہیں، تاکہ آپ اس میں موجود فائلیں دیکھ سکیں۔ کسی ایک فائل کو واپس لانے کا یہ سب سے تیز طریقہ ہے۔

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 میں چلے جائیں۔ ورنہ پرانی فائلوں سے live files overwrite ہو جائیں گی۔

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

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

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

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

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

FAQ

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

مقامی disk یا تیز LAN پر دونوں کی کارکردگی تقریباً یکساں ہوتی ہے، اور دونوں کی رفتار source پر read اور hash کی رفتار سے محدود رہتی ہے۔ بہت سی چھوٹی files کے ساتھ زیادہ 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 recover نہیں کیا جا سکتا۔ restic password سے scrypt کے ذریعے اپنی key اخذ کرتا ہے، اور اس میں کوئی bypass موجود نہیں۔ Borg کے repokey mode میں encrypted key repository کے اندر محفوظ ہوتی ہے، اس لیے restore کے لیے صرف passphrase کافی ہوتا ہے؛ جبکہ keyfile mode میں ~/.config/borg/keys/ سے key file بھی درکار ہوتی ہے۔ Password کو ایسے password manager میں محفوظ رکھیں جو backup کیے جانے والے server پر موجود نہ ہو، اور اگر آپ keyfile استعمال کرتے ہیں تو borg key export کے ذریعے Borg key export کریں۔

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

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