د شاتړ برخه 3: د نقل بیاکتنه او ازموینه

دا یادښت د بیک اپ وسیلو په اړه بحث کوي چې په بیک اپ سرور کې د آرشیفونو په جوړولو سره بیک اپ ترسره کوي.

د هغو په منځ کې چې اړتیاوې پوره کوي دوه اړخیز (کوم چې د ډیجا ډوپ په بڼه یو ښه انٹرفیس لري) او نقل دي.

یو بل خورا د پام وړ بیک اپ وسیله ډار دی، مګر دا چې دا د اختیارونو خورا پراخه لیست لري - د ازموینې میتودولوژي یوازې د هغه څه 10٪ پوښي چې دا یې وړتیا لري - موږ دا د اوسني دورې د یوې برخې په توګه نه ازموو.

متوقع پایلې

څرنګه چې دواړه کاندیدان په یو ډول یا بل ډول آرشیفونه رامینځته کوي، منظم تار د لارښود په توګه کارول کیدی شي.

برسیره پردې، موږ به ارزونه وکړو چې د ذخیره کولو سرور کې د ډیټا ذخیره کول د بیک اپ کاپي په جوړولو سره څومره ښه شوي چې یوازې د بشپړ کاپي او د فایلونو اوسني حالت، یا د پخوانیو او اوسني آرشیفونو ترمنځ توپیر لري (زیاتوالی، کمښت، او نور) .

د بیک اپ جوړولو پر مهال چلند:

1. د بیک اپ ذخیره کولو سرور کې د فایلونو نسبتا لږ شمیر (د بیک اپ کاپيونو شمیر یا په GB کې د ډیټا اندازې سره پرتله کول) ، مګر د دوی اندازه خورا لوی ده (له لسګونو څخه تر سلګونو میګابایټ پورې).
2. د ذخیره کولو اندازه به یوازې بدلونونه پکې شامل وي - هیڅ نقل به زیرمه نشي ، نو د ذخیره کولو اندازه به د rsync-based سافټویر په پرتله کوچنۍ وي.
3. د کمپریشن او/یا کوډ کولو کارولو په وخت کې د درنو CPU بار تمه وکړئ، او احتمال لري خورا لوړ شبکه او ډیسک بار وي که چیرې د آرشیف کولو او/یا کوډ کولو پروسه د بیک اپ ذخیره کولو سرور کې روانه وي.

راځئ چې لاندې کمانډ د حوالې ارزښت په توګه پرمخ یوسو:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

د اعدام پایلې په لاندې ډول وې:

د اجرا کولو وخت 3m12s. دا لیدل کیدی شي چې سرعت د بیک اپ ذخیره کولو سرور ډیسک فرعي سیسټم لخوا محدود دی، لکه څنګه چې په مثال کې rsync. یوازې یو څه ګړندی ، ځکه چې ... ثبت کول یو فایل ته ځي.

همچنان ، د کمپریشن ارزولو لپاره ، راځئ چې ورته اختیار پرمخ بوځو ، مګر د بیک اپ سرور اړخ کې کمپریشن فعال کړئ:

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 پروسې د ترلاسه کونکي اړخ کې روانې وې - خنډ بیا یو واحد تار شوی کمپرسور دی ، او د کوچني کوډ کولو سر.

UPD: د bliznezz په غوښتنه زه د pigz سره ازموینې اضافه کوم. که تاسو یوازې کمپرسور کاروئ، نو دا به 6m30s واخلي، که تاسو کوډ کول هم اضافه کړئ، دا به شاوخوا 7m وي. په لاندې ګراف کې ډوب یو غیر فلش شوی ډیسک کیچ دی:

دوه اړخیزه ازموینه

دوه اړخیزه د بیک اپ لپاره د پیتون سافټویر دی چې په ټار فارمیټ کې د کوډ شوي آرشیفونو رامینځته کولو سره.

د زیاتیدونکي آرشیفونو لپاره، librsync کارول کیږي، نو تاسو کولی شئ د بیان شوي چلند تمه وکړئ په لړۍ کې پخوانی پوسټ.

بیک اپ د gnupg په کارولو سره کوډ شوی او لاسلیک کیدی شي، کوم چې مهم دی کله چې د بیک اپ ذخیره کولو لپاره مختلف چمتو کونکي وکاروئ (s3، بیک بلیز، جی ډرایو، او نور)

راځئ وګورو چې پایلې څه دي:

دا هغه پایلې دي چې موږ یې ترلاسه کړې کله چې د کوډ کولو پرته چلیږي

خرابونکی

د هرې ازموینې د چلولو وخت:

1 پیل کړئ
2 پیل کړئ
3 پیل کړئ

16m33s
17m20s
16m30s

8m29s
9m3s
8m45s

5m21s
6m04s
5m53s

او دلته پایلې دي کله چې د gnupg کوډ کول فعال شي، د 2048 بټونو کلیدي اندازې سره:

په ورته ډیټا کې د کار کولو وخت، د کوډ کولو سره:

1 پیل کړئ
2 پیل کړئ
3 پیل کړئ

17m22s
17m32s
17m28s

8m52s
9m13s
9m3s

5m48s
5m40s
5m30s

د بلاک اندازه ښودل شوې - 512 میګابایټ، کوم چې په ګرافونو کې په ښکاره ډول لیدل کیږي؛ د پروسیسر بار په حقیقت کې په 50٪ کې پاتې شو، پدې معنی چې برنامه له یو څخه ډیر پروسیسر کور نه کاروي.

د برنامه د عملیاتو اصول هم په روښانه ډول څرګند دي: دوی د معلوماتو یوه برخه اخیستې ، کمپریس یې کړې او د بیک اپ ذخیره کولو سرور ته یې لیږلې ، کوم چې خورا ورو کیدی شي.
بله ځانګړتیا د برنامه وړاندوینې وړ چلولو وخت دی ، کوم چې یوازې د بدل شوي معلوماتو اندازې پورې اړه لري.

د کوډ کولو وړ کول د برنامه چلولو وخت کې د پام وړ زیاتوالی ندی راوستی ، مګر دا د پروسیسر بار شاوخوا 10٪ ډیر کړی ، کوم چې خورا ښه بونس کیدی شي.

له بده مرغه، دا برنامه ونشو کولی د لارښود نوم بدلولو سره وضعیت په سمه توګه کشف کړي، او د پایلې ذخیره اندازه د بدلونونو اندازې سره مساوي شوه (د بیلګې په توګه، ټول 18GB)، مګر په واضح ډول د بیک اپ لپاره د بې باوره سرور کارولو وړتیا دا چلند پوښي.

دوه اړخیزه ازموینه

دا سافټویر په C# کې لیکل شوی او د مونو څخه د کتابتونونو سیټ په کارولو سره چلیږي. دلته د GUI او همدارنګه د CLI نسخه شتون لري.

د اصلي ب featuresو نږدې لیست دوه اړخیز ته ورته دی ، پشمول د مختلف بیک اپ ذخیره چمتو کونکي ، په هرصورت ، د دوه اړخیز برعکس ، ډیری ب featuresې د دریمې ډلې وسیلو پرته شتون لري. ایا دا یو جمع یا منفي دی په ځانګړي قضیه پورې اړه لري ، مګر د پیل کونکو لپاره ، دا خورا اسانه دی چې د پایتون لپاره اضافي کڅوړې نصبولو پرځای په یوځل کې د دوی په مخ کې د ټولو ځانګړتیاو لیست ولرئ ، لکه څنګه چې دی. په دوه اړخیزه قضیه کې.

یو بل کوچنی نزاکت - برنامه په فعاله توګه د کارونکي په استازیتوب د محلي sqlite ډیټابیس لیکي څوک چې بیک اپ پیل کوي ، نو تاسو باید اضافي ډاډ ترلاسه کړئ چې اړین ډیټابیس په سمه توګه مشخص شوی کله چې د کلی په کارولو سره پروسه پیل شي. کله چې د GUI یا WEBGUI له لارې کار کوئ، توضیحات به د کارونکي څخه پټ شي.

راځئ وګورو چې دا حل کوم شاخصونه تولید کولی شي:

که تاسو کوډ کول بند کړئ (او WEBGUI د دې کولو وړاندیز نه کوي)، پایلې په لاندې ډول دي:

د کار ساعتونه:

1 پیل کړئ
2 پیل کړئ
3 پیل کړئ

20m43s
20m13s
20m28s

5m21s
5m40s
5m35s

7m36s
7m54s
7m49s

د کوډ کولو فعالولو سره، د aes په کارولو سره، دا داسې ښکاري:

د کار ساعتونه:

1 پیل کړئ
2 پیل کړئ
3 پیل کړئ

29m9s
30m1s
29m54s

5m29s
6m2s
5m54s

8m44s
9m12s
9m1s

او که تاسو بهرنۍ برنامه gnupg وکاروئ ، لاندې پایلې به راشي:

1 پیل کړئ
2 پیل کړئ
3 پیل کړئ

26m6s
26m35s
26m17s

5m20s
5m48s
5m40s

8m12s
8m42s
8m15s

لکه څنګه چې تاسو لیدلی شئ، برنامه کولی شي په څو تارونو کې کار وکړي، مګر دا دا یو ډیر ګټور حل نه کوي، او که تاسو د کوډ کولو کار پرتله کړئ، دا یو بهرنی پروګرام پیلوي.
د مونو سیټ څخه د کتابتون کارولو په پرتله ګړندی وګرځید. دا ممکن د دې حقیقت له امله وي چې بهرنی برنامه ډیر مطلوب دی.

یو بل ښه شی دا حقیقت و چې د ذخیره کولو اندازه د ریښتیني بدل شوي ډیټا په څیر دقیقا اخلي ، د بیلګې په توګه. duplicati د لارښود نوم بدل کړ او دا وضعیت یې په سمه توګه اداره کړ. دا لیدل کیدی شي کله چې دویمه ازموینه روانه وي.

په ټولیز ډول، د برنامه کافي مثبت تاثیرات، په شمول د نویو لپاره مناسب دوستانه.

پایلې

دواړو کاندیدانو په ورو ورو کار وکړ، مګر په عمومي توګه، د منظم تور په پرتله، لږ تر لږه د نقل سره، پرمختګ شتون لري. د داسې پرمختګ قیمت هم روښانه دی - د پام وړ بار
پروسیسر په عموم کې، د پایلو اټکل کولو کې کوم ځانګړي انحراف شتون نلري.

موندنو

که تاسو اړتیا نلرئ هرچیرې ګړندۍ شئ ، او اضافي پروسیسر هم ولرئ ، کوم حلونه چې په پام کې نیول شوي به ترسره کړي ، په هرصورت ، خورا ډیر کار ترسره شوی چې باید د ټار په سر کې د ریپر سکریپټونو لیکلو سره تکرار نشي. . د کوډ کولو شتون خورا اړین ملکیت دی که چیرې د بیک اپ کاپي ذخیره کولو سرور په بشپړ ډول باور ونه شي.

پر بنسټ د حلونو په پرتله rsync - فعالیت کولی شي څو ځله خراب وي، سره له دې چې د دې حقیقت سره سره چې په خالص شکل کې tar د rsync په پرتله 20-30٪ ګړندی کار کوي.
د ذخیره کولو په اندازې کې سپما شتون لري، مګر یوازې د نقل سره.

اعلامیه

بیک اپ، لومړۍ برخه: ولې بیک اپ ته اړتیا ده، د میتودونو، ټیکنالوژیو عمومي کتنه
د بیک اپ برخه 2: د rsync پر بنسټ د بیک اپ وسیلو بیاکتنه او ازموینه
د شاتړ برخه 3: بیاکتنه او دوه اړخیزه ازموینه
د بیک اپ برخه 4: د zbackup، آرامۍ، بورګ بیک اپ بیاکتنه او ازموینه
د بیک اپ برخه 5: د لینکس لپاره د بیکولا او ویم بیک اپ ازموینه
د بیک اپ برخه 6: د بیک اپ وسیلو پرتله کول
بیک اپ برخه 7: پایلې

لخوا لیکل شوی: پاول ډیمکوویچ

سرچینه: www.habr.com