دا بیاکتنه دوام لري
د UrBackup بیاکتنه.
د ګډون کونکي په غوښتنه
په بشپړ بیک اپ حالت کې، لاندې پایلې ترلاسه شوې:
د کار ساعتونه:
لومړی پیل
دوهم لانچ
دریم لانچ
لومړی ازموینه
8m20s
8m19s
8m24s
دوهمه ازموینه
8m30s
8m34s
8m20s
دریمه ازموینه
8m10s
8m14s
8m12s
په زیاتیدونکي بیک اپ حالت کې:
د کار ساعتونه:
لومړی پیل
دوهم لانچ
دریم لانچ
لومړی ازموینه
8m10s
8m10s
8m12s
دوهمه ازموینه
3m50s
4m12s
3m34s
دریمه ازموینه
2m50s
2m35s
2m38s
په دواړو قضیو کې د ذخیره کولو اندازه نږدې 14 GB وه، کوم چې د سرور اړخ کې د کار تخریب په ګوته کوي. دا هم باید په پام کې ونیول شي چې په سرور او پیرودونکي کې د بیک اپ رامینځته کولو وخت ترمینځ توپیر شتون لري ، کوم چې د ګرافونو څخه په څرګند ډول څرګندیږي او یو خورا خوندور بونس دی ، ځکه چې ویب انٹرفیس د بیک اپ پروسې چلولو وخت ښیې. د سرور اړخ په پام کې نیولو پرته
د پیرودونکي حالت. په عموم کې، د بشپړ او زیاتیدونکي کاپي لپاره ګرافونه د توپیر وړ ندي. یوازینی توپیر شاید دا دی چې دا څنګه د سرور اړخ کې اداره کیږي. زه په بې ځایه سیسټم کې د ټیټ پروسیسر بار څخه هم خوښ وم.
د بیک اپ پی سی بیاکتنه
د ګډون کونکي په غوښتنه
د rsync سره د بشپړ بیک اپ جوړولو په حالت کې، لاندې پایلې ترلاسه شوې:
لومړی پیل
دوهم لانچ
دریم لانچ
لومړی ازموینه
12m25s
12m14s
12m27s
دوهمه ازموینه
7m41s
7m44s
7m35s
دریمه ازموینه
10m11s
10m0s
9m54s
که تاسو بشپړ بیک اپ او ټار کاروئ:
لومړی پیل
دوهم لانچ
دریم لانچ
لومړی ازموینه
12m41s
12m25s
12m45s
دوهمه ازموینه
12m35s
12m45s
12m14s
دریمه ازموینه
12m43s
12m25s
12m5s
په زیاتیدونکي بیک اپ حالت کې ، ما باید ټار پریږدي ځکه چې بیک اپ د دې تنظیماتو سره ندي رامینځته شوي.
د rsync په کارولو سره د زیاتیدونکي بیک اپ رامینځته کولو پایلې په لاندې ډول دي:
لومړی پیل
دوهم لانچ
دریم لانچ
لومړی ازموینه
11m55s
11m50s
12m25s
دوهمه ازموینه
2m42s
2m50s
2m30s
دریمه ازموینه
6m00s
5m35s
5m30s
په عموم کې، rsync لږ سرعت ګټه لري؛ rsync هم د شبکې سره ډیر اقتصادي کار کوي. دا کیدای شي په یوه برخه کې د بیک اپ پروګرام په توګه د tar سره د لږ CPU کارولو له لارې تنظیم شي. د rsync بله ګټه دا ده چې دا د زیاتیدونکي کاپيونو سره کار کوي. د بشپړ بیک اپ رامینځته کولو په وخت کې د ذخیره کولو اندازه ورته ده ، 16 GB ، د زیاتیدونکي کاپيونو په حالت کې - 14 GB په هر چل کې ، پدې معنی چې د کار تخریب کول.
د AMANDA بیاکتنه
د ګډون کونکي په غوښتنه
د ټار سره د ازموینې پایلې لکه څنګه چې آرشیور او کمپریشن فعال شوی په لاندې ډول دي:
لومړی پیل
دوهم لانچ
دریم لانچ
لومړی ازموینه
9m5s
8m59s
9m6s
دوهمه ازموینه
0m5s
0m5s
0m5s
دریمه ازموینه
2m40s
2m47s
2m45s
برنامه په بشپړ ډول یو پروسیسر کور بار کوي ، مګر د بیک اپ ذخیره کولو سرور اړخ کې د IOPS ډیسک محدودیت له امله ، دا نشي کولی د ډیټا لیږد لوړ سرعت ترلاسه کړي. په عموم کې ، تنظیم د نورو برخه اخیستونکو په پرتله یو څه ډیر ستونزمن و ، ځکه چې د برنامې لیکوال ssh د ټرانسپورټ په توګه نه کاروي ، مګر د کیلي سره ورته سکیم پلي کوي ، د بشپړ CA رامینځته کول او ساتل. دا ممکنه ده چې پیرودونکي او بیک اپ سرور په پراخه کچه محدود کړئ: د مثال په توګه ، که دوی نشي کولی په بشپړ ډول یو بل باور وکړي ، نو تاسو کولی شئ د یو اختیار په توګه ، د اړوند متغیر ارزښت صفر ته په ترتیب کولو سره سرور د بیک اپ بیا رغونې پیل کولو مخه ونیسئ. د ترتیباتو فایل. دا ممکنه ده چې د مدیریت لپاره ویب انٹرفیس سره وصل کړئ، مګر په عمومي توګه ترتیب شوی سیسټم د کوچنیو باش سکریپټونو (یا SCM، د مثال په توګه د ځواب وړ) په کارولو سره په بشپړ ډول اتومات کیدی شي. د ذخیره کولو تنظیم کولو لپاره یو څه غیر معمولي سیسټم شتون لري ، کوم چې په ښکاره ډول د ډیټا ذخیره کولو لپاره د مختلف وسیلو پراخه لیست لپاره د ملاتړ له امله دی (LTO کیسټونه ، هارډ ډرایو او نور). دا هم د یادولو وړ ده چې پدې مقاله کې د بحث شوي ټولو برنامو څخه ، AMANDA یوازینی دی چې د لارښود نوم بدلولو موندلو توان درلود. د یوې منډې لپاره د ذخیره اندازه 13 GB وه.
اعلامیه
د بیک اپ برخه 6: د بیک اپ وسیلو پرتله کول
بیک اپ برخه 7: پایلې
سرچینه: www.habr.com