یہ نوٹ جاری ہے۔
بیک اپ کے بارے میں سائیکل
- بیک اپ حصہ 2: rsync پر مبنی بیک اپ ٹولز کا جائزہ اور جانچ
- بیک اپ حصہ 3: نقل، نقل، ڈیجا ڈوپ کا جائزہ اور جانچ
- بیک اپ حصہ 4: Zbackup، restic، borgbackup جائزہ اور جانچ
- بیک اپ، حصہ 5: لینکس کے لیے بیکولا اور ویم بیک اپ کی جانچ
- بیک اپ حصہ 6: بیک اپ ٹولز کا موازنہ
- بیک اپ حصہ 7: نتائج
جیسا کہ ہم پہلے مضمون میں لکھ چکے ہیں، rsync پر مبنی بیک اپ پروگرامز کی ایک بہت بڑی تعداد موجود ہے۔
ان میں سے جو ہمارے حالات کے مطابق ہیں، میں 3 پر غور کروں گا: rdiff-backup، rsnapshot اور burp۔
ٹیسٹ فائل سیٹ
ٹیسٹنگ فائل سیٹ تمام امیدواروں کے لیے یکساں ہوں گے، بشمول مستقبل کے مضامین۔
پہلا سیٹ: 10 GB میڈیا فائلیں، اور تقریباً 50 MB - PHP میں سائٹ کا سورس کوڈ، فائل کا سائز سورس کوڈ کے لیے کئی کلو بائٹس سے، میڈیا فائلوں کے لیے دسیوں میگا بائٹس تک۔ مقصد ایک جامد سائٹ کی نقل کرنا ہے۔
دوسرا سیٹ: 5 GB میڈیا فائلوں کے ساتھ ذیلی ڈائرکٹری کا نام تبدیل کرتے وقت پہلے سے حاصل کیا گیا۔ مقصد یہ ہے کہ ڈائریکٹری کا نام تبدیل کرتے وقت بیک اپ سسٹم کے رویے کا مطالعہ کیا جائے۔
تیسرا سیٹ: 3GB میڈیا فائلوں کو حذف کرکے اور نئی 3GB میڈیا فائلوں کو شامل کرکے پہلے سے حاصل کیا گیا۔ مقصد ایک عام سائٹ اپ ڈیٹ آپریشن کے دوران بیک اپ سسٹم کے رویے کا مطالعہ کرنا ہے۔
نتائج حاصل کرنا
کوئی بھی بیک اپ کم از کم 3 بار انجام دیا جاتا ہے اور اس کے ساتھ فائل سسٹم کیچز کو کمانڈز کے ساتھ ری سیٹ کرنا ہوتا ہے۔ sync и echo 3 > /proc/sys/vm/drop_caches ٹیسٹ سرور اور بیک اپ اسٹوریج سرور دونوں طرف۔
سرور پر جو بیک اپ کا ذریعہ ہوگا، نگرانی سافٹ ویئر انسٹال ہے - نیٹ ڈیٹا، جس کی مدد سے کاپی کرنے کے دوران سرور پر بوجھ کا اندازہ لگایا جائے گا، بیک اپ کے عمل کے دوران سرور پر بوجھ کا اندازہ کرنے کے لیے یہ ضروری ہے۔
میں یہ بھی مانتا ہوں کہ بیک اپ اسٹوریج سرور پروسیسر کے لحاظ سے مین سرور کے مقابلے میں سست ہے، لیکن اس میں نسبتاً کم رینڈم رائٹ اسپیڈ کے ساتھ زیادہ گنجائش والی ڈسکیں ہیں - بیک اپ کے دوران سب سے عام صورت حال، اور اس حقیقت کی وجہ سے کہ بیک اپ سرور کو نہیں ہونا چاہیے۔ میں صحیح طریقے سے بیک اپ کے علاوہ دوسرے کاموں کو ٹریک نہیں کروں گا، نیٹ ڈیٹا کا استعمال کرتے ہوئے اس کا بوجھ۔
میں نے سرورز کو بھی تبدیل کر دیا ہے جس پر میں بیک اپ کے لیے مختلف سسٹمز کو چیک کروں گا۔
اب ان میں درج ذیل خصوصیات ہیں۔پروسیسر
sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 2
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 1081.62
General statistics:
total time: 30.0013s
total number of events: 32453
Latency (ms):
min: 1.48
avg: 1.85
max: 9.84
95th percentile: 2.07
sum: 59973.40
Threads fairness:
events (avg/stddev): 16226.5000/57.50
execution time (avg/stddev): 29.9867/0.00
رام، پڑھنا...
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads...
Threads started!
Total operations: 104857600 (5837637.63 per second)
102400.00 MiB transferred (5700.82 MiB/sec)
General statistics:
total time: 17.9540s
total number of events: 104857600
Latency (ms):
min: 0.00
avg: 0.00
max: 66.08
95th percentile: 0.00
sum: 18544.64
Threads fairness:
events (avg/stddev): 26214400.0000/0.00
execution time (avg/stddev): 4.6362/0.12
...اور ریکارڈنگ
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads...
Threads started!
Total operations: 91414596 (3046752.56 per second)
89272.07 MiB transferred (2975.34 MiB/sec)
General statistics:
total time: 30.0019s
total number of events: 91414596
Latency (ms):
min: 0.00
avg: 0.00
max: 1022.90
95th percentile: 0.00
sum: 66430.91
Threads fairness:
events (avg/stddev): 22853649.0000/945488.53
execution time (avg/stddev): 16.6077/1.76
ڈیٹا سورس سرور پر ڈسک
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 4587.95
writes/s: 3058.66
fsyncs/s: 9795.73
Throughput:
read, MiB/s: 17.92
written, MiB/s: 11.95
General statistics:
total time: 60.0241s
total number of events: 1046492
Latency (ms):
min: 0.00
avg: 0.23
max: 14.45
95th percentile: 0.94
sum: 238629.34
Threads fairness:
events (avg/stddev): 261623.0000/1849.14
execution time (avg/stddev): 59.6573/0.00
بیک اپ اسٹوریج سرور پر ڈسک
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Initializing random number generator from current time
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads...
Threads started!
File operations:
reads/s: 11.37
writes/s: 7.58
fsyncs/s: 29.99
Throughput:
read, MiB/s: 0.04
written, MiB/s: 0.03
General statistics:
total time: 73.8868s
total number of events: 3104
Latency (ms):
min: 0.00
avg: 78.57
max: 3840.90
95th percentile: 297.92
sum: 243886.02
Threads fairness:
events (avg/stddev): 776.0000/133.26
execution time (avg/stddev): 60.9715/1.59
سرورز کے درمیان نیٹ ورک کی رفتار
iperf3 -c backup
Connecting to host backup, port 5201
[ 4] local x.x.x.x port 59402 connected to y.y.y.y port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes
[ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes
[ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes
[ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes
[ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes
[ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes
[ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes
[ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes
[ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes
[ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender
[ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver
ٹیسٹ کا طریقہ کار
- ٹیسٹ سرور پر، پہلے ٹیسٹ سیٹ کے ساتھ ایک فائل سسٹم تیار کیا جاتا ہے، اور بیک اپ سٹوریج سرور پر، اگر ضروری ہو تو، ذخیرہ شروع کیا جاتا ہے۔
بیک اپ کا عمل شروع ہوتا ہے اور اس کا وقت ناپا جاتا ہے۔ - ٹیسٹ سرور پر، فائلوں کو دوسرے ٹیسٹ سیٹ پر منتقل کیا جاتا ہے۔ بیک اپ کا عمل شروع ہوتا ہے اور اس کا وقت ناپا جاتا ہے۔
- ٹیسٹ سرور پر، منتقلی تیسرے ٹیسٹ سیٹ تک کی جاتی ہے۔ بیک اپ کا عمل شروع ہوتا ہے اور اس کا وقت ناپا جاتا ہے۔
- نتیجے میں تیسرے ٹیسٹ سیٹ کو نئے پہلے کے طور پر قبول کیا جاتا ہے۔ مرحلہ 1-3 مزید 2 بار دہرایا جاتا ہے۔
- ڈیٹا کو پیوٹ ٹیبل میں داخل کیا جاتا ہے، اور نیٹ ڈیٹا کے ساتھ گراف شامل کیے جاتے ہیں۔
- انفرادی بیک اپ کے طریقہ کار کے لیے ایک رپورٹ تیار کی جاتی ہے۔
متوقع نتائج
چونکہ تمام 3 امیدوار ایک ہی ٹیکنالوجی (rsync) پر مبنی ہیں، اس لیے توقع کی جاتی ہے کہ نتائج باقاعدہ rsync کے قریب ہوں گے، بشمول اس کے تمام فوائد، یعنی:
- ریپوزٹری میں فائلوں کو "جیسے ہے" محفوظ کیا جائے گا۔
- ریپوزٹری کا سائز صرف بیک اپ کے درمیان فرق سمیت بڑھے گا۔
- ڈیٹا کی منتقلی کے وقت نیٹ ورک پر نسبتاً بڑا بوجھ ہو گا، ساتھ ہی پروسیسر پر ایک چھوٹا بوجھ بھی پڑے گا۔
ریگولر rsync کا ٹیسٹ رن بطور حوالہ استعمال کیا جائے گا، اس کے نتائج
یہ ہیں
رکاوٹ ایک HDD پر مبنی ڈسک کی شکل میں بیک اپ ڈیٹا اسٹوریج سرور پر تھی، جو آری ٹوتھ گراف میں واضح طور پر نظر آتی ہے۔
ڈیٹا کو 4 منٹ اور 15 سیکنڈ میں کاپی کیا گیا۔
rdiff بیک اپ کی جانچ کرنا
پہلا امیدوار rdiff-backup ہے، ایک ازگر کا اسکرپٹ جو ایک ڈائرکٹری کو دوسری میں بیک اپ کرتا ہے۔ اس صورت میں، موجودہ بیک اپ کاپی کو "جیسا ہے" محفوظ کیا جاتا ہے، اور پہلے کی گئی بیک اپ کاپیاں ایک خاص ذیلی ڈائرکٹری میں بتدریج ذخیرہ کی جاتی ہیں، اور اس طرح جگہ کی بچت ہوتی ہے۔
ہم عام آپریٹنگ موڈ کو چیک کریں گے، یعنی بیک اپ کے عمل کا آغاز کلائنٹ خود کرتا ہے، اور بیک اپ کے لیے سرور کی طرف، ایک ایسا عمل شروع کیا جاتا ہے جو ڈیٹا وصول کرتا ہے۔
آئیے ایک نظر ڈالتے ہیں، وہ ہمارے حالات میں کیا کر سکتا ہے؟.
ہر ٹیسٹ رن کا رننگ ٹائم:
پہلا آغاز
دوسری لانچ
تیسری لانچ
پہلا سیٹ
16 ایم 32s
16 ایم 26s
16 ایم 19s
دوسرا سیٹ
2h5 م
2h10 م
2h8 م
تیسرا سیٹ
2h9 م
2h10 م
2h10 م
Rdiff-backup ڈیٹا میں کسی بھی بڑی تبدیلی پر بہت تکلیف دہ ردعمل ظاہر کرتا ہے، اور نیٹ ورک کو مکمل طور پر استعمال نہیں کرتا ہے۔
آر ایس نیپ شاٹ ٹیسٹنگ
دوسرا امیدوار، rsnapshot، ایک پرل اسکرپٹ ہے جس کے مؤثر آپریشن کے لیے بنیادی ضرورت ہارڈ لنکس کی حمایت ہے۔ یہ ڈسک کی جگہ بچاتا ہے۔ اس صورت میں، وہ فائلیں جو پچھلے بیک اپ کے بعد تبدیل نہیں ہوئی ہیں، ہارڈ لنکس کا استعمال کرتے ہوئے اصل فائل سے منسلک ہو جائیں گی۔
بیک اپ کے عمل کی منطق بھی الٹی ہے: سرور فعال طور پر اپنے کلائنٹس کے درمیان "چلتا ہے" اور ڈیٹا لیتا ہے۔
امتحانی نتائج
مندرجہ ذیل باہر کر دیا
پہلا آغاز
دوسری لانچ
تیسری لانچ
پہلا سیٹ
4 ایم 22s
4 ایم 19s
4 ایم 16s
دوسرا سیٹ
2 ایم 6s
2 ایم 10s
2 ایم 6s
تیسرا سیٹ
1 ایم 18s
1 ایم 10s
1 ایم 10s
اس نے بہت، بہت تیزی سے، rdiff-backup سے بہت تیز اور خالص rsync کے بہت قریب کام کیا۔
برپ ٹیسٹنگ
ایک اور آپشن librsync - burp کے اوپر C کا نفاذ ہے، جس میں کلائنٹ کی اجازت کے ساتھ ساتھ ایک ویب انٹرفیس (بنیادی پیکیج میں شامل نہیں) سمیت کلائنٹ-سرور کا فن تعمیر ہے۔ ایک اور دلچسپ خصوصیت کلائنٹ سائیڈ نان ریکوری بیک اپ ہے۔
آئیے ایک نظر ڈالتے ہیں۔کارکردگی.
پہلا آغاز
دوسری لانچ
تیسری لانچ
پہلا سیٹ
11 ایم 21s
11 ایم 10s
10 ایم 56s
دوسرا سیٹ
5 ایم 37s
5 ایم 40s
5 ایم 35s
تیسرا سیٹ
3 ایم 33s
3 ایم 24s
3 ایم 40s
اس نے rsnapshot سے 2 گنا سست کام کیا، لیکن پھر بھی کافی تیز، اور یقینی طور پر rdiff-backup سے تیز۔ گرافس تھوڑا سا سا ٹوتھ ہیں - کارکردگی ایک بار پھر بیک اپ اسٹوریج سرور کے ڈسک سب سسٹم پر منحصر ہے، حالانکہ یہ اتنا واضح نہیں ہے جتنا rsnapshot کے ساتھ۔
نتائج
تمام امیدواروں کے لیے مخزنوں کا سائز تقریباً ایک جیسا تھا، یعنی پہلے 10 GB تک بڑھنا، پھر 15 GB تک بڑھنا، پھر 18 GB تک بڑھنا، وغیرہ، جو rsync کی خاصیت کی وجہ سے ہے۔ یہ بات بھی قابل توجہ ہے کہ تمام امیدوار سنگل تھریڈڈ ہیں (دوہری کور مشین پر پروسیسر کا بوجھ تقریباً 50% ہے)۔ تمام 3 امیدواروں نے آخری بیک اپ "جیسا ہے" کو بحال کرنے کی صلاحیت فراہم کی، یعنی، کسی بھی فریق ثالث کے پروگراموں کو استعمال کیے بغیر فائلوں کو بحال کرنا ممکن تھا، بشمول ریپوزٹری بنانے کے لیے استعمال کیے جانے والے۔ یہ rsync کی "آبائی میراث" بھی ہے۔
نتائج
بیک اپ سسٹم جتنا پیچیدہ ہوگا اور اس میں جتنی زیادہ مختلف صلاحیتیں ہوں گی، یہ اتنی ہی سست رفتار سے کام کرے گا، لیکن بہت زیادہ ڈیمانڈ والے پروجیکٹس کے لیے ان میں سے کوئی بھی موزوں نہیں ہوگا، سوائے شاید، rdiff-backup کے۔
اعلان
یہ نوٹ بیک اپ کے سلسلے کو جاری رکھتا ہے۔
بیک اپ، حصہ 2: rsync پر مبنی بیک اپ ٹولز کا جائزہ اور جانچ
بیک اپ حصہ 3: نقل، نقل، ڈیجا ڈوپ کا جائزہ اور جانچ
بیک اپ حصہ 4: Zbackup، restic، borgbackup جائزہ اور جانچ
بیک اپ، حصہ 5: لینکس کے لیے بیکولا اور ویم بیک اپ کی جانچ
بیک اپ حصہ 6: بیک اپ ٹولز کا موازنہ
بیک اپ حصہ 7: نتائج
اشاعت کے مصنف: Pavel Demkovich
ماخذ: www.habr.com