Այս հոդվածը կքննարկի պահուստային ծրագրակազմը, որը տվյալների հոսքը բաժանելով առանձին բաղադրիչների (կտորների)՝ կազմում է պահեստ:
Պահեստի բաղադրիչները կարող են հետագայում սեղմվել և գաղտնագրվել, և ամենակարևորը կրկնվող կրկնօրինակման գործընթացների ժամանակ նորից օգտագործել:
Նման պահոցում պահուստային պատճենը միմյանց հետ կապված բաղադրիչների անվանական շղթա է, օրինակ՝ հիմնված տարբեր հեշ ֆունկցիաների վրա:
Կան մի քանի նմանատիպ լուծումներ, ես կկենտրոնանամ 3-ի վրա՝ zbackup, borgbackup և restic:
Ակնկալվող արդյունքներ
Քանի որ բոլոր դիմորդներն այս կամ այն կերպ պահանջում են շտեմարանի ստեղծում, ամենակարևոր գործոններից մեկը կլինի պահեստի չափը գնահատելը: Իդեալում, դրա չափը պետք է լինի ոչ ավելի, քան 13 ԳԲ, ըստ ընդունված մեթոդաբանության, կամ նույնիսկ ավելի քիչ՝ լավ օպտիմալացման ենթակա:
Նաև շատ ցանկալի է, որ կարողանանք ստեղծել ֆայլերի կրկնօրինակներ ուղղակիորեն՝ առանց tar-ի նման արխիվատորներ օգտագործելու, ինչպես նաև ssh/sftp-ի հետ աշխատել առանց լրացուցիչ գործիքների, ինչպիսիք են rsync-ը և sshfs-ը:
Պահուստային պատճեններ ստեղծելիս վարքագիծը.
- Պահեստի չափը հավասար կլինի փոփոխությունների չափին կամ ավելի քիչ:
- Կոմպրեսիոն և/կամ կոդավորումն օգտագործելիս սպասվում է CPU-ի մեծ բեռնվածություն, և հավանական է, որ ցանցի և սկավառակի բավականին բարձր բեռնվածություն, եթե արխիվացման և/կամ գաղտնագրման գործընթացն աշխատում է պահեստային պահեստավորման սերվերի վրա:
- Եթե պահեստը վնասված է, հավանական է, որ հետաձգված սխալ լինի ինչպես նոր կրկնօրինակներ ստեղծելիս, այնպես էլ վերականգնելիս: Անհրաժեշտ է լրացուցիչ միջոցներ պլանավորել պահեստի ամբողջականությունն ապահովելու համար կամ օգտագործել ներկառուցված գործիքներ՝ դրա ամբողջականությունը ստուգելու համար:
Թառի հետ աշխատելը վերցված է որպես հղման արժեք, ինչպես ցույց է տրվել նախորդ հոդվածներից մեկում։
Zbackup-ի փորձարկում
Zbackup-ի ընդհանուր մեխանիզմն այն է, որ ծրագիրը մուտքային տվյալների հոսքի մեջ գտնում է նույն տվյալները պարունակող տարածքները, այնուհետև ընտրովի սեղմում և գաղտնագրում է դրանք՝ պահպանելով յուրաքանչյուր տարածք միայն մեկ անգամ:
Deduplication-ը օգտագործում է 64-բիթանոց օղակի հեշ ֆունկցիան՝ լոգարիթմական պատուհանով, որպեսզի ստուգի բայթ առ բայթ համընկնումներն առկա տվյալների բլոկների հետ (նման է, թե ինչպես է այն իրականացնում rsync-ը):
Բազմաթելային lzma-ն և lzo-ն օգտագործվում են սեղմման համար, իսկ aes-ը՝ կոդավորման համար։ Վերջին տարբերակները հնարավորություն ունեն հետագայում ջնջել հին տվյալները պահեստից:
Ծրագիրը գրված է C++ լեզվով՝ նվազագույն կախվածությամբ։ Հեղինակը, ըստ երևույթին, ոգեշնչված էր unix-way-ով, ուստի ծրագիրը ընդունում է տվյալները stdin-ի վրա՝ կրկնօրինակումներ ստեղծելիս՝ վերականգնելիս stdout-ում նմանատիպ տվյալների հոսք արտադրելով: Այսպիսով, zbackup-ը կարող է օգտագործվել որպես շատ լավ «շինանյութ» ձեր սեփական պահեստային լուծումները գրելիս: Օրինակ՝ հոդվածի հեղինակը մոտավորապես 2014 թվականից օգտագործել է այս ծրագիրը՝ որպես տնային մեքենաների հիմնական պահեստային գործիք։
Տվյալների հոսքը կլինի սովորական tar, եթե այլ բան նշված չէ:
Տեսնենք, թե ինչ արդյունքներ կան.
Աշխատանքը ստուգվել է 2 տարբերակով.
- ստեղծվում է պահեստ, և zbackup-ը գործարկվում է սերվերի վրա աղբյուրի տվյալների հետ, այնուհետև պահեստի բովանդակությունը փոխանցվում է պահեստային պահեստավորման սերվերին:
- պահեստային պահուստային սերվերի վրա ստեղծվում է պահեստ, zbackup-ը գործարկվում է ssh-ի միջոցով պահեստային պահեստավորման սերվերի վրա, և տվյալները ուղարկվում են դրան խողովակի միջոցով:
Առաջին տարբերակի արդյունքները հետևյալն էին. 43m11s - չգաղտնագրված պահեստ և lzma կոմպրեսոր օգտագործելիս, 19m13s - կոմպրեսորը lzo-ով փոխարինելիս:
Սերվերի վրա բեռը սկզբնական տվյալներով հետևյալն էր (ցուցադրված է օրինակ lzma-ով. lzo-ի հետ մոտավորապես նույն պատկերն էր, բայց rsync-ի մասնաբաժինը մոտավորապես ժամանակի մեկ քառորդն էր).
Հասկանալի է, որ նման պահուստավորման գործընթացը հարմար է միայն համեմատաբար հազվադեպ և փոքր փոփոխությունների համար: Ցանկալի է նաև zbackup-ը սահմանափակել 1 շղթայով, հակառակ դեպքում պրոցեսորի շատ մեծ բեռնվածություն կլինի, քանի որ Ծրագիրը շատ լավ է աշխատում բազմաթիվ թեմաներով: Սկավառակի ծանրաբեռնվածությունը փոքր էր, ինչը, ընդհանուր առմամբ, նկատելի չէր լինի ժամանակակից ssd-ի վրա հիմնված սկավառակի ենթահամակարգի դեպքում: Դուք կարող եք նաև հստակ տեսնել պահեստի տվյալների հեռավոր սերվերի հետ համաժամացման գործընթացի սկիզբը, գործողության արագությունը համեմատելի է սովորական rsync-ի հետ և կախված է պահեստային պահեստավորման սերվերի սկավառակի ենթահամակարգի աշխատանքից: Այս մոտեցման թերությունը տեղական պահեստի պահպանումն է և, որպես հետևանք, տվյալների կրկնօրինակում:
Ավելի հետաքրքիր և գործնականում կիրառելի է երկրորդ տարբերակը՝ zbackup-ն ուղղակիորեն պահուստային պահեստի սերվերի վրա գործարկելը:
Նախ, մենք կփորձարկենք գործողությունը առանց կոդավորման lzma կոմպրեսորի միջոցով.
Յուրաքանչյուր փորձնական վազքի գործարկման ժամանակը.
Գործարկել 1
Գործարկել 2
Գործարկել 3
39 մ 45-ականներ
40 մ 20-ականներ
40 մ 3-ականներ
7 մ 36-ականներ
8 մ 3-ականներ
7 մ 48-ականներ
15 մ 35-ականներ
15 մ 48-ականներ
15 մ 38-ականներ
Եթե դուք միացնում եք գաղտնագրումը aes-ի միջոցով, արդյունքները բավականին մոտ են.
Գործողության ժամանակը նույն տվյալների վրա՝ գաղտնագրմամբ.
Գործարկել 1
Գործարկել 2
Գործարկել 3
43 մ 40-ականներ
44 մ 12-ականներ
44 մ 3-ականներ
8 մ 3-ականներ
8 մ 15-ականներ
8 մ 12-ականներ
15 մ 0-ականներ
15 մ 40-ականներ
15 մ 25-ականներ
Եթե գաղտնագրումը համակցված է սեղմման հետ՝ օգտագործելով lzo, ապա դա հետևյալն է.
Ժամեր:
Գործարկել 1
Գործարկել 2
Գործարկել 3
18 մ 2-ականներ
18 մ 15-ականներ
18 մ 12-ականներ
5 մ 13-ականներ
5 մ 24-ականներ
5 մ 20-ականներ
8 մ 48-ականներ
9 մ 3-ականներ
8 մ 51-ականներ
Ստացված պահոցի չափը համեմատաբար նույնն էր՝ 13 ԳԲ: Սա նշանակում է, որ deduplication-ը ճիշտ է աշխատում: Բացի այդ, արդեն սեղմված տվյալների վրա, lzo-ի օգտագործումը նկատելի էֆեկտ է տալիս. ընդհանուր գործառնական ժամանակի առումով zbackup-ը մոտ է կրկնօրինակությանը/կրկնօրինակին, բայց 2-5 անգամ զիջում է librsync-ի վրա հիմնվածներից:
Առավելությունները ակնհայտ են՝ պահեստային պահեստավորման սերվերի վրա սկավառակի տարածության խնայողություն: Ինչ վերաբերում է պահեստի ստուգման գործիքներին, ապա zbackup-ի հեղինակը դրանք չի տրամադրում, խորհուրդ է տրվում օգտագործել սխալ հանդուրժող սկավառակի զանգված կամ ամպային մատակարար:
Ընդհանուր առմամբ, շատ լավ տպավորություն է, չնայած այն հանգամանքին, որ նախագիծը կանգնած է մոտ 3 տարի (վերջին խաղարկային հարցումը եղել է մոտ մեկ տարի առաջ, բայց առանց պատասխանի):
Փորձարկում borgbackup
Borgbackup-ը ձեղնահարկի պատառաքաղ է, մեկ այլ համակարգ, որը նման է zbackup-ին: Գրված է python-ով, այն ունի zbackup-ի նման հնարավորությունների ցանկ, բայց լրացուցիչ կարող է.
- Տեղադրեք կրկնօրինակները ապահովիչների միջոցով
- Ստուգեք պահեստի բովանդակությունը
- Աշխատեք հաճախորդ-սերվեր ռեժիմում
- Տվյալների համար օգտագործեք տարբեր կոմպրեսորներ, ինչպես նաև ֆայլի տեսակի էվրիստիկական որոշում այն սեղմելիս:
- 2 գաղտնագրման տարբերակ, aes և blake
- Ներկառուցված գործիք համար
կատարողականի ստուգումներ
borgbackup հենանիշ crud ssh://backup_server/repo/path local_dir
Արդյունքները հետևյալն էին.
CZ-BIG 96.51 ՄԲ/վ (10 100.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 10.36 վրկ)
RZ-BIG 57.22 ՄԲ/վ (10 100.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 17.48 վրկ)
UZ-BIG 253.63 ՄԲ/վ (10 100.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 3.94 վրկ)
DZ-BIG 351.06 ՄԲ/վ (10 100.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 2.85 վրկ)
CR-BIG 34.30 ՄԲ/վ (10 100.00 ՄԲ պատահական ֆայլեր՝ 29.15 վրկ)
RR-BIG 60.69 ՄԲ/վ (10 100.00 ՄԲ պատահական ֆայլեր՝ 16.48 վրկ)
UR-BIG 311.06 ՄԲ/վ (10 100.00 ՄԲ պատահական ֆայլեր՝ 3.21 վրկ)
DR-BIG 72.63 ՄԲ/վ (10 100.00 ՄԲ պատահական ֆայլեր՝ 13.77 վրկ)
CZ-MEDIUM 108.59 ՄԲ/վ (1000 1.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 9.21 վրկ)
RZ-MEDIUM 76.16 ՄԲ/վ (1000 1.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 13.13 վրկ)
UZ-MEDIUM 331.27 ՄԲ/վ (1000 1.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 3.02 վրկ)
DZ-MEDIUM 387.36 ՄԲ/վ (1000 1.00 ՄԲ բոլոր զրոյական ֆայլեր՝ 2.58 վրկ)
CR-MEDIUM 37.80 ՄԲ/վ (1000 1.00 ՄԲ պատահական ֆայլեր՝ 26.45 վրկ)
RR-MEDIUM 68.90 ՄԲ/վ (1000 1.00 ՄԲ պատահական ֆայլեր՝ 14.51 վրկ)
UR-MEDIUM 347.24 ՄԲ/վ (1000 1.00 ՄԲ պատահական ֆայլեր՝ 2.88 վրկ)
DR-MEDIUM 48.80 ՄԲ/վ (1000 1.00 ՄԲ պատահական ֆայլեր՝ 20.49 վրկ)
CZ-SMALL 11.72 ՄԲ/վ (10000 10.00 կԲ զրոյական ֆայլեր՝ 8.53 վրկ)
RZ-SMALL 32.57 ՄԲ/վ (10000 10.00 կԲ զրոյական ֆայլեր՝ 3.07 վրկ)
UZ-SMALL 19.37 ՄԲ/վ (10000 10.00 կԲ զրոյական ֆայլեր՝ 5.16 վրկ)
DZ-SMALL 33.71 ՄԲ/վ (10000 10.00 կԲ զրոյական ֆայլեր՝ 2.97 վրկ)
CR-SMALL 6.85 ՄԲ/վ (10000 10.00 կԲ պատահական ֆայլեր՝ 14.60 վրկ)
RR-ՓՈՔՐ 31.27 ՄԲ/վ (10000 10.00 կԲ պատահական ֆայլեր՝ 3.20 վրկ)
UR-SMALL 12.28 ՄԲ/վ (10000 10.00 կԲ պատահական ֆայլեր՝ 8.14 վրկ)
DR-SMALL 18.78 ՄԲ/վ (10000 10.00 կԲ պատահական ֆայլեր՝ 5.32 վրկ)
Փորձարկելիս ֆայլի տեսակը որոշելու համար կօգտագործվի սեղմման էվրիստիկա (compression auto), և արդյունքները կլինեն հետևյալը.
Նախ, եկեք ստուգենք, թե ինչպես է այն աշխատում առանց կոդավորման.
Ժամեր:
Գործարկել 1
Գործարկել 2
Գործարկել 3
4 մ 6-ականներ
4 մ 10-ականներ
4 մ 5-ականներ
56s
58s
54s
1 մ 26-ականներ
1 մ 34-ականներ
1 մ 30-ականներ
Եթե միացնեք պահեստի թույլտվությունը (վավերացված ռեժիմ), արդյունքները մոտ կլինեն.
Ժամեր:
Գործարկել 1
Գործարկել 2
Գործարկել 3
4 մ 11-ականներ
4 մ 20-ականներ
4 մ 12-ականներ
1 մ 0-ականներ
1 մ 3-ականներ
1 մ 2-ականներ
1 մ 30-ականներ
1 մ 34-ականներ
1 մ 31-ականներ
Երբ aes գաղտնագրումը ակտիվացվեց, արդյունքները շատ չվատթարացան.
Գործարկել 1
Գործարկել 2
Գործարկել 3
4 մ 55-ականներ
5 մ 2-ականներ
4 մ 58-ականներ
1 մ 0-ականներ
1 մ 2-ականներ
1 մ 0-ականներ
1 մ 49-ականներ
1 մ 50-ականներ
1 մ 50-ականներ
Եվ եթե դուք փոխեք aes-ը blake-ի, ապա իրավիճակը լիովին կբարելավվի.
Ժամեր:
Գործարկել 1
Գործարկել 2
Գործարկել 3
4 մ 33-ականներ
4 մ 43-ականներ
4 մ 40-ականներ
59s
1 մ 0-ականներ
1 մ 0-ականներ
1 մ 38-ականներ
1 մ 43-ականներ
1 մ 40-ականներ
Ինչպես zbackup-ի դեպքում, պահեստի չափը 13 ԳԲ էր և նույնիսկ մի փոքր ավելի քիչ, ինչը, ընդհանուր առմամբ, սպասվում է: Ես շատ գոհ էի գործարկման ժամանակից, այն համեմատելի է librsync-ի վրա հիմնված լուծումների հետ՝ ապահովելով շատ ավելի լայն հնարավորություններ: Ինձ գոհացրեց նաև շրջակա միջավայրի փոփոխականների միջոցով տարբեր պարամետրեր սահմանելու հնարավորությունը, ինչը շատ լուրջ առավելություն է տալիս ավտոմատ ռեժիմում borgbackup-ի օգտագործման ժամանակ։ Ես գոհ էի նաև պահեստավորման ժամանակ բեռնվածությունից՝ դատելով պրոցեսորի ծանրաբեռնվածությունից՝ borgbackup-ը աշխատում է 1 թեմայում։
Այն օգտագործելիս առանձնահատուկ թերություններ չեն եղել:
ռեստիկ փորձարկում
Չնայած այն հանգամանքին, որ restic-ը բավականին նոր լուծում է (առաջին 2 թեկնածուները հայտնի էին դեռևս 2013 թվականին և ավելի հին), այն ունի բավականին լավ բնութագրեր։ Գրված է Go-ում:
Երբ համեմատվում է zbackup-ի հետ, այն լրացուցիչ տալիս է.
- Պահեստի ամբողջականության ստուգում (ներառյալ մասերի ստուգումը):
- Աջակցվող արձանագրությունների և պրովայդերների հսկայական ցուցակ՝ կրկնօրինակներ պահելու համար, ինչպես նաև աջակցություն rclone - rsync ամպային լուծումների համար:
- Համեմատելով 2 կրկնօրինակները միմյանց հետ.
- Պահեստի տեղադրում ապահովիչների միջոցով:
Ընդհանուր առմամբ, գործառույթների ցանկը բավականին մոտ է borgbackup-ին, որոշ տեղերում ավելի շատ, որոշ տեղերում՝ ավելի քիչ։ Առանձնահատկություններից մեկն այն է, որ գաղտնագրումն անջատելու միջոց չկա, և, հետևաբար, պահուստային պատճենները միշտ կոդավորված կլինեն: Եկեք տեսնենք գործնականում, թե ինչ կարելի է քամել այս ծրագրաշարից.
Արդյունքները հետևյալն էին.
Ժամեր:
Գործարկել 1
Գործարկել 2
Գործարկել 3
5 մ 25-ականներ
5 մ 50-ականներ
5 մ 38-ականներ
35s
38s
36s
1 մ 54-ականներ
2 մ 2-ականներ
1 մ 58-ականներ
Արդյունքների արդյունքները համեմատելի են նաև rsync-ի վրա հիմնված լուծումների հետ և, ընդհանուր առմամբ, շատ մոտ են borgbackup-ին, սակայն պրոցեսորի ծանրաբեռնվածությունն ավելի մեծ է (բազմաթելեր են աշխատում) և սղոցված ատամները:
Ամենայն հավանականությամբ, ծրագիրը սահմանափակված է տվյալների պահպանման սերվերի վրա սկավառակի ենթահամակարգի աշխատանքով, ինչպես արդեն եղել է rsync-ի դեպքում: Պահեստի չափը 13 ԳԲ էր, ինչպես zbackup-ը կամ borgbackup-ը, այս լուծումն օգտագործելիս ակնհայտ թերություններ չկային:
Արդյունքները
Փաստորեն, բոլոր թեկնածուները հասել են նույն արդյունքների, բայց տարբեր գներով։ Borgbackup-ը ամենից լավն էր, restic-ը մի փոքր ավելի դանդաղ էր, zbackup-ը հավանաբար չարժե սկսել օգտագործել,
և եթե այն արդեն օգտագործվում է, փորձեք փոխել այն borgbackup կամ restic:
Արդյունքները
Ամենահեռանկարային լուծումը կարծես թե հանգիստն է, քանի որ... նա է, ով ունի հնարավորությունների լավագույն հարաբերակցությունը գործառնական արագությանը, բայց եկեք առայժմ չշտապենք ընդհանուր եզրակացություններ անել:
Borgbackup-ը հիմնականում ավելի վատ չէ, բայց zbackup-ը հավանաբար ավելի լավ է փոխարինել: Ճիշտ է, zbackup-ը դեռ կարող է օգտագործվել՝ ապահովելու համար 3-2-1 կանոնի աշխատանքը: Օրինակ՝ ի լրումն (lib)rsync-ի վրա հիմնված պահուստավորման հարմարությունների:
Հայտարարություն
Կրկնօրինակում Մաս 5. Բակուլայի և veeam կրկնօրինակի փորձարկում Linux-ի համար
Կրկնօրինակում Մաս 6. Պահուստավորման գործիքների համեմատություն
Կրկնօրինակ Մաս 7. Եզրակացություններ
Տեղադրվել է: Պավել Դեմկովիչ
Source: www.habr.com