بیک اپ حصہ 6: بیک اپ ٹولز کا موازنہ

یہ مضمون بیک اپ ٹولز کا موازنہ کرے گا، لیکن پہلے آپ کو معلوم کرنا چاہیے کہ وہ بیک اپ سے ڈیٹا کو بحال کرنے میں کتنی جلدی اور اچھی طرح سے مقابلہ کرتے ہیں۔
موازنہ میں آسانی کے لیے، ہم مکمل بیک اپ سے بحال کرنے پر غور کریں گے، خاص طور پر چونکہ تمام امیدوار اس طرز عمل کی حمایت کرتے ہیں۔ سادگی کے لیے، نمبر پہلے سے ہی اوسط ہیں (کئی رنز کا ریاضی کا مطلب)۔ نتائج کا خلاصہ ایک جدول میں کیا جائے گا، جس میں صلاحیتوں کے بارے میں معلومات بھی ہوں گی: ویب انٹرفیس کی موجودگی، سیٹ اپ اور آپریشن میں آسانی، خودکار کرنے کی صلاحیت، مختلف اضافی خصوصیات کی موجودگی (مثال کے طور پر، ڈیٹا کی سالمیت کی جانچ) وغیرہ گرافس سرور پر بوجھ دکھائے گا جہاں ڈیٹا استعمال کیا جائے گا (بیک اپ کاپیوں کو ذخیرہ کرنے کے لیے سرور نہیں)۔

ڈیٹا کی بازیابی۔

rsync اور tar کو ایک حوالہ نقطہ کے طور پر استعمال کیا جائے گا۔ وہ عام طور پر ان پر مبنی ہیں بیک اپ کاپیاں بنانے کے لیے سادہ سکرپٹ۔

Rsync 4 منٹ اور 28 سیکنڈ میں سیٹ کردہ ٹیسٹ ڈیٹا کے ساتھ مقابلہ کیا، دکھا رہا ہے۔

اس طرح کا بوجھ

بحالی کے عمل نے بیک اپ سٹوریج سرور (ساؤ ٹوتھ گرافس) کے ڈسک سب سسٹم کی حد کو متاثر کیا۔ آپ بغیر کسی پریشانی کے ایک دانا کی لوڈنگ کو بھی واضح طور پر دیکھ سکتے ہیں (کم iowait اور softirq - بالترتیب ڈسک اور نیٹ ورک کے ساتھ کوئی مسئلہ نہیں)۔ چونکہ دیگر دو پروگرام، یعنی rdiff-backup اور rsnapshot، rsync پر مبنی ہیں اور ریگولر rsync کو ریکوری ٹول کے طور پر بھی پیش کرتے ہیں، اس لیے ان کا لوڈ پروفائل اور بیک اپ ریکوری کا تقریباً ایک ہی وقت ہوگا۔

ٹار۔ اسے تھوڑا تیز کیا

2 منٹ اور 43 سیکنڈ:

بڑھتے ہوئے softirq کی وجہ سے سسٹم کا کل بوجھ اوسطاً 20% زیادہ تھا - نیٹ ورک سب سسٹم کے آپریشن کے دوران اوور ہیڈ لاگت میں اضافہ ہوا۔

اگر آرکائیو کو مزید کمپریس کیا جاتا ہے، تو بازیابی کا وقت 3 منٹ 19 سیکنڈ تک بڑھ جاتا ہے۔
مین سرور پر اتنے بوجھ کے ساتھ (مین سرور کی طرف سے پیک کھولنا):

ڈیکمپریشن عمل دونوں پروسیسر کور کو لے لیتا ہے کیونکہ دو عمل چل رہے ہیں۔ عام طور پر، یہ متوقع نتیجہ ہے. نیز، بیک اپ کے ساتھ سرور سائیڈ پر gzip چلانے پر ایک موازنہ نتیجہ (3 منٹ اور 20 سیکنڈ) حاصل کیا گیا؛ مرکزی سرور پر لوڈ پروفائل gzip کمپریسر کے بغیر ٹار چلانے سے بہت ملتا جلتا تھا (پچھلا گراف دیکھیں)۔

В rdiff بیک اپ آپ باقاعدہ rsync کا استعمال کرتے ہوئے اپنے بنائے ہوئے آخری بیک اپ کو سنکرونائز کر سکتے ہیں (نتائج ایک جیسے ہوں گے)، لیکن پرانے بیک اپ کو اب بھی rdiff-backup پروگرام کا استعمال کرتے ہوئے بحال کرنے کی ضرورت ہے، جس نے 17 منٹ اور 17 سیکنڈ میں بحالی مکمل کی،

یہ بوجھ:

شاید اس کا مقصد کم از کم مصنفین کی رفتار کو محدود کرنا تھا۔ ایسا حل پیش کرتے ہیں. بیک اپ کاپی کو بحال کرنے کا عمل خود ایک کور کے نصف سے تھوڑا کم لیتا ہے، جس میں متناسب موازنہ کارکردگی (یعنی 2-5 گنا سست) ڈسک اور نیٹ ورک پر rsync کے ساتھ ہوتی ہے۔

آر نیپ شاٹ بحالی کے لیے، یہ باقاعدہ rsync استعمال کرنے کا مشورہ دیتا ہے، لہذا اس کے نتائج ایک جیسے ہوں گے۔ عام طور پر، یہ اس طرح نکلا.

برپ میں نے بیک اپ کو بحال کرنے کا کام 7 منٹ اور 2 سیکنڈ میں مکمل کیا۔
اس بوجھ کے ساتھ:

اس نے کافی تیزی سے کام کیا، اور کم از کم خالص rsync سے کہیں زیادہ آسان ہے: آپ کو کسی بھی جھنڈے کو یاد رکھنے کی ضرورت نہیں ہے، ایک سادہ اور بدیہی کلی انٹرفیس، متعدد کاپیوں کے لیے بلٹ ان سپورٹ - حالانکہ یہ دو گنا سست ہے۔ اگر آپ کو اپنے بنائے گئے آخری بیک اپ سے ڈیٹا کو بحال کرنے کی ضرورت ہے، تو آپ کچھ انتباہات کے ساتھ rsync استعمال کر سکتے ہیں۔

پروگرام نے تقریباً ایک ہی رفتار اور بوجھ دکھایا بیک اپ پی سی rsync ٹرانسفر موڈ کو فعال کرتے وقت، بیک اپ کو تعینات کرتے وقت

7 منٹ اور 42 سیکنڈ:

لیکن ڈیٹا ٹرانسفر موڈ میں، بیک اپ پی سی نے ٹار کا زیادہ آہستہ سے مقابلہ کیا: 12 منٹ اور 15 سیکنڈ میں، پروسیسر کا بوجھ عام طور پر کم تھا۔

ڈیڑھ بار:

نقل بغیر انکرپشن نے قدرے بہتر نتائج دکھائے، 10 منٹ اور 58 سیکنڈ میں بیک اپ بحال کیا۔ اگر آپ gpg کا استعمال کرتے ہوئے انکرپشن کو فعال کرتے ہیں، تو بازیابی کا وقت 15 منٹ اور 3 سیکنڈ تک بڑھ جاتا ہے۔ اس کے علاوہ، کاپیاں ذخیرہ کرنے کے لیے ایک ذخیرہ بناتے وقت، آپ آرکائیو کا سائز بتا سکتے ہیں جو آنے والے ڈیٹا اسٹریم کو تقسیم کرتے وقت استعمال کیا جائے گا۔ عام طور پر، روایتی ہارڈ ڈرائیوز پر، سنگل تھریڈڈ آپریٹنگ موڈ کی وجہ سے بھی زیادہ فرق نہیں ہوتا ہے۔ جب ہائبرڈ اسٹوریج استعمال کیا جاتا ہے تو یہ مختلف بلاک سائز میں ظاہر ہو سکتا ہے۔ ریکوری کے دوران مین سرور پر بوجھ حسب ذیل تھا:

کوئی خفیہ کاری نہیں

خفیہ کاری کے ساتھ

ڈپلیکیٹ 13 منٹ اور 45 سیکنڈ میں اسے مکمل کرتے ہوئے، ایک موازنہ بازیابی کی شرح دکھائی۔ بازیافت شدہ ڈیٹا کی درستگی کی جانچ کرنے میں مزید 5 منٹ لگے (کل تقریباً 19 منٹ)۔ بوجھ تھا۔

کافی اونچا:

جب aes انکرپشن کو اندرونی طور پر فعال کیا گیا تھا، تو ریکوری کا وقت 21 منٹ 40 سیکنڈ تھا، ریکوری کے دوران CPU کے زیادہ سے زیادہ استعمال (دونوں کور!) کے ساتھ؛ ڈیٹا چیک کرتے وقت، صرف ایک دھاگہ فعال تھا، ایک پروسیسر کور پر قابض تھا۔ ریکوری کے بعد ڈیٹا چیک کرنے میں اتنے ہی 5 منٹ لگے (کل تقریباً 27 منٹ)۔

نتیجہ

بیرونی جی پی جی پروگرام کو خفیہ کاری کے لیے استعمال کرتے وقت ڈپلیکٹی ریکوری کے ساتھ تھوڑا تیز تھا، لیکن عام طور پر پچھلے موڈ سے فرق کم سے کم ہوتا ہے۔ آپریٹنگ ٹائم 16 منٹ 30 سیکنڈ تھا، 6 منٹ میں ڈیٹا کی تصدیق کے ساتھ۔ بوجھ تھا۔

اس طرح:

آمنداٹار کا استعمال کرتے ہوئے، اسے 2 منٹ 49 سیکنڈ میں مکمل کیا، جو اصولی طور پر ریگولر ٹار کے بہت قریب ہے۔ اصولی طور پر سسٹم پر لوڈ کریں۔

ایسا ہی:

استعمال کرتے ہوئے بیک اپ بحال کرتے وقت zbackup مندرجہ ذیل نتائج حاصل کیے گئے:

خفیہ کاری، lzma کمپریشن

رننگ ٹائم 11 منٹ اور 8 سیکنڈ

AES انکرپشن، lzma کمپریشن

آپریٹنگ ٹائم 14 منٹ

AES انکرپشن، lzo کمپریشن

رننگ ٹائم 6 منٹ، 19 سیکنڈ

مجموعی طور پر، برا نہیں. یہ سب بیک اپ سرور پر پروسیسر کی رفتار پر منحصر ہے، جسے مختلف کمپریسرز کے ساتھ پروگرام کے چلنے کے وقت سے واضح طور پر دیکھا جا سکتا ہے۔ بیک اپ سرور سائیڈ پر، ایک باقاعدہ ٹار لانچ کیا گیا تھا، لہذا اگر آپ اس کا موازنہ کریں، تو ریکوری 3 گنا سست ہے۔ یہ دو سے زیادہ دھاگوں کے ساتھ ملٹی تھریڈڈ موڈ میں آپریشن کو چیک کرنے کے قابل ہو سکتا ہے۔

بورگ بیک اپ۔ غیر انکرپٹڈ موڈ میں یہ ٹار سے تھوڑا سا سست تھا، 2 منٹ 45 سیکنڈ میں، تاہم، ٹار کے برعکس، ریپوزٹری کو ڈپلیکیٹ کرنا ممکن ہوا۔ بوجھ نکلا۔

مندرجہ ذیل:

اگر آپ بلیک پر مبنی انکرپشن کو فعال کرتے ہیں، تو بیک اپ کی بازیابی کی رفتار قدرے سست ہوتی ہے۔ اس موڈ میں ریکوری کا وقت 3 منٹ 19 سیکنڈ ہے، اور بوجھ ختم ہو گیا ہے۔

اس طرح:

AES انکرپشن قدرے سست ہے، ریکوری کا وقت 3 منٹ 23 سیکنڈ ہے، بوجھ خاص طور پر ہے

تبدیل نہیں ہوا:

چونکہ بورگ ملٹی تھریڈڈ موڈ میں کام کر سکتا ہے، اس لیے پروسیسر کا بوجھ زیادہ سے زیادہ ہوتا ہے، اور جب اضافی فنکشنز کو چالو کیا جاتا ہے، تو آپریٹنگ ٹائم بڑھ جاتا ہے۔ بظاہر، یہ zbackup کی طرح ملٹی تھریڈنگ کو تلاش کرنے کے قابل ہے۔

ریسٹیک وصولی کے ساتھ تھوڑا زیادہ آہستہ سے مقابلہ کیا، آپریٹنگ وقت 4 منٹ 28 سیکنڈ تھا. بوجھ لگ رہا تھا۔

تو:

بظاہر بحالی کا عمل کئی دھاگوں میں کام کرتا ہے، لیکن کارکردگی اتنی زیادہ نہیں ہے جتنی BorgBackup کی ہے، لیکن وقت کے ساتھ اس کا موازنہ باقاعدہ rsync سے کیا جا سکتا ہے۔

کے ساتھ اور بیک بیک 8 منٹ اور 19 سیکنڈ میں ڈیٹا کو بحال کرنا ممکن تھا، لوڈ تھا۔

اس طرح:

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

تقابل کے لیے معیار کا انتخاب اور جواز

جیسا کہ پچھلے مضامین میں سے ایک میں بتایا گیا ہے، بیک اپ سسٹم کو درج ذیل معیارات پر پورا اترنا چاہیے:

• استعمال میں آسانی
• استرتا
• استحکام
• سپیڈ

ہر ایک نکتے پر مزید تفصیل سے غور کرنے کے قابل ہے۔

آپریشن میں آسانی

یہ سب سے بہتر ہے جب ایک بٹن ہو "ہر چیز اچھی طرح سے کرو"، لیکن اگر آپ حقیقی پروگراموں پر واپس آتے ہیں، تو سب سے آسان چیز کچھ مانوس اور معیاری آپریٹنگ اصول ہوگی۔
زیادہ تر صارفین زیادہ تر بہتر ہوں گے اگر انہیں cli کے لیے کلیدوں کا ایک گروپ یاد رکھنا، ویب یا tui کے ذریعے مختلف، اکثر غیر واضح اختیارات کا ایک گروپ ترتیب دینا، یا ناکام آپریشن کے بارے میں اطلاعات مرتب کرنے کی ضرورت نہیں ہے۔ اس میں موجودہ انفراسٹرکچر میں بیک اپ حل کو آسانی سے "فٹ" کرنے کی صلاحیت کے ساتھ ساتھ بیک اپ کے عمل کی آٹومیشن بھی شامل ہے۔ پیکیج مینیجر کا استعمال کرتے ہوئے، یا "ڈاؤن لوڈ اور پیک کھولیں" جیسے ایک یا دو کمانڈز میں انسٹالیشن کا بھی امکان ہے۔ curl ссылка | sudo bash - ایک پیچیدہ طریقہ، کیونکہ آپ کو چیک کرنے کی ضرورت ہے کہ لنک کے ذریعے کیا آتا ہے۔

مثال کے طور پر، زیر غور امیدواروں میں سے، ایک آسان حل ہے burp، rdiff-backup اور restic، جس میں مختلف آپریٹنگ طریقوں کے لیے یادداشت کی کلیدیں ہوتی ہیں۔ قدرے زیادہ پیچیدہ بورگ اور دوہری ہیں۔ سب سے مشکل AMANDA تھی۔ باقی استعمال میں آسانی کے لحاظ سے درمیان میں کہیں ہیں۔ کسی بھی صورت میں، اگر آپ کو یوزر مینوئل کو پڑھنے کے لیے 30 سیکنڈ سے زیادہ کا وقت درکار ہے، یا آپ کو گوگل یا کسی اور سرچ انجن پر جانے کی ضرورت ہے، اور مدد کی ایک لمبی شیٹ کے ذریعے اسکرول کرنے کی بھی ضرورت ہے، تو فیصلہ مشکل ہے، کسی نہ کسی طریقے سے۔

جن امیدواروں پر غور کیا گیا ان میں سے کچھ خود بخود ای میل جبر کے ذریعے پیغام بھیجنے کے قابل ہیں، جبکہ دیگر سسٹم میں ترتیب شدہ الرٹس پر انحصار کرتے ہیں۔ مزید یہ کہ اکثر پیچیدہ حلوں میں مکمل طور پر واضح الرٹ سیٹنگز نہیں ہوتی ہیں۔ کسی بھی صورت میں، اگر بیک اپ پروگرام ایک غیر صفر ریٹرن کوڈ تیار کرتا ہے، جسے وقتا فوقتا کاموں کے لیے سسٹم سروس کے ذریعے درست طریقے سے سمجھا جائے گا (ایک پیغام سسٹم ایڈمنسٹریٹر کو یا براہ راست نگرانی کے لیے بھیجا جائے گا) - صورت حال آسان ہے۔ لیکن اگر بیک اپ سسٹم، جو بیک اپ سرور پر نہیں چلتا ہے، کو کنفیگر نہیں کیا جا سکتا، تو اس مسئلے کے بارے میں کہنے کا واضح طریقہ یہ ہے کہ پیچیدگی پہلے ہی بہت زیادہ ہے۔ کسی بھی صورت میں، صرف ویب انٹرفیس یا لاگ کو وارننگز اور دیگر پیغامات جاری کرنا ایک برا عمل ہے، کیونکہ اکثر انہیں نظر انداز کر دیا جائے گا۔

جہاں تک آٹومیشن کا تعلق ہے، ایک سادہ پروگرام ماحولیاتی متغیرات کو پڑھ سکتا ہے جو اس کا آپریٹنگ موڈ سیٹ کرتا ہے، یا اس میں ایک ترقی یافتہ کلی ہے جو ویب انٹرفیس کے ذریعے کام کرتے وقت رویے کو مکمل طور پر نقل کر سکتی ہے، مثال کے طور پر۔ اس میں مسلسل آپریشن کا امکان، توسیع کے مواقع کی دستیابی وغیرہ بھی شامل ہے۔

استرتا

جزوی طور پر آٹومیشن کے حوالے سے پچھلے ذیلی حصے کی بازگشت کرتے ہوئے، موجودہ انفراسٹرکچر میں بیک اپ کے عمل کو "فٹ" کرنا کوئی خاص مسئلہ نہیں ہونا چاہیے۔
یہ بات قابل غور ہے کہ کام کے لیے غیر معیاری بندرگاہوں (اچھی طرح سے، ویب انٹرفیس کے علاوہ) کا استعمال، غیر معیاری طریقے سے انکرپشن کا نفاذ، غیر معیاری پروٹوکول کا استعمال کرتے ہوئے ڈیٹا کا تبادلہ غیر معیاری ہونے کی علامات ہیں۔ - عالمگیر حل. زیادہ تر حصے کے لیے، تمام امیدواروں کے پاس کسی نہ کسی وجہ سے واضح وجہ ہے: سادگی اور استعداد عام طور پر ایک ساتھ نہیں ہوتے۔ ایک استثناء کے طور پر - burp، اور بھی ہیں.

ایک نشانی کے طور پر - باقاعدہ ssh کا استعمال کرتے ہوئے کام کرنے کی صلاحیت۔

کام کی رفتار

سب سے متنازعہ اور متنازعہ نکتہ۔ ایک طرف، ہم نے عمل شروع کیا، اس نے جلد سے جلد کام کیا اور اہم کاموں میں مداخلت نہیں کی۔ دوسری طرف، بیک اپ کی مدت کے دوران ٹریفک اور پروسیسر کے بوجھ میں اضافہ ہوتا ہے۔ یہ بات بھی قابل غور ہے کہ کاپیاں بنانے کے لیے تیز ترین پروگرام عام طور پر فنکشنز کے لحاظ سے سب سے غریب ہوتے ہیں جو صارفین کے لیے اہم ہوتے ہیں۔ ایک بار پھر: اگر پاس ورڈ کے ساتھ کئی دسیوں بائٹس کے سائز کی ایک بدقسمتی ٹیکسٹ فائل حاصل کرنے کے لیے، اور اس کی وجہ سے پوری سروس کی لاگت آتی ہے (ہاں، ہاں، میں سمجھتا ہوں کہ بیک اپ کا عمل اکثر یہاں قصوروار نہیں ہے)، اور آپ کو ریپوزٹری میں موجود تمام فائلوں کو ترتیب وار دوبارہ پڑھنے کی ضرورت ہے یا پوری آرکائیو کو پھیلانا ہوگا - بیک اپ سسٹم کبھی تیز نہیں ہوتا ہے۔ ایک اور نکتہ جو اکثر رکاوٹ بن جاتا ہے وہ ہے آرکائیو سے بیک اپ کی تعیناتی کی رفتار۔ یہاں ان لوگوں کے لیے ایک واضح فائدہ ہے جو بہت زیادہ ہیرا پھیری کے بغیر فائلوں کو آسانی سے کاپی یا مطلوبہ مقام پر منتقل کر سکتے ہیں (مثال کے طور پر rsync)، لیکن اکثر مسئلہ کو تنظیمی طریقے سے حل کیا جانا چاہیے، تجرباتی طور پر: بیک اپ ریکوری کے وقت کی پیمائش کر کے اور صارفین کو اس بارے میں کھلے عام مطلع کرنا۔

استحکام

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

بیک اپ ٹولز کا موازنہ

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

Rsync
4 ایم 15s
4 ایم 28s
جی ہاں
нет
нет
нет
جی ہاں
нет
нет
جی ہاں
нет
جی ہاں
جی ہاں
нет
нет
нет
нет
нет
جی ہاں
6

ٹار۔
پاک
3 ایم 12s
2 ایم 43s
جی ہاں
нет
нет
нет
нет
нет
جی ہاں
جی ہاں
нет
جی ہاں
нет
нет
нет
нет
нет
нет
جی ہاں
8,5

gzip
9 ایم 37s
3 ایم 19s
جی ہاں

Rdiff بیک اپ
16 ایم 26s
17 ایم 17s
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
нет
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
11

آر نیپ شاٹ
4 ایم 19s
4 ایم 28s
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
нет
جی ہاں
нет
جی ہاں
нет
جی ہاں
нет
нет
جی ہاں
جی ہاں
нет
جی ہاں
12,5

برپ
11 ایم 9s
7 ایم 2s
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
جی ہاں
нет
нет
جی ہاں
нет
جی ہاں
нет
جی ہاں
10,5

نقل
کوئی خفیہ کاری نہیں
16 ایم 48s
10 ایم 58s
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
جی ہاں
нет
нет
جی ہاں
нет
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
11

جی پی پی
17 ایم 27s
15 ایم 3s

ڈپلیکیٹ
کوئی خفیہ کاری نہیں
20 ایم 28s
13 ایم 45s
нет
جی ہاں
нет
нет
нет
جی ہاں
جی ہاں
нет
нет
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
11

یئایس
29 ایم 41s
21 ایم 40s

جی پی پی
26 ایم 19s
16 ایم 30s

زیب بیک
کوئی خفیہ کاری نہیں
40 ایم 3s
11 ایم 8s
جی ہاں
جی ہاں
нет
нет
нет
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
нет
нет
нет
10

یئایس
42 ایم 0s
14 ایم 1s

aes+lzo
18 ایم 9s
6 ایم 19s

بورگ بیک اپ۔
کوئی خفیہ کاری نہیں
4 ایم 7s
2 ایم 45s
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
16

یئایس
4 ایم 58s
3 ایم 23s

بلیک 2۔
4 ایم 39s
3 ایم 19s

ریسٹیک
5 ایم 38s
4 ایم 28s
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
нет
جی ہاں
جی ہاں
15,5

اور بیک بیک
8 ایم 21s
8 ایم 19s
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
нет
جی ہاں
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
12

Amanda
9 ایم 3s
2 ایم 49s
جی ہاں
нет
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
13

بیک اپ پی سی
rsync
12 ایم 22s
7 ایم 42s
جی ہاں
нет
جی ہاں
جی ہاں
جی ہاں
جی ہاں
جی ہاں
нет
جی ہاں
нет
нет
جی ہاں
جی ہاں
нет
جی ہاں
нет
جی ہاں
10,5

ٹار
12 ایم 34s
12 ایم 15s

ٹیبل لیجنڈ:

• سبز، آپریٹنگ ٹائم پانچ منٹ سے کم، یا جواب "ہاں" (ماسوائے کالم "کلائنٹ سرور کی ضرورت ہے؟" کے)، 1 پوائنٹ
• پیلا، آپریٹنگ وقت پانچ سے دس منٹ، 0.5 پوائنٹس
• سرخ، کام کا وقت دس منٹ سے زیادہ ہے، یا جواب ہے "نہیں" (سوائے کالم "کیا آپ کو کلائنٹ سرور کی ضرورت ہے؟")، 0 پوائنٹس

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

میں ہر اس شخص کا شکریہ ادا کرتا ہوں جنہوں نے سیریز کو آخر تک پڑھا، میں آپ کو آپشنز پر تبادلہ خیال کرنے اور اگر کوئی ہے تو اپنی پیشکش کرنے کی دعوت دیتا ہوں۔ جیسے جیسے بحث آگے بڑھتی ہے، میز کو بڑھایا جا سکتا ہے۔

سیریز کا نتیجہ حتمی مضمون ہو گا، جس میں ایک مثالی، تیز اور قابل انتظام بیک اپ ٹول تیار کرنے کی کوشش کی جائے گی جو آپ کو کم سے کم وقت میں ایک کاپی واپس تعینات کرنے کی اجازت دیتا ہے اور ساتھ ہی ساتھ آسان اور آسان بھی۔ ترتیب دینے اور برقرار رکھنے کے لیے۔

اعلان

بیک اپ، حصہ 1: بیک اپ کی ضرورت کیوں ہے، طریقوں، ٹیکنالوجیز کا جائزہ
بیک اپ، حصہ 2: rsync پر مبنی بیک اپ ٹولز کا جائزہ اور جانچ
بیک اپ حصہ 3: نقل کا جائزہ اور جانچ، نقل
بیک اپ حصہ 4: Zbackup، restic، borgbackup جائزہ اور جانچ
بیک اپ، حصہ 5: لینکس کے لیے بیکولا اور ویم بیک اپ کی جانچ
بیک اپ حصہ 6: بیک اپ ٹولز کا موازنہ
بیک اپ حصہ 7: نتائج

ماخذ: www.habr.com