အရန်သိမ်းခြင်း အပိုင်း 3- ထပ်တူပွားခြင်း၊ ထပ်တူပွားခြင်းကို ပြန်လည်သုံးသပ်ခြင်းနှင့် စမ်းသပ်ခြင်း။

ဤမှတ်စုသည် အရန်ဆာဗာတစ်ခုပေါ်တွင် မော်ကွန်းတိုက်များဖန်တီးခြင်းဖြင့် အရန်သိမ်းဆည်းမှုများကို လုပ်ဆောင်သည့် အရန်ကိရိယာများကို ဆွေးနွေးထားသည်။

လိုအပ်ချက်များနှင့် ကိုက်ညီသူများထဲတွင် duplicity ( deja dup ပုံစံဖြင့် ကောင်းမွန်သော မျက်နှာပြင်ပါရှိသော) နှင့် duplicati တို့ဖြစ်သည်။

နောက်ထပ် အလွန်မှတ်သားဖွယ်ကောင်းသော အရန်ကိရိယာမှာ dar ဖြစ်သည်၊ သို့သော် ၎င်းတွင် ရွေးချယ်စရာများ အလွန်ကျယ်ပြန့်သောကြောင့် - စမ်းသပ်မှုနည်းစနစ်သည် ၎င်းကို စွမ်းဆောင်နိုင်သည့်အရာများ၏ 10% မျှသာ အကျုံးဝင်သည် - ကျွန်ုပ်တို့သည် ၎င်းကို လက်ရှိစက်ဝန်း၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် စမ်းသပ်ခြင်းမဟုတ်ပါ။

မျှော်လင့်ထားသည့်ရလဒ်များ

ကိုယ်စားလှယ်လောင်းနှစ်ဦးစလုံးသည် မော်ကွန်းတိုက်များကို တစ်နည်းမဟုတ်တစ်နည်း ဖန်တီးကြသောကြောင့် ပုံမှန် ကတ္တရာစေးကို လမ်းညွှန်အဖြစ် အသုံးပြုနိုင်ပါသည်။

ထို့အပြင်၊ ဖိုင်အပြည့်အစုံနှင့် လက်ရှိအခြေအနေကြား သို့မဟုတ် ယခင်နှင့် လက်ရှိ မှတ်တမ်းများအကြား (တိုးမြှင့်မှု၊ လျှော့ပေါ့ စသည်ဖြင့်) ပါဝင်သော အရန်မိတ္တူများကို ဖန်တီးခြင်းဖြင့် သိုလှောင်မှုဆာဗာတွင် ဒေတာသိမ်းဆည်းမှု မည်မျှကောင်းမွန်ကြောင်း အကဲဖြတ်ပါမည်။ .

အရန်သိမ်းဆည်းမှုများ ဖန်တီးသည့်အခါ အပြုအမူ

1. အရန်သိုလှောင်မှုဆာဗာရှိ ဖိုင်အရေအတွက် အနည်းငယ် (အရန်ကူးယူသည့် အရေအတွက် သို့မဟုတ် GB ရှိ ဒေတာအရွယ်အစားနှင့် နှိုင်းယှဉ်နိုင်သည်)၊ သို့သော် ၎င်းတို့၏ အရွယ်အစားမှာ အလွန်ကြီးမားသည် (ဆယ်ဂဏန်းမှ ရာဂဏန်းအထိ)။
2. သိုလှောင်မှု အရွယ်အစားတွင် အပြောင်းအလဲများသာ ပါဝင်လိမ့်မည် - ထပ်တူများကို သိမ်းဆည်းမည်မဟုတ်ပါ၊ ထို့ကြောင့် သိုလှောင်မှုအရွယ်အစားသည် rsync-based ဆော့ဖ်ဝဲလ်ထက် သေးငယ်မည်ဖြစ်သည်။
3. သိမ်းဆည်းခြင်းနှင့်/သို့မဟုတ် ကုဒ်ဝှက်ခြင်းလုပ်ငန်းစဉ်သည် အရန်သိုလှောင်မှုဆာဗာတစ်ခုပေါ်တွင် လုပ်ဆောင်နေပါက ဖိသိပ်ခြင်းနှင့်/သို့မဟုတ် ကုဒ်ဝှက်ခြင်းကိုအသုံးပြုသည့်အခါ လေးလံသော CPU load ကိုမျှော်လင့်ထားပြီး၊ သိမ်းဆည်းခြင်းနှင့်/သို့မဟုတ် ကုဒ်ဝှက်ခြင်းလုပ်ငန်းစဉ်သည် အရန်သိုလှောင်မှုဆာဗာပေါ်တွင် လုပ်ဆောင်နေပါက ကွန်ရက်နှင့် ဒစ်ခ်အား သယ်ဆောင်ခြင်းမှာ အလွန်မြင့်မားဖွယ်ရှိသည်။

ရည်ညွှန်းတန်ဖိုးအဖြစ် အောက်ပါ command ကို run ကြပါစို့။

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

စီရင်ချက်ရလဒ်များမှာ အောက်ပါအတိုင်းဖြစ်သည်။

စီရင်ချိန် 3m12s။ နမူနာတွင်ကဲ့သို့ အရန်သိုလှောင်မှုဆာဗာ၏ disk ခွဲစနစ်က အမြန်နှုန်းကို ကန့်သတ်ထားသည်ကို တွေ့မြင်နိုင်သည်။ rsync. နည်းနည်းမြန်တာမို့... အသံသွင်းခြင်းသည် ဖိုင်တစ်ခုသို့ ရောက်သွားပါသည်။

ထို့အပြင်၊ ဖိသိပ်မှုကို အကဲဖြတ်ရန်၊ တူညီသောရွေးချယ်မှုကို လုပ်ဆောင်ကြပါစို့၊ သို့သော် အရန်ဆာဗာဘက်ခြမ်းတွင် ချုံ့မှုကို ဖွင့်ပါ-

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

ရလဒ်များမှာ-

စီရင်ချိန် 10m11s။ အများစုမှာ ပိတ်ဆို့ခြင်းမှာ လက်ခံမှုအဆုံးရှိ single-flow compressor ဖြစ်သည်။

တူညီသောအမိန့်တော်ဖြစ်သော်လည်း၊ ကန့်လန့်ဖြတ်သည် single-threaded compressor ဖြစ်သည်ဟူသော ယူဆချက်ကို စမ်းသပ်ရန်အတွက် မူရင်းဒေတာဖြင့် ဆာဗာသို့ ဖိသိပ်မှုဖြင့် လွှဲပြောင်းပေးပါသည်။

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

ဤကဲ့သို့ ထွက်ပေါ်လာသည်-

ကွပ်မျက်ချိန်သည် 9m37s ဖြစ်သည်။ compressor မှ core တစ်ခုတွင် load ကို ရှင်းရှင်းလင်းလင်း မြင်နိုင်သောကြောင့် ဖြစ်သည်။ ကွန်ရက်လွှဲပြောင်းမှုအမြန်နှုန်းနှင့် ရင်းမြစ်ဒစ်ခွဲစနစ်ရှိ ဝန်သည် ဆင်တူသည်။

ကုဒ်ဝှက်ခြင်းကို အကဲဖြတ်ရန်၊ သင်သည် နောက်ထပ် command တစ်ခုကို ချိတ်ဆက်ခြင်းဖြင့် openssl သို့မဟုတ် gpg ကို အသုံးပြုနိုင်သည်။ openssl သို့မဟုတ် gpg ပိုက်ထဲမှာ။ ကိုးကားရန်အတွက် ဤကဲ့သို့သော command တစ်ခုရှိလိမ့်မည်-

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

ရလဒ်များ ဤကဲ့သို့ ထွက်ပေါ်လာသည် ။

လက်ခံသည့်ဘက်တွင် လုပ်ငန်းစဉ် 10 ခု လုပ်ဆောင်နေသောကြောင့် လုပ်ဆောင်ချိန်သည် 30m2s ဖြစ်လာသည် - တစ်ဆို့သည်မှာ single-threaded compressor ဖြစ်ပြီး၊ သေးငယ်သော encryption overhead ဖြစ်သည်။

UPD: bliznezz ၏တောင်းဆိုချက်အရ pigz နှင့်စမ်းသပ်မှုများထပ်ထည့်နေသည်။ အကယ်၍ သင်သည် ကွန်ပရက်ဆာကိုသာ အသုံးပြုပါက 6m30s ကြာမည်ဖြစ်ပြီး၊ encryption ထည့်ပါက 7m ခန့်ရှိမည်ဖြစ်သည်။ အောက်ခြေဂရပ်တွင် ကျဆင်းမှုသည် ဖယ်ထုတ်ထားသော disk cache ဖြစ်သည်-

အကုသိုလ်ပွား

Duplicity သည် tar ဖော်မတ်ဖြင့် စာဝှက်ထားသော မှတ်တမ်းများကို ဖန်တီးခြင်းဖြင့် အရန်ကူးယူရန်အတွက် Python ဆော့ဖ်ဝဲတစ်ခုဖြစ်သည်။

တိုးမြင့်လာသော မှတ်တမ်းများအတွက်၊ librsync ကို အသုံးပြုထားသောကြောင့် တွင်ဖော်ပြထားသော အပြုအမူကို သင်မျှော်လင့်နိုင်ပါသည်။ စီးရီးအတွက် ယခင်ပို့စ်.

အရန်ကူးယူမှုများကို သိမ်းဆည်းရန်အတွက် မတူညီသောဝန်ဆောင်မှုပေးသူများကိုအသုံးပြုသည့်အခါ အရေးကြီးသည်မှာ gnupg ကိုအသုံးပြု၍ ကုဒ်ဝှက်ပြီး လက်မှတ်ထိုးနိုင်သည် (s3၊ backblaze၊ gdrive စသည်ဖြင့်)

ရလဒ်တွေက ဘာတွေလဲဆိုတာ ကြည့်လိုက်ရအောင်။

ဤအရာများသည် ကုဒ်ဝှက်ခြင်းမရှိဘဲ လုပ်ဆောင်သည့်အခါ ကျွန်ုပ်တို့ရရှိသော ရလဒ်များဖြစ်သည်။

spoiler

စမ်းသပ်မှုတစ်ခုစီ၏ လည်ပတ်ချိန်-

စတင်ရန် ၁
စတင်ရန် ၁
စတင်ရန် ၁

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

2048 bits သော့အရွယ်အစားဖြင့် gnupg encryption ကိုဖွင့်ထားသောအခါတွင်ရလဒ်များဖြစ်သည်။

ကုဒ်ဝှက်စနစ်ဖြင့် တူညီသောဒေတာပေါ်တွင် လုပ်ဆောင်ချိန်-

စတင်ရန် ၁
စတင်ရန် ၁
စတင်ရန် ၁

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

ဘလောက်အရွယ်အစားကို ညွှန်ပြခဲ့သည် - 512 megabytes၊ ပရိုဆက်ဆာ load သည် 50% တွင် အမှန်တကယ်ရှိနေခဲ့သည်ဆိုလိုသည်မှာ ပရိုဂရမ်သည် ပရိုဆက်ဆာ core တစ်ခုထက်မပိုစေရပါ။

ပရိုဂရမ်၏ လုပ်ဆောင်ချက်၏ နိယာမကိုလည်း ရှင်းရှင်းလင်းလင်း မြင်နိုင်သည်- ၎င်းတို့သည် ဒေတာအပိုင်းအစကို ယူကာ ၎င်းကို ချုံ့ကာ အရန်သိုလှောင်မှု ဆာဗာသို့ ပို့လိုက်သည်၊၊ အလွန်နှေးကွေးနိုင်သည်။
အခြားအင်္ဂါရပ်တစ်ခုမှာ ပြောင်းလဲထားသောဒေတာအရွယ်အစားပေါ်တွင်သာ မူတည်သည့် ပရိုဂရမ်၏ ပြေးမြင်နိုင်သော အချိန်ကာလဖြစ်သည်။

ကုဒ်ဝှက်ခြင်းကို ဖွင့်ခြင်းသည် ပရိုဂရမ်၏ လုပ်ဆောင်ချိန်ကို သိသိသာသာ မတိုးစေဘဲ ပရိုဆက်ဆာဝန်အား 10% ခန့် တိုးစေသည့်အတွက် အတော်လေး ကောင်းသော ဘောနပ်စ်ဖြစ်နိုင်သည်။

ကံမကောင်းစွာဖြင့်၊ ဤပရိုဂရမ်သည် လမ်းညွှန်အမည်ပြောင်းခြင်းဖြင့် အခြေအနေကို မှန်ကန်စွာရှာဖွေတွေ့ရှိနိုင်ခြင်း မရှိခဲ့ဘဲ ထွက်ပေါ်လာသော သိုလှောင်မှုအရွယ်အစားသည် ပြောင်းလဲမှုများ၏ အရွယ်အစား (ဆိုလိုသည်မှာ 18GB အားလုံးကို) နှင့် ညီမျှသွားသော်လည်း အရန်သိမ်းဆည်းရန်အတွက် စိတ်မချရသော ဆာဗာကို ရှင်းရှင်းလင်းလင်း အသုံးပြုနိုင်ခြင်း ဤအပြုအမူကို ဖုံးကွယ်ထားသည်။

အကုသိုလ်ပွား

ဤဆော့ဖ်ဝဲကို C# ဖြင့်ရေးသားထားပြီး Mono မှ စာကြည့်တိုက်အစုံကို အသုံးပြုထားသည်။ GUI နှင့် CLI ဗားရှင်းလည်းရှိသည်။

အဓိကအင်္ဂါရပ်များစာရင်း၏ ခန့်မှန်းခြေစာရင်းသည် အမျိုးမျိုးသော အရန်သိုလှောင်မှုဝန်ဆောင်မှုပေးသူများအပါအဝင် ထပ်တူပွားခြင်းနှင့် ဆင်တူသော်လည်း၊ ထပ်တူနှင့်မတူဘဲ၊ အင်္ဂါရပ်အများစုသည် ပြင်ပကိရိယာများမပါဘဲ ရရှိနိုင်ပါသည်။ ၎င်းသည် အပေါင်း သို့မဟုတ် အနုတ်ရှိမရှိ သတ်သတ်မှတ်မှတ်ကိစ္စအပေါ် မူတည်သော်လည်း စတင်သူများအတွက်မူ python အတွက် ပက်ကေ့ဂျ်များကို ထပ်လောင်းထည့်သွင်းရမည့်အစား ၎င်းတို့ရှေ့တွင် အင်္ဂါရပ်များအားလုံးကို တစ်ပြိုင်နက် စာရင်းတစ်ခုရရန် ပိုမိုလွယ်ကူဖွယ်ရှိသည်။ ထပ်တူကိစ္စ။

နောက်ထပ်အသေးစိတ်အချက်တစ်ချက် - ပရိုဂရမ်သည် အရန်သိမ်းခြင်းကိုစတင်သည့်အသုံးပြုသူကိုယ်စား local sqlite ဒေတာဘေ့စ်ကိုတက်ကြွစွာရေးသားသည်၊ ထို့ကြောင့် cli ကိုအသုံးပြုသည့်လုပ်ငန်းစဉ်စတင်ချိန်တိုင်းတွင် လိုအပ်သောဒေတာဘေ့စ်ကို မှန်ကန်စွာသတ်မှတ်ထားကြောင်း သေချာရန် လိုအပ်ပါသည်။ GUI သို့မဟုတ် WEBGUI မှတစ်ဆင့် လုပ်ဆောင်သည့်အခါ အသေးစိတ်အချက်အလက်များကို အသုံးပြုသူထံမှ ဝှက်ထားမည်ဖြစ်သည်။

ဤဖြေရှင်းချက်သည် အဘယ်အညွှန်းကိန်းများကို ထုတ်ပေးနိုင်သည်ကို ကြည့်ကြပါစို့။

အကယ်၍ သင်သည် ကုဒ်ဝှက်ခြင်းကို ပိတ်ထားပါက (၎င်းကို WEBGUI မှ အကြံပြုထားခြင်း မရှိပါ) ရလဒ်များမှာ အောက်ပါအတိုင်း ဖြစ်ပါသည်။

hours:

စတင်ရန် ၁
စတင်ရန် ၁
စတင်ရန် ၁

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

aes ကို အသုံးပြု၍ ကုဒ်ဝှက်ခြင်းကို ဖွင့်ထားခြင်းဖြင့်၊ ၎င်းသည် ဤကဲ့သို့ ဖြစ်သည်-

hours:

စတင်ရန် ၁
စတင်ရန် ၁
စတင်ရန် ၁

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

ပြင်ပပရိုဂရမ် gnupg ကိုအသုံးပြုပါက၊ အောက်ပါရလဒ်များထွက်လာသည်-

စတင်ရန် ၁
စတင်ရန် ၁
စတင်ရန် ၁

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

၁ မိနစ် ၃၀
၁ မိနစ် ၃၀
၁ မိနစ် ၃၀

သင်တွေ့မြင်ရသည့်အတိုင်း၊ ပရိုဂရမ်သည် စာတွဲများစွာတွင် အလုပ်လုပ်နိုင်သော်လည်း ၎င်းသည် ၎င်းကို ပိုမိုအကျိုးရှိသော ဖြေရှင်းချက်တစ်ခု ဖြစ်စေမည်မဟုတ်ဘဲ ကုဒ်ဝှက်ခြင်းလုပ်ငန်းကို နှိုင်းယှဉ်ပါက၊ ၎င်းသည် ပြင်ပပရိုဂရမ်ကို စတင်လုပ်ဆောင်နေသည်
Mono set မှ စာကြည့်တိုက်ကို အသုံးပြုခြင်းထက် ပိုမိုမြန်ဆန်လာသည်။ ပြင်ပပရိုဂရမ်ကို ပိုကောင်းအောင်ပြုလုပ်ထားခြင်းကြောင့် ဖြစ်နိုင်သည်။

နောက်ထပ်ကောင်းတဲ့အချက်ကတော့ repository ရဲ့ အရွယ်အစားဟာ တကယ့်ပြောင်းလဲသွားတဲ့ data တွေထက် အတိအကျ ယူရတဲ့အချက်ပါပဲ။ ထပ်တူကူးထားသော လမ်းညွှန်အမည်ပြောင်းခြင်းကို တွေ့ရှိပြီး ဤအခြေအနေကို မှန်ကန်စွာ ကိုင်တွယ်ပါ။ ဒုတိယစမ်းသပ်မှုကို လုပ်ဆောင်သောအခါတွင် ယင်းကို တွေ့မြင်နိုင်သည်။

ယေဘုယျအားဖြင့်၊ အသစ်အသစ်များနှင့် လိုက်လျောညီထွေရှိခြင်း အပါအဝင် ပရိုဂရမ်၏ အပြုသဘောဆောင်သော အထင်အမြင်များ။

ရလဒ်များကို

ကိုယ်စားလှယ်လောင်းနှစ်ဦးစလုံးသည် နှေးကွေးစွာ အလုပ်လုပ်သော်လည်း ယေဘုယျအားဖြင့် ပုံမှန် ကတ္တရာစေးနှင့် နှိုင်းယှဉ်ပါက အနည်းဆုံး ထပ်တူပွားခြင်းဖြင့် တိုးတက်မှု ရှိပါသည်။ ထိုကဲ့သို့သောတိုးတက်မှု၏စျေးနှုန်းမှာလည်းရှင်းရှင်းလင်းလင်းဖြစ်ပါသည် - သိသာထင်ရှားသောဝန်ထုပ်ဝန်ပိုးဖြစ်ပါတယ်။
ပရိုဆက်ဆာ။ ယေဘုယျအားဖြင့် ရလဒ်များကို ခန့်မှန်းရာတွင် အထူးသွေဖည်မှု မရှိပါ။

တွေ့ရှိချက်များ

မည်သည့်နေရာမှ အလျင်စလို မလိုအပ်ဘဲ အပိုပရိုဆက်ဆာ ပါရှိပါက၊ ထည့်သွင်းစဉ်းစားထားသော ဖြေရှင်းချက်များသည် မည်သို့ပင်ဖြစ်စေ ကတ္တရာစေးပေါ်တွင် wrapper scripts များကို ထပ်ခါထပ်ခါ မရေးသင့်သော အလုပ်များစွာကို လုပ်ဆောင်ပြီးပြီ၊ . အရန်မိတ္တူများ သိမ်းဆည်းခြင်းအတွက် ဆာဗာသည် အပြည့်အဝယုံကြည်နိုင်ခြင်းမရှိပါက ကုဒ်ဝှက်ခြင်းရှိနေခြင်းသည် အလွန်လိုအပ်သောပိုင်ဆိုင်မှုတစ်ခုဖြစ်သည်။

ဖြေရှင်းနည်းများနှင့် နှိုင်းယှဉ်ပါ။ rsync - ၎င်း၏သန့်စင်သောပုံစံတွင် rsync ထက် 20-30% ပိုမိုမြန်ဆန်စွာအလုပ်လုပ်နေသော်လည်း စွမ်းဆောင်ရည်သည် အဆများစွာ ပိုဆိုးနိုင်သည်။
repository ၏ အရွယ်အစားပေါ်တွင် စုဆောင်းငွေများ ရှိသည်၊ သို့သော် မိတ္တူပွားခြင်းသာ ဖြစ်သည်။

ကြေငြာချက်

အရန်သိမ်းခြင်း၊ အပိုင်း 1- အဘယ်ကြောင့် အရန်ကူးရန် လိုအပ်သနည်း၊ နည်းလမ်းများ ခြုံငုံသုံးသပ်ချက်၊ နည်းပညာများ
အရန်သိမ်းခြင်း အပိုင်း 2- rsync-based အရန်ကိရိယာများကို ပြန်လည်သုံးသပ်ခြင်းနှင့် စမ်းသပ်ခြင်း။
အရန်သိမ်းခြင်း အပိုင်း 3- ထပ်တူပွားခြင်း၊ ထပ်တူပွားခြင်း၊ deja dup ကို ပြန်လည်သုံးသပ်ခြင်းနှင့် စမ်းသပ်ခြင်း။
အရန်သိမ်းခြင်း အပိုင်း 4- zbackup၊ restic၊ borgbackup ကို စစ်ဆေးခြင်းနှင့် စမ်းသပ်ခြင်း။
အရန်သိမ်းခြင်း အပိုင်း 5- linux အတွက် bacula နှင့် veeam အရန်ကူးခြင်းကို စမ်းသပ်နေသည်။
အရန်သိမ်းခြင်း အပိုင်း 6- အရန်ကိရိယာများကို နှိုင်းယှဉ်ခြင်း။
အရန်သိမ်းခြင်း အပိုင်း 7- နိဂုံးများ

ရေးသားခဲ့သည်- Pavel Demkovich

source: www.habr.com