یہ نوٹ بیک اپ ٹولز پر بحث کرتا ہے جو بیک اپ سرور پر آرکائیوز بنا کر بیک اپ انجام دیتے ہیں۔
تقاضوں کو پورا کرنے والوں میں ڈپلیسیٹی (جس کا ڈیجا ڈوپ کی شکل میں ایک اچھا انٹرفیس ہے) اور ڈپلیکیٹی ہیں۔
ایک اور بہت ہی قابل ذکر بیک اپ ٹول ڈار ہے، لیکن چونکہ اس میں آپشنز کی ایک بہت وسیع فہرست ہے - ٹیسٹنگ کا طریقہ کار بمشکل 10 فیصد کا احاطہ کرتا ہے جس کی یہ صلاحیت رکھتی ہے - ہم اسے موجودہ سائیکل کے حصے کے طور پر نہیں جانچ رہے ہیں۔
متوقع نتائج
چونکہ دونوں امیدوار کسی نہ کسی طریقے سے آرکائیوز بناتے ہیں، اس لیے باقاعدہ ٹار کو بطور رہنما استعمال کیا جا سکتا ہے۔
مزید برآں، ہم جائزہ لیں گے کہ سٹوریج سرور پر ڈیٹا سٹوریج کو کتنی اچھی طرح سے بہتر بنایا گیا ہے بیک اپ کاپیاں بنا کر جس میں صرف ایک مکمل کاپی اور فائلوں کی موجودہ حالت، یا پچھلے اور موجودہ آرکائیوز کے درمیان فرق ہوتا ہے (بڑھتی ہوئی، کمی، وغیرہ)۔ .
بیک اپ بناتے وقت برتاؤ:
- بیک اپ اسٹوریج سرور پر فائلوں کی نسبتاً کم تعداد (بیک اپ کاپیوں کی تعداد یا جی بی میں ڈیٹا کے سائز کے مقابلے)، لیکن ان کا سائز کافی بڑا ہے (دسیوں سے سینکڑوں میگا بائٹس)۔
- ریپوزٹری کے سائز میں صرف تبدیلیاں شامل ہوں گی - کوئی ڈپلیکیٹ محفوظ نہیں کیا جائے گا، لہذا ریپوزٹری کا سائز rsync پر مبنی سافٹ ویئر کے مقابلے میں چھوٹا ہوگا۔
- کمپریشن اور/یا انکرپشن کا استعمال کرتے وقت بھاری CPU بوجھ کی توقع کریں، اور اگر بیک اپ اسٹوریج سرور پر آرکائیونگ اور/یا انکرپشن کا عمل چل رہا ہو تو نیٹ ورک اور ڈسک کا بہت زیادہ بوجھ متوقع ہے۔
آئیے درج ذیل کمانڈ کو بطور ریفرنس ویلیو چلائیں:
cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"عملدرآمد کے نتائج حسب ذیل تھے:
عملدرآمد کا وقت 3m12s۔ یہ دیکھا جا سکتا ہے کہ رفتار بیک اپ سٹوریج سرور کے ڈسک سب سسٹم کے ذریعے محدود ہے، جیسا کہ مثال کے طور پر . صرف تھوڑا تیز، کیونکہ... ریکارڈنگ ایک فائل میں جاتی ہے۔
اس کے علاوہ، کمپریشن کا اندازہ کرنے کے لیے، آئیے وہی آپشن چلائیں، لیکن بیک اپ سرور سائیڈ پر کمپریشن کو فعال کریں:
cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"نتائج یہ ہیں:
عملدرآمد کا وقت 10m11s۔ زیادہ تر امکان ہے کہ رکاوٹ وصول کرنے والے سرے پر سنگل فلو کمپریسر ہے۔
وہی کمانڈ، لیکن کمپریشن کے ساتھ اصل ڈیٹا کے ساتھ سرور کو منتقل کیا گیا تاکہ اس مفروضے کی جانچ کی جا سکے کہ رکاوٹ ایک واحد تھریڈڈ کمپریسر ہے۔
cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"یہ اس طرح نکلا:
پھانسی کا وقت 9m37s تھا۔ کمپریسر کے ذریعہ ایک کور پر بوجھ واضح طور پر نظر آتا ہے، کیونکہ نیٹ ورک کی منتقلی کی رفتار اور سورس ڈسک سب سسٹم پر بوجھ ایک جیسے ہیں۔
خفیہ کاری کا اندازہ کرنے کے لیے، آپ ایک اضافی کمانڈ کو جوڑ کر openssl یا gpg استعمال کر سکتے ہیں۔ openssl یا gpg پائپ میں. حوالہ کے لئے اس طرح ایک کمانڈ ہو گا:
cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"نتائج اس طرح سامنے آئے:
عمل درآمد کا وقت 10m30s نکلا، کیونکہ 2 پروسیس ریسیونگ سائیڈ پر چل رہے تھے - رکاوٹ دوبارہ سنگل تھریڈڈ کمپریسر ہے، نیز چھوٹے انکرپشن اوور ہیڈ۔
یوپیڈی: bliznezz کی درخواست پر میں pigz کے ساتھ ٹیسٹ شامل کر رہا ہوں۔ اگر آپ صرف کمپریسر استعمال کرتے ہیں، تو اس میں 6m30s لگیں گے، اگر آپ انکرپشن بھی شامل کرتے ہیں، تو یہ تقریباً 7m ہوگا۔ نیچے کے گراف میں ڈِپ ایک غیر فلشڈ ڈسک کیش ہے:
ڈپلیکیٹ ٹیسٹنگ
ڈپلیسیٹی ٹار فارمیٹ میں انکرپٹڈ آرکائیوز بنا کر بیک اپ کے لیے ایک ازگر کا سافٹ ویئر ہے۔
انکریمنٹل آرکائیوز کے لیے، librsync استعمال کیا جاتا ہے، لہذا آپ اس طرز عمل کی توقع کر سکتے ہیں جس میں بیان کیا گیا ہے۔ .
بیک اپ کو gnupg کا استعمال کرتے ہوئے انکرپٹ اور دستخط کیا جا سکتا ہے، جو بیک اپس (s3، backblaze، gdrive، وغیرہ) کو ذخیرہ کرنے کے لیے مختلف فراہم کنندگان کا استعمال کرتے وقت اہم ہے۔
آئیے دیکھتے ہیں کہ نتائج کیا ہیں:
یہ وہ نتائج ہیں جو ہمیں بغیر خفیہ کاری کے چلانے پر ملے
خراب کرنے والا
ہر ٹیسٹ رن کا رننگ ٹائم:
لانچ 1
لانچ 2
لانچ 3
16 ایم 33s
17 ایم 20s
16 ایم 30s
8 ایم 29s
9 ایم 3s
8 ایم 45s
5 ایم 21s
6 ایم 04s
5 ایم 53s
اور 2048 بٹس کے کلیدی سائز کے ساتھ، gnupg انکرپشن فعال ہونے پر نتائج یہ ہیں:
اسی ڈیٹا پر آپریٹنگ ٹائم، انکرپشن کے ساتھ:
لانچ 1
لانچ 2
لانچ 3
17 ایم 22s
17 ایم 32s
17 ایم 28s
8 ایم 52s
9 ایم 13s
9 ایم 3s
5 ایم 48s
5 ایم 40s
5 ایم 30s
بلاک سائز کا اشارہ کیا گیا تھا - 512 میگا بائٹس، جو گراف میں واضح طور پر نظر آتا ہے؛ پروسیسر کا بوجھ درحقیقت 50% پر رہا، جس کا مطلب ہے کہ پروگرام ایک سے زیادہ پروسیسر کور استعمال نہیں کرتا ہے۔
پروگرام کے آپریشن کا اصول بھی واضح طور پر نظر آتا ہے: انہوں نے ڈیٹا کا ایک ٹکڑا لیا، اسے کمپریس کیا، اور اسے بیک اپ اسٹوریج سرور پر بھیج دیا، جو کافی سست ہو سکتا ہے۔
ایک اور خصوصیت پروگرام کے چلنے کا متوقع وقت ہے، جو صرف تبدیل شدہ ڈیٹا کے سائز پر منحصر ہے۔
انکرپشن کو فعال کرنے سے پروگرام کے چلنے کے وقت میں خاطر خواہ اضافہ نہیں ہوا، لیکن اس سے پروسیسر کے بوجھ میں تقریباً 10 فیصد اضافہ ہوا، جو کافی اچھا بونس ہو سکتا ہے۔
بدقسمتی سے، یہ پروگرام ڈائرکٹری کا نام تبدیل کرنے کے ساتھ صورت حال کا صحیح طور پر پتہ لگانے میں ناکام رہا، اور اس کے نتیجے میں ریپوزٹری کا سائز تبدیلیوں کے سائز (یعنی تمام 18 جی بی) کے برابر نکلا، لیکن بیک اپ کے لیے غیر بھروسہ مند سرور کو واضح طور پر استعمال کرنے کی صلاحیت۔ اس رویے کا احاطہ کرتا ہے.
ڈپلیکیٹ ٹیسٹنگ
یہ سافٹ ویئر C# میں لکھا گیا ہے اور Mono کی لائبریریوں کے سیٹ کا استعمال کرتے ہوئے چلتا ہے۔ ایک GUI کے ساتھ ساتھ CLI ورژن بھی ہے۔
اہم خصوصیات کی تخمینی فہرست دوہرے سے ملتی جلتی ہے، بشمول مختلف بیک اپ سٹوریج فراہم کرنے والے، تاہم، ڈپلیکیٹی کے برعکس، زیادہ تر خصوصیات تھرڈ پارٹی ٹولز کے بغیر دستیاب ہیں۔ آیا یہ پلس ہے یا مائنس مخصوص کیس پر منحصر ہے، لیکن ابتدائی افراد کے لیے، ازگر کے لیے اضافی پیکجز انسٹال کرنے کے بجائے، تمام فیچرز کی فہرست ایک ساتھ رکھنا زیادہ آسان ہوتا ہے، جیسا کہ دوغلے پن کے ساتھ معاملہ.
ایک اور چھوٹی بات - پروگرام بیک اپ شروع کرنے والے صارف کی جانب سے فعال طور پر ایک مقامی sqlite ڈیٹابیس لکھتا ہے، لہذا آپ کو اضافی طور پر اس بات کو یقینی بنانا ہوگا کہ جب بھی cli کا استعمال شروع کیا جائے تو مطلوبہ ڈیٹا بیس کی صحیح وضاحت کی گئی ہے۔ GUI یا WEBGUI کے ذریعے کام کرتے وقت، تفصیلات صارف سے چھپائی جائیں گی۔
آئیے دیکھتے ہیں کہ یہ حل کن اشارے پیدا کرسکتا ہے:
اگر آپ خفیہ کاری کو بند کر دیتے ہیں (اور WEBGUI ایسا کرنے کی سفارش نہیں کرتا ہے)، تو نتائج درج ذیل ہیں:
اوقات:
لانچ 1
لانچ 2
لانچ 3
20 ایم 43s
20 ایم 13s
20 ایم 28s
5 ایم 21s
5 ایم 40s
5 ایم 35s
7 ایم 36s
7 ایم 54s
7 ایم 49s
خفیہ کاری فعال ہونے کے ساتھ، aes کا استعمال کرتے ہوئے، ایسا لگتا ہے:
اوقات:
لانچ 1
لانچ 2
لانچ 3
29 ایم 9s
30 ایم 1s
29 ایم 54s
5 ایم 29s
6 ایم 2s
5 ایم 54s
8 ایم 44s
9 ایم 12s
9 ایم 1s
اور اگر آپ بیرونی پروگرام gnupg استعمال کرتے ہیں تو درج ذیل نتائج سامنے آتے ہیں۔
لانچ 1
لانچ 2
لانچ 3
26 ایم 6s
26 ایم 35s
26 ایم 17s
5 ایم 20s
5 ایم 48s
5 ایم 40s
8 ایم 12s
8 ایم 42s
8 ایم 15s
جیسا کہ آپ دیکھ سکتے ہیں، یہ پروگرام کئی تھریڈز میں کام کر سکتا ہے، لیکن اس سے یہ زیادہ نتیجہ خیز حل نہیں بنتا، اور اگر آپ انکرپشن کے کام کا موازنہ کریں تو یہ ایک بیرونی پروگرام شروع کر رہا ہے۔
مونو سیٹ سے لائبریری استعمال کرنے سے زیادہ تیز نکلا۔ یہ اس حقیقت کی وجہ سے ہوسکتا ہے کہ بیرونی پروگرام زیادہ بہتر ہے۔
ایک اور اچھی بات یہ تھی کہ ریپوزٹری کا سائز بالکل اتنا ہی لگتا ہے جتنا اصل تبدیل شدہ ڈیٹا، یعنی duplicati نے ڈائریکٹری کا نام تبدیل کرنے کا پتہ لگایا اور اس صورتحال کو صحیح طریقے سے سنبھالا۔ یہ دوسرا ٹیسٹ چلاتے وقت دیکھا جا سکتا ہے۔
مجموعی طور پر، پروگرام کے کافی مثبت تاثرات، بشمول نئے آنے والوں کے لیے کافی دوستانہ ہونا۔
نتائج
دونوں امیدواروں نے آہستہ آہستہ کام کیا، لیکن عام طور پر، ریگولر ٹار کے مقابلے میں، کم از کم نقل کے ساتھ، ترقی ہوتی ہے۔ اس طرح کی ترقی کی قیمت بھی واضح ہے - ایک قابل توجہ بوجھ
پروسیسر عام طور پر، نتائج کی پیشن گوئی میں کوئی خاص انحراف نہیں ہے۔
نتائج
اگر آپ کو کہیں بھی جلدی کرنے کی ضرورت نہیں ہے، اور آپ کے پاس اسپیئر پروسیسر بھی ہے، تو غور کیا گیا کوئی بھی حل کام کرے گا، کسی بھی صورت میں، کافی کام ہو چکا ہے جسے ٹار کے اوپر ریپر اسکرپٹ لکھ کر نہیں دہرایا جانا چاہیے۔ . اگر بیک اپ کاپیوں کو ذخیرہ کرنے والے سرور پر مکمل بھروسہ نہیں کیا جا سکتا ہے تو خفیہ کاری کی موجودگی ایک بہت ضروری خاصیت ہے۔
پر مبنی حل کے مقابلے - کارکردگی کئی گنا بدتر ہو سکتی ہے، اس حقیقت کے باوجود کہ اپنی خالص شکل میں ٹار نے rsync کے مقابلے میں 20-30% تیزی سے کام کیا۔
ذخیرہ کے سائز پر بچتیں ہیں، لیکن صرف نقل کے ساتھ۔
اعلان
بیک اپ حصہ 3: ڈپلیکیٹی، ڈپلیکیٹی، ڈیجا ڈوپ کا جائزہ اور جانچ
بیک اپ حصہ 4: Zbackup، restic، borgbackup جائزہ اور جانچ
بیک اپ، حصہ 5: لینکس کے لیے بیکولا اور ویم بیک اپ کی جانچ
بیک اپ حصہ 6: بیک اپ ٹولز کا موازنہ
بیک اپ حصہ 7: نتائج
پوسٹ کردہ بذریعہ: پاول ڈیمکووچ
ماخذ: www.habr.com