Կրկնօրինակ Մաս 3. Կրկնօրինակության վերանայում և փորձարկում

Այս նշումը քննարկում է պահեստային գործիքները, որոնք կրկնօրինակում են կատարում՝ ստեղծելով արխիվներ պահուստային սերվերի վրա:

Պահանջներին համապատասխանողներից են երկակիությունը (որն ունի գեղեցիկ ինտերֆեյս deja dup-ի տեսքով) և կրկնօրինակները։

Պահուստավորման մեկ այլ շատ ուշագրավ գործիք dar-ն է, բայց քանի որ այն ունի ընտրանքների շատ ընդարձակ ցանկ՝ թեստավորման մեթոդոլոգիան ընդգրկում է այն, ինչի կարող է հազիվ 10%-ը, մենք այն չենք փորձարկում որպես ընթացիկ ցիկլի մաս:

Ակնկալվող արդյունքներ

Քանի որ երկու թեկնածուներն էլ այս կամ այն ​​կերպ ստեղծում են արխիվներ, սովորական թառը կարող է օգտագործվել որպես ուղեցույց:

Բացի այդ, մենք կգնահատենք, թե որքանով է օպտիմիզացված տվյալների պահպանումը պահեստավորման սերվերի վրա՝ ստեղծելով կրկնօրինակների պատճեններ, որոնք պարունակում են միայն ամբողջական պատճենի և ֆայլերի ներկայիս վիճակի կամ նախորդ և ընթացիկ արխիվների միջև տարբերությունը (ավելի, նվազող և այլն): .

Պահուստային պատճեններ ստեղծելիս վարքագիծը.

1. Համեմատաբար փոքր թվով ֆայլեր պահուստային պահպանման սերվերում (համեմատելի է կրկնօրինակների քանակի կամ տվյալների չափի հետ ԳԲ), բայց դրանց չափը բավականին մեծ է (տասնյակից հարյուրավոր մեգաբայթ):
2. Պահեստի չափը կներառի միայն փոփոխությունները. կրկնօրինակներ չեն պահվի, ուստի պահեստի չափը կլինի ավելի փոքր, քան rsync-ի վրա հիմնված ծրագրաշարի դեպքում:
3. Սպասեք պրոցեսորի մեծ բեռնվածություն սեղմման և/կամ գաղտնագրման օգտագործման ժամանակ, և, հավանաբար, բավականին բարձր ցանցի և սկավառակի բեռնվածություն, եթե արխիվացման և/կամ գաղտնագրման գործընթացն աշխատում է պահեստային պահեստավորման սերվերի վրա:

Եկեք գործարկենք հետևյալ հրամանը որպես հղման արժեք.

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"

Պարզվեց այսպես.

Կատարման ժամանակը կազմել է 9 մ37 վրկ։ Մեկ միջուկի ծանրաբեռնվածությունը կոմպրեսորի կողմից հստակ տեսանելի է, քանի որ Ցանցի փոխանցման արագությունը և աղբյուրի սկավառակի ենթահամակարգի բեռը նման են:

Գաղտնագրումը գնահատելու համար կարող եք օգտագործել 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"

Արդյունքները ստացվել են այսպես.

Կատարման ժամանակը պարզվեց, որ 10 մ 30 վրկ է, քանի որ ընդունող կողմում աշխատում էին 2 պրոցեսներ՝ խցանման վզը կրկին մեկ թելերով կոմպրեսոր է, գումարած փոքր կոդավորման վերևում:

UPS: Bliznezz-ի խնդրանքով ավելացնում եմ թեստեր pigz-ով։ Եթե ​​դուք օգտագործում եք միայն կոմպրեսորը, ապա դա կպահանջի 6 մ 30 վրկ, եթե ավելացնեք նաև կոդավորումը՝ մոտ 7 մ: Ներքևի գրաֆիկի անկումը չլցված սկավառակի քեշն է.

Կրկնակի փորձարկում

Duplicity-ը python-ի ծրագրաշար է՝ կրկնօրինակման համար՝ ստեղծելով գաղտնագրված արխիվներ tar ձևաչափով:

Աճող արխիվների համար օգտագործվում է librsync, այնպես որ կարող եք ակնկալել նկարագրված վարքագիծը շարքի նախորդ գրառումը.

Կրկնօրինակները կարող են գաղտնագրվել և ստորագրվել gnupg-ի միջոցով, ինչը կարևոր է կրկնօրինակներ պահելու համար տարբեր մատակարարների օգտագործման ժամանակ (s3, backblaze, gdrive և այլն):

Տեսնենք, թե ինչ արդյունքներ կան.

Սրանք այն արդյունքներն են, որոնք մենք ստացել ենք առանց գաղտնագրման աշխատելիս

փչացող

Յուրաքանչյուր փորձնական վազքի գործարկման ժամանակը.

Գործարկել 1
Գործարկել 2
Գործարկել 3

16 մ 33-ականներ
17 մ 20-ականներ
16 մ 30-ականներ

8 մ 29-ականներ
9 մ 3-ականներ
8 մ 45-ականներ

5 մ 21-ականներ
6 մ 04-ականներ
5 մ 53-ականներ

Եվ ահա արդյունքները, երբ միացված է gnupg կոդավորումը՝ 2048 բիթանոց բանալու չափով.

Գործողության ժամանակը նույն տվյալների վրա՝ գաղտնագրմամբ.

Գործարկել 1
Գործարկել 2
Գործարկել 3

17 մ 22-ականներ
17 մ 32-ականներ
17 մ 28-ականներ

8 մ 52-ականներ
9 մ 13-ականներ
9 մ 3-ականներ

5 մ 48-ականներ
5 մ 40-ականներ
5 մ 30-ականներ

Նշված էր բլոկի չափը՝ 512 մեգաբայթ, ինչը հստակ երևում է գրաֆիկներում; Պրոցեսորի ծանրաբեռնվածությունը իրականում մնացել է 50%, ինչը նշանակում է, որ ծրագիրը օգտագործում է ոչ ավելի, քան մեկ պրոցեսորի միջուկ:

Ծրագրի գործարկման սկզբունքը նույնպես բավականին հստակ տեսանելի է. նրանք վերցրեցին մի կտոր տվյալ, սեղմեցին այն և ուղարկեցին պահեստային պահեստավորման սերվեր, որը կարող է բավականին դանդաղ լինել:
Մեկ այլ առանձնահատկություն է ծրագրի կանխատեսելի գործարկման ժամանակը, որը կախված է միայն փոփոխված տվյալների չափից:

Գաղտնագրումը միացնելը զգալիորեն չի մեծացրել ծրագրի գործարկման ժամանակը, սակայն այն մեծացրել է պրոցեսորի բեռնվածությունը մոտ 10%-ով, ինչը կարող է բավականին լավ բոնուս լինել:

Ցավոք, այս ծրագիրը չկարողացավ ճիշտ հայտնաբերել գրացուցակի վերանվանման հետ կապված իրավիճակը, և արդյունքում ստացված պահեստի չափը պարզվեց, որ հավասար է փոփոխությունների չափին (այսինքն, բոլորը 18 ԳԲ), բայց հստակորեն կրկնօրինակման համար անվստահելի սերվեր օգտագործելու հնարավորությունը: ծածկում է այս պահվածքը:

Կրկնակի փորձարկում

Այս ծրագրաշարը գրված է C#-ով և աշխատում է Mono-ի գրադարանների հավաքածուի միջոցով: Կա GUI, ինչպես նաև CLI տարբերակ:

Հիմնական հատկանիշների մոտավոր ցանկը նման է երկակիությանը, ներառյալ պահեստային պահեստավորման տարբեր մատակարարներ, սակայն, ի տարբերություն երկակիության, գործառույթների մեծ մասը հասանելի է առանց երրորդ կողմի գործիքների: Արդյոք սա պլյուս է, թե մինուս, կախված է կոնկրետ դեպքից, բայց սկսնակների համար, ամենայն հավանականությամբ, ավելի հեշտ է միանգամից ունենալ բոլոր հնարավորությունների ցուցակը, այլ ոչ թե լրացուցիչ տեղադրել python-ի համար նախատեսված փաթեթներ, ինչպես դա է: գործը երկակիությամբ.

Մեկ այլ փոքր նրբերանգ. ծրագիրը ակտիվորեն գրում է տեղական sqlite տվյալների բազան այն օգտագործողի անունից, ով սկսում է կրկնօրինակումը, այնպես որ դուք պետք է լրացուցիչ համոզվեք, որ անհրաժեշտ տվյալների բազան ճիշտ նշված է ամեն անգամ, երբ գործընթացը սկսվում է cli-ով: GUI-ի կամ WEBGUI-ի միջոցով աշխատելիս մանրամասները կթաքցվեն օգտվողից:

Տեսնենք, թե ինչ ցուցանիշներ կարող է բերել այս լուծումը.

Եթե ​​անջատեք գաղտնագրումը (և WEBGUI-ն խորհուրդ չի տալիս դա անել), արդյունքները հետևյալն են.

Ժամեր:

Գործարկել 1
Գործարկել 2
Գործարկել 3

20 մ 43-ականներ
20 մ 13-ականներ
20 մ 28-ականներ

5 մ 21-ականներ
5 մ 40-ականներ
5 մ 35-ականներ

7 մ 36-ականներ
7 մ 54-ականներ
7 մ 49-ականներ

Եթե ​​գաղտնագրումը միացված է, օգտագործելով aes, այն ունի հետևյալ տեսքը.

Ժամեր:

Գործարկել 1
Գործարկել 2
Գործարկել 3

29 մ 9-ականներ
30 մ 1-ականներ
29 մ 54-ականներ

5 մ 29-ականներ
6 մ 2-ականներ
5 մ 54-ականներ

8 մ 44-ականներ
9 մ 12-ականներ
9 մ 1-ականներ

Եվ եթե դուք օգտագործում եք gnupg արտաքին ծրագիրը, ապա ստացվում են հետևյալ արդյունքները.

Գործարկել 1
Գործարկել 2
Գործարկել 3

26 մ 6-ականներ
26 մ 35-ականներ
26 մ 17-ականներ

5 մ 20-ականներ
5 մ 48-ականներ
5 մ 40-ականներ

8 մ 12-ականներ
8 մ 42-ականներ
8 մ 15-ականներ

Ինչպես տեսնում եք, ծրագիրը կարող է աշխատել մի քանի թեմաներով, բայց դա այն ավելի արդյունավետ լուծում չի դարձնում, և եթե համեմատում եք գաղտնագրման աշխատանքը, այն գործարկում է արտաքին ծրագիր:
պարզվեց, որ ավելի արագ է, քան գրադարանից օգտվելը Mono հավաքածուից: Դա կարող է պայմանավորված լինել այն հանգամանքով, որ արտաքին ծրագիրն ավելի օպտիմիզացված է։

Մեկ այլ հաճելի բան այն էր, որ պահեստի չափը վերցնում է ճիշտ այնքան, որքան փաստացի փոփոխված տվյալները, այսինքն. duplicati-ն հայտնաբերել է գրացուցակի վերանվանումը և ճիշտ վարվել այս իրավիճակում: Սա կարելի է տեսնել երկրորդ թեստն իրականացնելիս:

Ընդհանուր առմամբ, ծրագրի բավականին դրական տպավորություններ, ներառյալ բավականին բարեկամական լինելը նորեկների հետ:

Արդյունքները

Երկու թեկնածուներն էլ բավականին դանդաղ են աշխատել, բայց ընդհանուր առմամբ սովորական թառի համեմատ առաջընթաց կա, համենայն դեպս կրկնօրինակներով։ Նման առաջընթացի գինը նույնպես պարզ է՝ նկատելի բեռ
պրոցեսոր։ Ընդհանուր առմամբ արդյունքների կանխատեսման մեջ առանձնահատուկ շեղումներ չկան։

Արդյունքները

Եթե ​​որևէ տեղ շտապելու կարիք չունեք, ինչպես նաև ունեք պահեստային պրոցեսոր, ապա դիտարկված լուծումներից ցանկացածը կկատարի, ամեն դեպքում, բավականին մեծ աշխատանք է կատարվել, որը չպետք է կրկնվի՝ թառի վերևում գրելով փաթաթման սցենարներ։ . Գաղտնագրման առկայությունը շատ անհրաժեշտ հատկություն է, եթե պահուստային պատճենները պահելու սերվերին չի կարելի լիովին վստահել:

Համեմատ լուծումների վրա հիմնված rsync - կատարումը կարող է մի քանի անգամ ավելի վատ լինել, չնայած այն հանգամանքին, որ իր մաքուր տեսքով խեժն աշխատել է 20-30% ավելի արագ, քան rsync-ը:
Պահեստի չափի վրա խնայողություններ կան, բայց միայն կրկնօրինակներով:

Հայտարարություն

Կրկնօրինակում, մաս 1. Ինչու է անհրաժեշտ կրկնօրինակում, մեթոդների, տեխնոլոգիաների ակնարկ
Կրկնօրինակում Մաս 2. rsync-ի վրա հիմնված պահուստավորման գործիքների վերանայում և փորձարկում
Կրկնօրինակում Մաս 3. Դիտեք և փորձարկեք կրկնակիությունը, կրկնօրինակը, deja dup-ը
Կրկնօրինակում Մաս 4. zbackup, restic, borgbackup վերանայում և փորձարկում
Կրկնօրինակում Մաս 5. Բակուլայի և veeam կրկնօրինակի փորձարկում Linux-ի համար
Կրկնօրինակում Մաս 6. Պահուստավորման գործիքների համեմատություն
Կրկնօրինակ Մաս 7. Եզրակացություններ

Տեղադրվել է: Պավել Դեմկովիչ

Source: www.habr.com