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

Restic اور BorgBackup، ایک پیراگراف میں

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

باقی تمام فرق نسبتاً معمولی ہیں۔ دونوں content-defined chunking کے ذریعے files کو تقسیم کرتے ہیں، اس لیے 40 GB کی ایسی directory جس میں 200 MB کی تبدیلی ہوئی ہو، تقریباً 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 کے لیے نشان زد ہے، اس لیے آج آپ کو 1.4 deploy کرنا چاہیے۔

اصل repository ہی حقیقی فرق ہے

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

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

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

# 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

خفیہ کاری: ان میں سے ایک کو بند کیا جا سکتا ہے

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

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

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

کمپریشن، اور restic میں اس کی تاخیر کی وجہ

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

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

عموماً فیصلہ اسی مرحلے پر ہوتا ہے۔

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

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 کو ریموٹ repository تک پہنچنے کے لیے SSH اور دوسری جانب Borg کی installation درکار ہوتی ہے۔ دوسری جانب موجود version کا client کے ساتھ compatible ہونا بھی ضروری ہے۔ اگر دوسری جانب موجود server آپ کے انتظام میں نہ ہو تو یہ ایک رکاوٹ ہے۔ اگر وہ دوسرا 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 میں اس کا مساوی طریقہ صرف اسی وقت موجود ہے جب آپ اپنا REST server چلائیں، جو append only mode کو support کرتا ہے۔ plain S3 کے ساتھ یہی نتیجہ bucket policy یا object lock سے حاصل ہوتا ہے۔ یہ provider کی ذمہ داری ہے، restic کی نہیں۔ transport کو بھی محفوظ کریں، کیونکہ SSH والے حصے کو بھی کسی دوسرے login کی طرح احتیاط درکار ہے: backup account پر restricted authorized_keys entry کے ساتھ صرف key والا SSH لاگو کریں۔

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

دونوں پروجیکٹس ایسا بینچ مارک شائع نہیں کرتے جس پر آپ اپنے ڈیٹا کے لیے بھروسا کر سکیں۔ اس لیے طریقۂ کار کی بنیاد پر نتیجہ اخذ کریں۔

SSH پر Borg تاخیر والے لنک پر تیز ہوتا ہے، کیونکہ سرور کی طرف ذہین عمل موجود ہوتا ہے۔ کلائنٹ ایک سوال بھیجتا ہے، ریموٹ borg serve عمل ریپوزٹری انڈیکس سے جواب دیتا ہے، اور ٹرانزیکشن ایک ہی جگہ مکمل ہوتی ہے۔ ہر چھوٹی فائل کے لیے chunk تلاشیں الگ network round trip میں تبدیل نہیں ہوتیں۔

Object storage پر Restic میں سرور کی طرف ایسا عمل موجود نہیں ہوتا۔ اس لیے اسے HTTP کے ذریعے حاصل کی گئی index files اور pack files سے اپنی معلومات تیار کرنا پڑتی ہیں۔ درخواستوں کی تعداد کو قابلِ انتظام رکھنے کے لیے یہ اپ لوڈ سے پہلے بہت سے چھوٹے chunks کو بڑی pack files میں جمع کرتا ہے۔ اگلی بار مکمل انڈیکس دوبارہ حاصل نہ کرنا پڑے، اس لیے یہ ~/.cache/restic میں مقامی cache رکھتا ہے۔ یہ cache حذف کر دیں تو اگلا backup سست ہوگا، کیونکہ cache دوبارہ تیار کیا جائے گا۔ زیادہ تاخیر والے لنک پر، جہاں لاکھوں چھوٹی فائلیں ہوں، یہی صورت حال ہے جس میں اسی ڈیٹا پر Restic، Borg کے مقابلے میں سست محسوس ہوتا ہے۔

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

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

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

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

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

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

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

دونوں ٹولز میں مسئلہ ایک ہی ہے، اس لیے اسے واضح طور پر بیان کرنا ضروری ہے۔ Borg میں borg prune آرکائیوز ہٹا دیتا ہے، لیکن خود ڈسک کی جگہ خالی نہیں کرتا۔ جگہ اس وقت واپس آتی ہے جب borg compact چلتا ہے۔ اس لیے ایسا cron job جو prune چلاتا ہے لیکن compact نہیں چلاتا، repository کو مسلسل بڑا کرتا رہتا ہے، جبکہ آرکائیوز کی فہرست مختصر رہتی ہے۔ restic میں forget کو --prune کے بغیر چلانے سے صرف snapshot references ہٹتے ہیں، جبکہ ڈیٹا اس وقت تک موجود رہتا ہے جب تک prune نہ چلایا جائے۔

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

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

دونوں tools ایک 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 کر دیں گی۔

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

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

جب ہدف object storage ہو، آپ ایک binary چاہتے ہوں اور دور والے سرے پر کوئی software انسٹال نہ کرنا چاہتے ہوں، کئی machines کو ایک دوسرے کے ساتھ deduplication کرنی ہو، یا restore کرنے والا شخص آپ نہ بھی ہو سکتا ہو، تو restic منتخب کریں۔ یہ ایک single static binary ہے جس کے ساتھ repository کے لیے URL استعمال ہوتا ہے، اور 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 لیتے ہیں تو انہیں جاری رکھیں: database dumps کے ساتھ Nextcloud on Docker setup کا طریقہ دونوں tools پر لاگو ہوتا ہے، کیونکہ کسی live database file کو کسی بے ترتیب وقت پر copy کرنا database کا backup نہیں ہوتا۔

FAQ

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

مقامی ڈسک یا تیز LAN پر دونوں کی رفتار تقریباً یکساں ہوتی ہے، اور آخرکار دونوں ماخذ پر پڑھنے اور hash کرنے کی رفتار سے محدود رہتے ہیں۔ بہت سی چھوٹی فائلوں کے ساتھ زیادہ 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 scrypt کے ذریعے password سے اپنی key اخذ کرتا ہے، اور اس میں کوئی bypass موجود نہیں ہے۔ repokey mode میں Borg 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 کے لیے قرار دیتا ہے۔ Stable series 1.4 ہے، اور موجودہ ورژن 1.4.5 ہے۔ ابھی 1.4 سے آغاز کریں۔ Borg 2 repository format تبدیل کرتا ہے اور upgrade کا documented path فراہم کرتا ہے، اس لیے آج آغاز کرنے سے آپ بعد میں کسی بند گلی میں نہیں پھنسیں گے۔