اس مضمون میں بیک اپ سافٹ ویئر پر غور کیا جائے گا جو ڈیٹا سٹریم کو الگ الگ اجزاء (ٹکڑوں) میں توڑ کر، ایک ذخیرہ بناتا ہے۔
ریپوزٹری کے اجزاء کو مزید کمپریسڈ اور انکرپٹ کیا جا سکتا ہے، اور سب سے اہم بات - بار بار بیک اپ کے عمل کے دوران - دوبارہ استعمال کیا جاتا ہے۔
اس طرح کے ذخیرے میں بیک اپ کاپی ایک دوسرے سے جڑے ہوئے اجزاء کی ایک نامزد سلسلہ ہے، مثال کے طور پر، مختلف ہیش فنکشنز پر مبنی۔
اسی طرح کے کئی حل ہیں، میں 3 پر توجہ مرکوز کروں گا: zbackup، borgbackup اور restic۔
متوقع نتائج
چونکہ تمام درخواست دہندگان کو کسی نہ کسی طریقے سے ذخیرہ بنانے کی ضرورت ہوتی ہے، اس لیے سب سے اہم عوامل میں سے ایک ذخیرہ کے سائز کا اندازہ لگانا ہوگا۔ مثالی طور پر، اس کا سائز قبول شدہ طریقہ کار کے مطابق 13 GB سے زیادہ نہیں ہونا چاہیے، یا اس سے بھی کم - اچھی اصلاح کے تابع۔
ٹار جیسے آرکائیورز کا استعمال کیے بغیر، براہ راست فائلوں کی بیک اپ کاپیاں بنانے کے ساتھ ساتھ rsync اور sshfs جیسے اضافی ٹولز کے بغیر ssh/sftp کے ساتھ کام کرنے کے قابل ہونا بھی انتہائی مطلوب ہے۔
بیک اپ بناتے وقت برتاؤ:
- مخزن کا سائز تبدیلیوں کے سائز کے برابر یا اس سے کم ہوگا۔
- کمپریشن اور/یا انکرپشن کا استعمال کرتے وقت بھاری CPU بوجھ کی توقع کی جاتی ہے، اور اگر بیک اپ اسٹوریج سرور پر آرکائیونگ اور/یا انکرپشن کا عمل چل رہا ہو تو کافی زیادہ نیٹ ورک اور ڈسک لوڈ ہونے کا امکان ہے۔
- اگر ریپوزٹری کو نقصان پہنچا ہے تو، نئے بیک اپ بناتے وقت اور بحال کرنے کی کوشش کرتے وقت تاخیر کا امکان ہے۔ ذخیرہ کی سالمیت کو یقینی بنانے کے لیے اضافی اقدامات کی منصوبہ بندی کرنا یا اس کی سالمیت کو جانچنے کے لیے بلٹ ان ٹولز کا استعمال کرنا ضروری ہے۔
ٹار کے ساتھ کام کرنا ایک حوالہ قدر کے طور پر لیا جاتا ہے، جیسا کہ پچھلے مضامین میں سے ایک میں دکھایا گیا تھا۔
زیڈ بیک اپ کی جانچ
zbackup کا عمومی طریقہ کار یہ ہے کہ پروگرام ان پٹ ڈیٹا اسٹریم والے علاقوں میں تلاش کرتا ہے جس میں ایک ہی ڈیٹا ہوتا ہے، پھر اختیاری طور پر ان کو کمپریس اور انکرپٹ کرتا ہے، ہر علاقے کو صرف ایک بار بچاتا ہے۔
ڈی ڈپلیکیشن موجودہ ڈیٹا بلاکس کے خلاف بائٹ بائی بائٹ میچز کی جانچ کرنے کے لیے سلائیڈنگ ونڈو کے ساتھ 64 بٹ رنگ ہیش فنکشن کا استعمال کرتی ہے (جیسے کہ rsync اسے کیسے نافذ کرتا ہے)۔
ملٹی تھریڈڈ lzma اور lzo کو کمپریشن کے لیے استعمال کیا جاتا ہے، اور aes کو خفیہ کاری کے لیے استعمال کیا جاتا ہے۔ تازہ ترین ورژنز مستقبل میں پرانے ڈیٹا کو ذخیرہ کرنے سے حذف کرنے کی صلاحیت رکھتے ہیں۔
پروگرام کم سے کم انحصار کے ساتھ C++ میں لکھا گیا ہے۔ مصنف بظاہر یونکس وے سے متاثر تھا، لہذا پروگرام بیک اپ بناتے وقت stdin پر ڈیٹا کو قبول کرتا ہے، بحال کرتے وقت stdout پر اسی طرح کا ڈیٹا سٹریم تیار کرتا ہے۔ اس طرح، آپ کے اپنے بیک اپ حل لکھتے وقت zbackup کو ایک بہت اچھے "بلڈنگ بلاک" کے طور پر استعمال کیا جا سکتا ہے۔ مثال کے طور پر، مضمون کے مصنف نے تقریباً 2014 سے اس پروگرام کو گھریلو مشینوں کے لیے بنیادی بیک اپ ٹول کے طور پر استعمال کیا ہے۔
ڈیٹا سٹریم ایک باقاعدہ ٹار ہو گا جب تک کہ دوسری صورت میں بیان نہ کیا جائے۔
آئیے دیکھتے ہیں کہ نتائج کیا ہیں:
کام کو 2 اختیارات میں چیک کیا گیا تھا:
- ایک ذخیرہ بنایا جاتا ہے اور zbackup کو سرور پر سورس ڈیٹا کے ساتھ لانچ کیا جاتا ہے، پھر ریپوزٹری کے مواد کو بیک اپ اسٹوریج سرور میں منتقل کیا جاتا ہے۔
- بیک اپ سٹوریج سرور پر ایک ریپوزٹری بنائی جاتی ہے، zbackup کو بیک اپ اسٹوریج سرور پر ssh کے ذریعے لانچ کیا جاتا ہے، اور ڈیٹا کو پائپ کے ذریعے بھیجا جاتا ہے۔
پہلے آپشن کے نتائج حسب ذیل تھے: 43m11s - جب ایک غیر خفیہ شدہ ذخیرہ اور lzma کمپریسر کا استعمال کرتے ہوئے، 19m13s - جب کمپریسر کو lzo سے تبدیل کیا جائے۔
اصل اعداد و شمار کے ساتھ سرور پر لوڈ اس طرح تھا (lzma کے ساتھ ایک مثال دکھائی گئی ہے؛ lzo کے ساتھ تقریبا ایک ہی تصویر تھی، لیکن rsync کا حصہ وقت کا ایک چوتھائی تھا):
یہ واضح ہے کہ اس طرح کا بیک اپ عمل صرف نسبتاً نایاب اور چھوٹی تبدیلیوں کے لیے موزوں ہے۔ زیڈ بیک اپ کو 1 تھریڈ تک محدود رکھنے کا بھی بہت مشورہ دیا جاتا ہے، ورنہ CPU کا بوجھ بہت زیادہ ہو گا، کیونکہ یہ پروگرام ایک سے زیادہ تھریڈز میں کام کرنے میں بہت اچھا ہے۔ ڈسک پر بوجھ چھوٹا تھا، جو عام طور پر جدید ایس ایس ڈی پر مبنی ڈسک سب سسٹم کے ساتھ قابل توجہ نہیں ہوگا۔ آپ ریپوزٹری ڈیٹا کو ریموٹ سرور سے سنکرونائز کرنے کے عمل کے آغاز کو بھی واضح طور پر دیکھ سکتے ہیں؛ آپریشن کی رفتار کا موازنہ ریگولر rsync سے کیا جاسکتا ہے اور اس کا انحصار بیک اپ اسٹوریج سرور کے ڈسک سب سسٹم کی کارکردگی پر ہے۔ اس نقطہ نظر کا نقصان ایک مقامی ذخیرہ کا ذخیرہ ہے اور اس کے نتیجے میں، ڈیٹا کی نقل۔
زیادہ دلچسپ اور عملی طور پر قابل اطلاق دوسرا آپشن ہے، zbackup کو براہ راست بیک اپ اسٹوریج سرور پر چلانا۔
سب سے پہلے، ہم lzma کمپریسر کے ساتھ خفیہ کاری کا استعمال کیے بغیر آپریشن کی جانچ کریں گے:
ہر ٹیسٹ رن کا رننگ ٹائم:
لانچ 1
لانچ 2
لانچ 3
39 ایم 45s
40 ایم 20s
40 ایم 3s
7 ایم 36s
8 ایم 3s
7 ایم 48s
15 ایم 35s
15 ایم 48s
15 ایم 38s
اگر آپ aes کا استعمال کرتے ہوئے انکرپشن کو فعال کرتے ہیں، تو نتائج کافی قریب ہیں:
اسی ڈیٹا پر آپریٹنگ ٹائم، انکرپشن کے ساتھ:
لانچ 1
لانچ 2
لانچ 3
43 ایم 40s
44 ایم 12s
44 ایم 3s
8 ایم 3s
8 ایم 15s
8 ایم 12s
15 ایم 0s
15 ایم 40s
15 ایم 25s
اگر انکرپشن کو lzo کا استعمال کرتے ہوئے کمپریشن کے ساتھ ملایا جائے تو یہ اس طرح لگتا ہے:
اوقات:
لانچ 1
لانچ 2
لانچ 3
18 ایم 2s
18 ایم 15s
18 ایم 12s
5 ایم 13s
5 ایم 24s
5 ایم 20s
8 ایم 48s
9 ایم 3s
8 ایم 51s
نتیجے کے ذخیرے کا سائز 13GB پر نسبتاً ایک جیسا تھا۔ اس کا مطلب ہے کہ ڈپلیکیشن صحیح طریقے سے کام کر رہی ہے۔ اس کے علاوہ، پہلے سے ہی کمپریسڈ ڈیٹا پر، lzo کا استعمال نمایاں اثر دیتا ہے؛ کل آپریٹنگ ٹائم کے لحاظ سے، zbackup ڈپلیکیٹی/ڈپلیکیٹی کے قریب آتا ہے، لیکن librsync پر مبنی ان سے 2-5 گنا پیچھے رہ جاتا ہے۔
فوائد واضح ہیں - بیک اپ اسٹوریج سرور پر ڈسک کی جگہ بچانا۔ جہاں تک ریپوزٹری چیکنگ ٹولز کا تعلق ہے، zbackup کا مصنف انہیں فراہم نہیں کرتا ہے؛ یہ سفارش کی جاتی ہے کہ غلطی برداشت کرنے والی ڈسک سرنی یا کلاؤڈ فراہم کنندہ استعمال کریں۔
مجموعی طور پر، ایک بہت اچھا تاثر، اس حقیقت کے باوجود کہ پراجیکٹ تقریباً 3 سال سے کھڑا ہے (آخری خصوصیت کی درخواست تقریباً ایک سال پہلے کی گئی تھی، لیکن جواب کے بغیر)۔
بورگ بیک اپ کی جانچ کرنا
بورگ بیک اپ اٹاری کا ایک کانٹا ہے، زیڈ بیک اپ کی طرح ایک اور نظام۔ python میں لکھا گیا، اس میں zbackup جیسی صلاحیتوں کی فہرست ہے، لیکن اس کے علاوہ یہ کر سکتے ہیں:
- فیوز کے ذریعے بیک اپ کو ماؤنٹ کریں۔
- ذخیرہ کے مواد کو چیک کریں۔
- کلائنٹ سرور موڈ میں کام کریں۔
- ڈیٹا کے لیے مختلف کمپریسرز کا استعمال کریں، نیز فائل کی قسم کو کمپریس کرتے وقت اس کا اندازہ لگانا۔
- 2 خفیہ کاری کے اختیارات، aes اور بلیک
- کے لیے بلٹ ان ٹول
کارکردگی کی جانچ پڑتال
borgbackup بینچ مارک crud ssh://backup_server/repo/path local_dir
نتائج حسب ذیل تھے:
CZ-BIG 96.51 MB/s (10 100.00 MB تمام صفر فائلیں: 10.36s)
RZ-BIG 57.22 MB/s (10 100.00 MB تمام صفر فائلیں: 17.48s)
UZ-BIG 253.63 MB/s (10 100.00 MB تمام صفر فائلیں: 3.94s)
DZ-BIG 351.06 MB/s (10 100.00 MB تمام صفر فائلیں: 2.85s)
CR-BIG 34.30 MB/s (10 100.00 MB بے ترتیب فائلیں: 29.15s)
RR-BIG 60.69 MB/s (10 100.00 MB بے ترتیب فائلیں: 16.48s)
UR-BIG 311.06 MB/s (10 100.00 MB بے ترتیب فائلیں: 3.21s)
DR-BIG 72.63 MB/s (10 100.00 MB بے ترتیب فائلیں: 13.77s)
CZ-MEDIUM 108.59 MB/s (1000 1.00 MB تمام صفر فائلیں: 9.21s)
RZ-MEDIUM 76.16 MB/s (1000 1.00 MB تمام صفر فائلیں: 13.13s)
UZ-MEDIUM 331.27 MB/s (1000 1.00 MB تمام صفر فائلیں: 3.02s)
DZ-MEDIUM 387.36 MB/s (1000 1.00 MB تمام صفر فائلیں: 2.58s)
CR-MEDIUM 37.80 MB/s (1000 1.00 MB بے ترتیب فائلیں: 26.45s)
RR-MEDIUM 68.90 MB/s (1000 1.00 MB بے ترتیب فائلیں: 14.51s)
UR-MEDIUM 347.24 MB/s (1000 1.00 MB بے ترتیب فائلیں: 2.88s)
DR-MEDIUM 48.80 MB/s (1000 1.00 MB بے ترتیب فائلیں: 20.49s)
CZ-SMALL 11.72 MB/s (10000 10.00 kB تمام صفر فائلیں: 8.53s)
RZ-SMALL 32.57 MB/s (10000 10.00 kB تمام صفر فائلیں: 3.07s)
UZ-SMALL 19.37 MB/s (10000 10.00 kB تمام صفر فائلیں: 5.16s)
DZ-SMALL 33.71 MB/s (10000 10.00 kB تمام صفر فائلیں: 2.97s)
CR-SMALL 6.85 MB/s (10000 10.00 kB بے ترتیب فائلیں: 14.60s)
RR-SMALL 31.27 MB/s (10000 10.00 kB بے ترتیب فائلیں: 3.20s)
UR-SMALL 12.28 MB/s (10000 10.00 kB بے ترتیب فائلیں: 8.14s)
DR-SMALL 18.78 MB/s (10000 10.00 kB بے ترتیب فائلیں: 5.32s)
جانچ کرتے وقت، فائل کی قسم (کمپریشن آٹو) کا تعین کرنے کے لیے کمپریشن ہیورسٹکس کا استعمال کیا جائے گا، اور نتائج درج ذیل ہوں گے:
سب سے پہلے، آئیے چیک کریں کہ یہ خفیہ کاری کے بغیر کیسے کام کرتا ہے:
اوقات:
لانچ 1
لانچ 2
لانچ 3
4 ایم 6s
4 ایم 10s
4 ایم 5s
56s
58s
54s
1 ایم 26s
1 ایم 34s
1 ایم 30s
اگر آپ ریپوزٹری کی اجازت (توثیق شدہ موڈ) کو فعال کرتے ہیں، تو نتائج قریب ہوں گے:
اوقات:
لانچ 1
لانچ 2
لانچ 3
4 ایم 11s
4 ایم 20s
4 ایم 12s
1 ایم 0s
1 ایم 3s
1 ایم 2s
1 ایم 30s
1 ایم 34s
1 ایم 31s
جب aes انکرپشن کو چالو کیا گیا تو نتائج زیادہ خراب نہیں ہوئے:
لانچ 1
لانچ 2
لانچ 3
4 ایم 55s
5 ایم 2s
4 ایم 58s
1 ایم 0s
1 ایم 2s
1 ایم 0s
1 ایم 49s
1 ایم 50s
1 ایم 50s
اور اگر آپ aes کو بلیک میں تبدیل کرتے ہیں تو صورتحال مکمل طور پر بہتر ہو جائے گی:
اوقات:
لانچ 1
لانچ 2
لانچ 3
4 ایم 33s
4 ایم 43s
4 ایم 40s
59s
1 ایم 0s
1 ایم 0s
1 ایم 38s
1 ایم 43s
1 ایم 40s
جیسا کہ زیڈ بیک اپ کے معاملے میں، ریپوزٹری کا سائز 13 جی بی اور اس سے بھی کم تھا، جس کی عام طور پر توقع کی جاتی ہے۔ میں رننگ ٹائم سے بہت خوش تھا؛ یہ librsync پر مبنی حل سے موازنہ ہے، بہت وسیع صلاحیتیں فراہم کرتا ہے۔ میں ماحولیاتی متغیرات کے ذریعے مختلف پیرامیٹرز سیٹ کرنے کی صلاحیت سے بھی خوش تھا، جو خودکار موڈ میں بورگ بیک اپ کا استعمال کرتے وقت بہت سنجیدہ فائدہ دیتا ہے۔ میں بیک اپ کے دوران بوجھ سے بھی خوش تھا: پروسیسر کے بوجھ کو دیکھتے ہوئے، بورگ بیک اپ 1 تھریڈ میں کام کرتا ہے۔
اسے استعمال کرتے وقت کوئی خاص نقصان نہیں ہوا۔
آرام دہ اور پرسکون ٹیسٹنگ
اس حقیقت کے باوجود کہ ریسٹک کافی نیا حل ہے (پہلے 2 امیدواروں کو 2013 اور اس سے زیادہ عمر میں جانا جاتا تھا)، اس میں کافی اچھی خصوصیات ہیں۔ گو میں لکھا گیا۔
جب zbackup کے ساتھ موازنہ کیا جائے تو، یہ اضافی طور پر دیتا ہے:
- ذخیرہ کی سالمیت کی جانچ کرنا (بشمول حصوں کی جانچ پڑتال)۔
- بیک اپ کو ذخیرہ کرنے کے لیے معاون پروٹوکولز اور فراہم کنندگان کی ایک بڑی فہرست، نیز کلاؤڈ حل کے لیے rclone - rsync کے لیے سپورٹ۔
- ایک دوسرے کے ساتھ 2 بیک اپ کا موازنہ کرنا۔
- فیوز کے ذریعے ذخیرے کو لگانا۔
عام طور پر، خصوصیات کی فہرست بورگ بیک اپ کے کافی قریب ہے، کچھ جگہوں پر زیادہ، دوسروں میں کم۔ خصوصیات میں سے ایک یہ ہے کہ خفیہ کاری کو غیر فعال کرنے کا کوئی طریقہ نہیں ہے، اور اس وجہ سے بیک اپ کاپیاں ہمیشہ انکرپٹ کی جائیں گی۔ آئیے عملی طور پر دیکھتے ہیں کہ اس سافٹ ویئر سے کیا کیا جا سکتا ہے:
نتائج حسب ذیل تھے:
اوقات:
لانچ 1
لانچ 2
لانچ 3
5 ایم 25s
5 ایم 50s
5 ایم 38s
35s
38s
36s
1 ایم 54s
2 ایم 2s
1 ایم 58s
کارکردگی کے نتائج کا موازنہ rsync پر مبنی حلوں سے بھی کیا جا سکتا ہے اور، عام طور پر، بورگ بیک اپ کے بہت قریب، لیکن CPU لوڈ زیادہ ہے (متعدد تھریڈز چل رہے ہیں) اور sawtooth۔
زیادہ تر امکان ہے کہ، پروگرام ڈیٹا اسٹوریج سرور پر ڈسک سب سسٹم کی کارکردگی سے محدود ہے، جیسا کہ پہلے ہی rsync کا معاملہ تھا۔ ذخیرے کا سائز 13 جی بی تھا، بالکل zbackup یا borgbackup کی طرح، اس حل کو استعمال کرتے وقت کوئی واضح نقصانات نہیں تھے۔
نتائج
درحقیقت، تمام امیدواروں نے ایک جیسے نتائج حاصل کیے، لیکن مختلف قیمتوں پر۔ بورگ بیک اپ نے سب سے بہترین کارکردگی کا مظاہرہ کیا، ریسٹک قدرے سست تھا، زیڈ بیک اپ شاید استعمال کرنا شروع کرنے کے قابل نہیں ہے،
اور اگر یہ پہلے سے استعمال میں ہے تو اسے بورگ بیک اپ یا ریسٹک میں تبدیل کرنے کی کوشش کریں۔
نتائج
سب سے امید افزا حل آرام دہ معلوم ہوتا ہے، کیونکہ... یہ وہی ہے جس کے پاس آپریٹنگ اسپیڈ میں صلاحیتوں کا بہترین تناسب ہے، لیکن آئیے فی الحال عام نتائج پر جلدی نہ کریں۔
Borgbackup بنیادی طور پر کوئی بدتر نہیں ہے، لیکن zbackup کو شاید بہتر طور پر تبدیل کیا گیا ہے۔ سچ ہے، zbackup اب بھی 3-2-1 اصول کے کام کرنے کو یقینی بنانے کے لیے استعمال کیا جا سکتا ہے۔ مثال کے طور پر، (lib)rsync پر مبنی بیک اپ سہولیات کے علاوہ۔
اعلان
بیک اپ، حصہ 5: لینکس کے لیے بیکولا اور ویم بیک اپ کی جانچ
بیک اپ حصہ 6: بیک اپ ٹولز کا موازنہ
بیک اپ حصہ 7: نتائج
پوسٹ کردہ بذریعہ: پاول ڈیمکووچ
ماخذ: www.habr.com