Capacity Tier-ը (կամ ինչպես մենք այն անվանում ենք Vim - captir-ի ներսում) հայտնվել է դեռևս Veeam Backup-ի և Replication 9.5 Update 4-ի ժամանակներում՝ Archive Tier անունով: Դրա գաղափարը կայանում է նրանում, որ հնարավորություն ընձեռվի տեղափոխել կրկնօրինակները, որոնք դուրս են եկել այսպես կոչված գործառնական վերականգնման պատուհանից դեպի օբյեկտների պահեստ: Սա օգնեց մաքրել սկավառակի տարածքը այն օգտվողների համար, ովքեր քիչ ունեին: Եվ այս տարբերակը կոչվում էր Move Mode:

Այս պարզ (ինչպես թվում է) գործողությունը կատարելու համար բավական էր բավարարել երկու պայման՝ տեղափոխված պահուստավորման բոլոր կետերը պետք է լինեն վերը նշված գործառնական վերականգնման պատուհանի սահմաններից դուրս, որը բացահայտորեն սահմանված է UI-ում: Եվ երկրորդը. շղթան պետք է լինի այսպես կոչված «կնքված ձևով» (կնքված պահուստային շղթա կամ Inactive Backup Chain): Այսինքն՝ ժամանակի ընթացքում այս շղթայում փոփոխություններ չեն լինում։

Բայց VBR v10-ում կոնցեպտը համալրվեց նոր գործառույթներով՝ Copy Mode, Sealed Mode և հայտնվեց դժվար արտասանվող Immutability անունով մի բան։

Սրանք այն հետաքրքրաշարժ բաներն են, որոնց մասին կխոսենք այսօր: Նախ՝ այն մասին, թե ինչպես է այն աշխատել VBR9.5u4-ում, իսկ հետո՝ տասներորդ տարբերակի փոփոխությունների մասին։

Եվ թող ինձ ներեն մաքուր լեզվի չեմպիոնները, բայց չափազանց շատ տերմիններ կան, որոնք չեն կարող թարգմանվել։
Այսպիսով, այստեղ կլինեն տոննա անգլիկիզմներ:
Եվ շատ gif-ներ:
Եվ նկարներ.

• Առանց ամենափոքր ափսոսանքի։ Հոդվածի հեղինակ.

Ինչպես եղավ

Դե, եկեք սկսենք վերլուծելով գործառնական վերականգնման պատուհանը և կնքված կրկնօրինակը (կամ ինչպես դրանք կոչվում են Inactive Backup Chain փաստաթղթերում): Առանց նրանց հասկանալու հետագա բացատրությունը հնարավոր չի լինի։

Ինչպես տեսնում ենք նկարում, մենք ունենք տվյալների բլոկներով մի տեսակ պահեստային շղթա, որը գտնվում է պահեստի Performance մակարդակի SOBR-ի վրա, որին միացված է Capacity Tier-ը։ Մեր գործառնական պահուստավորման պատուհանը երեք օր է:

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

Բայց կոնկրետ ի՞նչ նկատի ուներ կնքված շղթա ասելով, և ի՞նչ կարող էր ուղարկվել 4-րդ թարմացման հզորության հրաձգարան:

Forward Incremental, շղթայի կնքման նշան է նոր ամբողջական կրկնօրինակի ստեղծումը: Եվ կարևոր չէ, թե ինչպես է ստացվում այս ամբողջական կրկնօրինակը. հաշվի են առնվում ինչպես սինթետիկ, այնպես էլ ակտիվ ամբողջական կրկնօրինակները:

Reverse-ի դեպքում սրանք բոլոր ֆայլերն են, որոնք չեն ընկնում գործող պատուհանի մեջ:

Հետադարձումներով առաջ ավելացման դեպքում դրանք բոլորը հետադարձումներ են և .vbk, եթե կատարողականի չափի վրա կա մեկ այլ .vbk:

Այժմ դիտարկենք Backup Copy շղթաների հետ աշխատելու տարբերակը։ Այստեղ տեղափոխվեցին միայն GFS-ի պահպանման տակ գտնվող իրերը: Քանի որ այն ամենը, ինչ պահվում է ավելի նոր կրկնօրինակման շղթաներում, կարող է փոխվել այս կամ այն ​​կերպ:

Հիմա եկեք նայենք գլխարկի տակ: Այնտեղ տեղի է ունենում մի գործընթաց, որը կոչվում է ջրազրկում՝ թողնելով դատարկ պահուստային ֆայլերը տարածության վրա և այդ ֆայլերից բլոկները քաշելով դեպի հրաձգարան: Այս գործընթացը օպտիմալացնելու համար օգտագործվում է այսպես կոչված ջրազրկման ինդեքսը, որը թույլ է տալիս խուսափել բլոկների պատճենումից, որոնք արդեն պատճենվել են հզորության հրաձգարան:

Եկեք տեսնենք, թե ինչ տեսք ունի սա օրինակով. Ենթադրենք, մենք ունենք .vbk, որը դուրս է եկել գործարքի պատուհանից և պատկանում է կնքված շղթային: Սա նշանակում է, որ մենք բոլոր իրավունքներն ունենք այն տեղափոխելու հզորության հրաձգարան։ Տեղափոխման պահին մետատվյալների ֆայլ է ստեղծվում փոխանցված ֆայլի հզորության տողում և բլոկներում: Հղման մակարդակի մետատվյալների ֆայլը նկարագրում է, թե ինչ բլոկներից է բաղկացած մեր ֆայլը: Նկարում պատկերված դեպքում մեր առաջին ֆայլը բաղկացած է a, b, c բլոկներից, և մետատվյալները պարունակում են հղումներ դեպի այս բլոկները: Երբ մենք ունենք երկրորդ .vbk ֆայլը, որը պատրաստ է տեղափոխվելու և բաղկացած է a, b և d բլոկներից, մենք, վերլուծելով ջրազրկման ինդեքսը, հասկանում ենք, որ միայն d բլոկը պետք է փոխանցվի: Եվ դրա մետատվյալների ֆայլը կպարունակի հղումներ դեպի երկու նախորդ բլոկներ և մեկ նոր:

Համապատասխանաբար, այս դատարկ տարածքները տվյալների հետ լրացնելու գործընթացը կոչվում է ռեհիդրացիա: Այն արդեն օգտագործում է իր սեփական ռեհիդրացիոն ինդեքսը՝ հիմնված ամենահին .vbk ֆայլի վրա՝ տեղական կատարողականի չափով: Այսինքն, եթե օգտատերը ցանկանում է վերադարձնել ֆայլը հզորության հրաձգարանից, մենք նախ ստեղծում ենք ամենահին ամբողջական կրկնօրինակի բլոկների ինդեքսը և հզորության նկարահանման պատկերասրահից փոխանցում միայն բացակայող բլոկները: Նկարում ներկայացված դեպքում FullBackup1.vbk-ն ըստ ռեհիդրացիոն ինդեքսի ռեհիդրատավորելու համար մեզ անհրաժեշտ է միայն C բլոկ, որը վերցնում ենք հզորության հրաձգարանից։ Եթե ​​պահեստային ամպային օբյեկտը ծառայում է որպես հրաձգարան, դա թույլ է տալիս հսկայական գումարներ խնայել:

Այստեղ կարող է թվալ, որ այս տեխնոլոգիան նույնական է WAN արագացուցիչներում օգտագործվող տեխնոլոգիային, բայց դա միայն թվում է: Արագացուցիչներում կրկնօրինակումը գլոբալ է, այստեղ տեղական կրկնօրինակումը օգտագործվում է յուրաքանչյուր ֆայլում որոշակի օֆսեթով: Դա տեղի է ունենում լուծվող առաջադրանքների տարբերության պատճառով. այստեղ մենք պետք է պատճենենք մեծ պահեստային ֆայլեր, և մեր հետազոտության համաձայն, նույնիսկ եթե նրանց միջև երկար ժամանակ է անցնում, ապա կրկնօրինակման այս ալգորիթմը տալիս է լավագույն արդյունքը:

Բայց ավելի շատ ցուցանիշներ ինդեքսների աստծո համար: Կա նաև տվյալների վերականգնման ինդեքս: Երբ մենք սկսում ենք վերականգնել հզորության գծիկում գտնվող մեքենան, մենք կկարդանք միայն տվյալների եզակի բլոկները, որոնք չկան կատարողականի գծիկում:

Ինչպե՞ս դա տեղի ունեցավ:

Այսքանը ներածական մասի համար: Այն բավականին մանրամասն է, բայց ինչպես վերը նշվեց, առանց այս մանրամասների հնարավոր չի լինի բացատրել, թե ինչպես են աշխատում նոր գործառույթները։ Հետևաբար, առանց հետագա անհանգստության, եկեք անցնենք առաջինին:

Պատճենման ռեժիմ

Այն հիմնականում հիմնված է գոյություն ունեցող տեխնոլոգիաների վրա, բայց կրում է օգտագործման բոլորովին այլ տրամաբանություն։ 

Այս ռեժիմի նպատակն է ապահովել, որ տեղական տարածության վրա տեղակայված բոլոր տվյալները ունենան պատճենը հզորության գծիկում:

Եթե ​​համեմատեք «Տեղափոխել» և «Պատճենել» ռեժիմները, ապա այն կունենա հետևյալ տեսքը.

• Միայն կնքված շղթան կարելի է տեղափոխել։ Պատճենման ռեժիմի դեպքում բացարձակապես ամեն ինչ փոխանցվում է, անկախ նրանից, թե ինչ է կատարվում պահեստային աշխատանքում։
• Տեղափոխումը գործարկվում է, երբ ֆայլերը դուրս են գալիս գործառնական պահուստավորման պատուհանի սահմաններից, և պատճենումը գործարկվում է պահուստային ֆայլի հայտնվելուն պես:
• Պատճենելու համար նոր տվյալների մոնիտորինգը տեղի է ունենում անընդհատ, իսկ տեղափոխման համար գործարկվում էր 4 ժամը մեկ:

Նոր ռեժիմը դիտարկելիս առաջարկում եմ պարզ օրինակներից անցնել բարդի:

Ամենատարածված դեպքում մենք պարզապես ունենք նոր ֆայլեր՝ ավելացումներով, և մենք դրանք պարզապես պատճենում ենք հզորության հրաձգարան: Անկախ նրանից, թե ինչ ռեժիմ է օգտագործվում պահեստային աշխատանքում, անկախ նրանից՝ այն պատկանում է շղթայի փակ հատվածին, թե ոչ, անկախ նրանից՝ մեր գործող պատուհանի ժամկետը լրացել է։ Ուղղակի վերցրել են ու պատճենել։

Սրա հիմքում ընկած գործընթացը դեռևս ջրազրկումն է, ինչպես նկարագրված է վերևում: Պատճենման ռեժիմում այն ​​նաև ապահովում է, որ մենք չենք պատճենում բլոկները, որոնք արդեն մեր պահեստում են: Միակ տարբերությունն այն է, որ եթե ֆիլմի ռեժիմում իրական ֆայլերը փոխարինել ենք կեղծ ֆայլերով, ապա այստեղ մենք ոչ մի կերպ չենք դիպչում դրանց և թողնում ենք ամեն ինչ այնպես, ինչպես կա: Հակառակ դեպքում, դա հենց նույն ջրազրկման ցուցանիշն է, որը զգուշորեն փորձում է խնայել ձեր գումարն ու ժամանակը։

Հարց է առաջանում՝ եթե նայեք UI-ին, ապա հնարավորություն կա միաժամանակ ընտրել երկու տարբերակները։ Ինչպե՞ս կաշխատի նման համակցված ռեժիմը:

Եկեք դա պարզենք:

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

Այս ամբողջ հետաքրքրաշարժ տրամաբանությունը պատասխանատու է ինտերֆեյսի ընդամենը մեկ վանդակի համար. պատճենեք կրկնօրինակները օբյեկտների պահեստում հենց դրանք ստեղծվեն:

Ինչու՞ է մեզ անհրաժեշտ այս Պատճենման ռեժիմը:

Ավելի լավ է հարցը վերափոխել այսպես՝ ի՞նչ ռիսկերից ենք մենք պաշտպանված դրա օգնությամբ։ Ի՞նչ խնդիր է դա մեզ օգնում լուծել:

Պատասխանն ակնհայտ է՝ իհարկե, սա տվյալների վերականգնում է։ Եթե ​​մենք ունենք օբյեկտի պահպանման տեղական տվյալների ամբողջական պատճեն, ապա անկախ նրանից, թե ինչ է պատահում մեր արտադրանքի հետ, մենք միշտ կարող ենք վերականգնել տվյալները պայմանական Amazon-ում տեղակայված ֆայլերից:

Այսպիսով, եկեք անցնենք հնարավոր սցենարների միջով` ամենապարզից մինչև ավելի բարդ:

Ամենապարզ դժբախտությունը, որը կարող է ընկնել մեր գլխին, պահեստային շղթայի ֆայլերից մեկի անհասանելիությունն է։

Ավելի տխուր պատմություն է այն, որ մեր SOBR պահեստի տարածքներից մեկը կոտրվեց:

Այն ավելի է վատանում, երբ SOBR-ի ողջ պահեստն անհասանելի է դարձել, բայց հզորությամբ հրաձգարանն աշխատում է:
Եվ ամեն ինչ իսկապես վատ է. սա այն դեպքում, երբ պահուստային սերվերը մահանում է, և ձեր առաջին ցանկությունն է փորձել վազել Կանադայի սահմանը տասը րոպեում:

Այժմ եկեք նայենք յուրաքանչյուր իրավիճակին առանձին:

Երբ մենք կորցրել ենք մեկ (և նույնիսկ մի քանի) պահուստային ֆայլ, այնուհետև մեզ անհրաժեշտ է միայն սկսել պահեստի վերասկանավորման գործընթացը, և կորցրած ֆայլը կփոխարինվի կեղծ ֆայլով: Եվ օգտագործելով ռեհիդրացման գործընթացը (որը քննարկվել է հոդվածի սկզբում), օգտատերը կկարողանա տվյալներ ներբեռնել հզորության հրաձգարանից տեղական պահեստ:

Հիմա իրավիճակն ավելի բարդ է. Ենթադրենք, որ մեր SOBR-ը բաղկացած է Performance ռեժիմով աշխատող երկու աստիճանից, ինչը նշանակում է, որ մեր .vbk-ն և .vib-ը տարածված են դրանց վրա բավականին անհավասար շերտով: Եվ ինչ-որ պահի չափերից մեկն անհասանելի է դառնում, և օգտատերը շտապ պետք է վերականգնի մեքենան, որի տվյալների մի մասը հենց այս չափի վրա է:

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

Այս դեպքի ենթատեսակն այն է, որ SOBR-ի ամբողջ պահեստն անհասանելի է դարձել: Այս դեպքում մենք տեղական պահեստից պատճենելու ոչինչ չունենք, և բոլոր բլոկները ներբեռնվում են ամպից:

Եվ ամենահետաքրքիր իրավիճակն այն է, որ պահեստային սերվերը մահացել է: Այստեղ երկու տարբերակ կա՝ ադմինը հիանալի է և կազմաձևման կրկնօրինակումներ է արել, իսկ ադմինը չար Պինոկիոն է և չի արել կոնֆիգուրացիայի կրկնօրինակումներ։

Առաջին դեպքում, նրա համար բավական կլինի պարզապես տեղակայել VBR-ի մաքուր տեղադրումը ինչ-որ տեղ և վերականգնել դրա տվյալների բազան կրկնօրինակից՝ օգտագործելով ստանդարտ միջոցներ: Այս գործընթացի ավարտից հետո ամեն ինչ կվերադառնա իր բնականոն հունին: Կամ այն ​​կվերականգնվի վերը նշված սցենարներից մեկի համաձայն։

Բայց եթե ադմինը կամ իր թշնամին է, կամ կոնֆիգուրացիայի կրկնօրինակը նույնպես էպիկական ձախողում է կրել, ապա նույնիսկ այստեղ մենք նրան չենք թողնի բախտի ողորմածությանը: Այս դեպքի համար մենք ներդրել ենք նոր ընթացակարգ, որը կոչվում է Ներմուծման օբյեկտների պահպանում: Այն թույլ է տալիս բաց թողնել SOBR պահոցը ձեռքով վերստեղծելու և դրան հաջորդող վերասկանավորման միջոցով հզորությամբ հրաձգարան կցելու գործընթացը, և պարզապես Vim ինտերֆեյսին ավելացնել պահեստավորման օբյեկտ և գործարկել Import Storage Repository ընթացակարգը: Միակ բանը, որը կարող է խոչընդոտել ձեր և ձեր կրկնօրինակների միջև, գաղտնաբառ մուտքագրելու հարցումն է, եթե ձեր կրկնօրինակները գաղտնագրված են:

Սա, հավանաբար, վերաբերում է Պատճենման ռեժիմին, և մենք անցնում ենք

Կնքված ռեժիմ

Հիմնական գաղափարն այն է, որ նոր կրկնօրինակները չեն կարող հայտնվել պահոցի ընտրված SOBR տարածության վրա: Մինչև v10, մենք ունեինք միայն Maintenance Mode, երբ պահեստի հետ ցանկացած աշխատանք ամբողջովին արգելված էր: Մի տեսակ հարդքոր ռեժիմ՝ պահեստավորումն անջատելու համար, որտեղ հասանելի է միայն Էվակուացնել կոճակը, որը մեկ անգամ մեկ այլ չափով պահուստավորում է տեղափոխում:

Իսկ կնքված ռեժիմը մի տեսակ «փափուկ» տարբերակ է՝ մենք արգելում ենք նոր կրկնօրինակների ստեղծումը և աստիճանաբար ջնջում հինը՝ ըստ ընտրված պահպանման, բայց այդ ընթացքում մենք չենք կորցնում պահեստավորված կետերից վերականգնելու հնարավորությունը։ Շատ օգտակար բան, երբ մենք կա՛մ ունենք ապարատային մի կտոր, որը մոտենում է իր կյանքի ավարտին և պետք է փոխարինենք այն, կա՛մ մենք պարզապես պետք է ազատենք այն ավելի կարևոր բանի համար, բայց այն վերցնելու և ամեն ինչ միանգամից տեղափոխելու տեղ չկա: Կամ այն ​​չի կարող ջնջվել:

Համապատասխանաբար, գործողության սկզբունքը բավականին պարզ է. անհրաժեշտ է արգելել բոլոր գրելու գործողությունները (նոր տվյալների հայտնվելը), թողնելով ընթերցումը (վերականգնումները) և ջնջելը (պահպանումը):

Երկու ռեժիմներն էլ կարող են օգտագործվել միաժամանակ, բայց հիշեք, որ սպասարկումն ավելի բարձր առաջնահերթություն ունի:

Որպես օրինակ, դիտարկեք SOBR-ը, որը բաղկացած է երկու չափերից: Ենթադրենք, որ առաջին չորս օրվա ընթացքում մենք ստեղծել ենք կրկնօրինակներ Forward Forever Incremental ռեժիմում, այնուհետև կնքում ենք չափը, ինչը հանգեցնում է նրան, որ մենք նախաձեռնում ենք նոր ակտիվի ստեղծումը երկրորդ հասանելի չափով: Եթե ​​մեր պահպանումը չորսն է, ապա երբ փակված տարածության վրա գտնվող ամբողջ շղթան դուրս է գալիս իր սահմաններից, այն ջնջվում է հանգիստ խղճով։

Կան իրավիճակներ, երբ ջնջումը տեղի է ունենում ավելի վաղ: Օրինակ, սա Forward incremental-ն է՝ պարբերական լրացումներով: Եթե ​​մենք առաջին երկու օրվա ընթացքում ստեղծել ենք ամբողջական կրկնօրինակներ, իսկ հինգշաբթի մենք որոշել ենք կնքել պահեստը, ապա ուրբաթ օրը, երբ ստեղծվի նոր կրկնօրինակում, երկուշաբթիի ֆայլը կջնջվի, քանի որ այս կետում կախվածություն չկա: Իսկ կետն ինքնին ոչ մեկից կախված չէ։ Այնուհետև սպասում ենք, մինչև ստեղծվեն չորս կետեր հասանելի չափով և ջնջում ենք մնացած երեքը, որոնք չեն կարող ջնջվել միմյանցից անկախ։

Reverse Incremental-ով ամեն ինչ ավելի պարզ է: Դրանում ամենահին կետերը ոչնչից կախված չեն և կարող են ապահով կերպով ջնջվել։ Հետևաբար, հենց որ նոր .vbk ստեղծվի նոր չափով, հին .vrb-ները հերթով կջնջվեն։

Ի դեպ, ինչու ենք մենք ամեն անգամ ստեղծում նոր .vbk. եթե մենք այն չստեղծեինք, այլ շարունակեինք հավելումների հին շղթան, ապա հին .vbk-ն անսահման երկար ժամանակ կսառեր ցանկացած ռեժիմում՝ կանխելով դրա ջնջումը։ Հետևաբար, որոշվեց, որ չափը կնքվելուն պես մենք ստեղծում ենք ամբողջական կրկնօրինակում անվճար տարածության վրա:

Ամեն ինչ ավելի բարդ է հզորության հրաձգարանի հետ կապված:

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

Մոտավորապես նույնը տեղի է ունենում շարժման ռեժիմում՝ մենք սպասում ենք ռետուշի, ջնջում ենք հինը տեղական պահեստում և ջնջում ենք օբյեկտի պահեստում պահվածը։

Հետաքրքիր օրինակ Forever forward incremental-ի հետ: Մենք տեղադրում ենք պահպանում երեք կետերում և երկուշաբթի սկսում ենք կրկնօրինակումներ պատրաստել, որոնք պարբերաբար պատճենվում են ամպի մեջ: Պահեստը կնքելուց հետո կրկնօրինակները շարունակում են ստեղծվել՝ պահպանելով երեք կետ, սակայն հզորության գծիկում պահվող տվյալները մնում են կախված և չեն կարող ջնջվել: Հետևաբար, մենք սպասում ենք մինչև հինգշաբթի, երբ մեր .vbk-ն դուրս կգա պահպանման սահմաններից, և միայն դրանից հետո մենք հանգիստ ջնջում ենք ողջ պահպանված շղթան։

Եվ մի փոքր հերքում. այստեղ բոլոր օրինակները ցուցադրվում են մեկ մեքենայի միջոցով: Եթե ​​ձեր կրկնօրինակում ունեք դրանցից մի քանիսը, ապա դրանց ռետուշը կտարբերվի՝ կախված նրանից՝ Active Full-ը պատրաստվել է, թե ոչ:

Դա հիմնականում այն ​​է, ինչ կա դրա համար: Այսպիսով, եկեք անցնենք ամենակարևոր հատկանիշին.

Անփոփոխելիություն

Ինչպես նախորդ կետերում, առաջինն այն է, թե ինչ խնդիր է լուծում այս գործառույթը: Հենց որ մենք վերբեռնում ենք մեր պահուստները ինչ-որ տեղ պահեստավորման համար, մեծ ցանկություն է առաջանում երաշխավորել դրանց անվտանգությունը, այսինքն՝ ֆիզիկապես արգելել դրանց ջնջումը և ցանկացած փոփոխություն տվյալ պահման ընթացքում: Ներառյալ ադմինիստրատորները, ներառյալ նրանց արմատային հաշիվները: Սա թույլ է տալիս պաշտպանել դրանք պատահական կամ դիտավորյալ վնասներից: Յուրաքանչյուր ոք, ով աշխատում է AWS-ով, կարող է հանդիպել նմանատիպ գործառույթի, որը կոչվում է Object Lock:

Հիմա եկեք նայենք ռեժիմին ընդհանուր առումներով, ապա խորանանք մանրամասների մեջ: Մեր օրինակում Անփոփոխելիությունը կմիացվի մեր հզորության հրաձգարանի համար՝ չորս օր պահպանմամբ: Իսկ կրկնօրինակում միացված է Copy ռեժիմը։

Անփոփոխությունը ոչ մի կերպ չի փոխազդում ընդհանուր պահպանման հետ: Օրինակ՝ ավելորդ միավորներ կամ նման բան չի ավելացնում։ Պարզապես մարդը չի կարող չորս օրվա ընթացքում ջնջել պահուստային ֆայլերը: Եթե ​​կրկնօրինակեք երկուշաբթի օրը, դուք կկարողանաք ջնջել դրա ֆայլը միայն ուրբաթ օրը:

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

Հիմա հիանալի ժամանակ է բացատրելու մեր բլոկների ստեղծման տեխնոլոգիան: Կամ արգելափակել սերունդը: Դա անելու համար հաշվի առեք այն իրավիճակը, որը հանգեցրեց դրա տեսքին:

Վերցնենք վեց օրվա ժամանակային սանդղակը, իսկ ստորև կնշենք անփոփոխության ակնկալվող ավարտի ժամանակը: Առաջին օրը մենք վերցնում և ստեղծում ենք ֆայլ, որը բաղկացած է տվյալների բլոկից և դրա մետատվյալներից: Եթե ​​անփոփոխելիությունը սահմանված է երեք օր, ապա տրամաբանական է ենթադրել, որ չորրորդ օրը տվյալները կբացվեն և կջնջվեն: Երկրորդ օրը մենք կավելացնենք նոր ֆայլ2, որը բաղկացած է նույն կարգավորումներով b բլոկից։ Ա-ի բլոկը դեռ պետք է հեռացվի չորրորդ օրը: Բայց երրորդ օրը սարսափելի բան է տեղի ունենում՝ ստեղծվում է File3 ֆայլ, որը բաղկացած է նոր d բլոկից և հին բլոկի հղումից a: Սա նշանակում է, որ բլոկի և դրա անփոփոխելիության համար դրոշը պետք է վերականգնվի նոր ամսաթվի վրա, որը տեղափոխվում է վեցերորդ օր: Եվ այստեղ խնդիր է առաջանում՝ իրական կրկնօրինակումներում կան հսկայական թվով նման բլոկներ։ Իսկ դրանց անփոփոխության ժամկետը երկարացնելու համար պետք է ամեն անգամ հսկայական թվով հարցումներ կատարել։ Եվ իրականում սա կլինի գրեթե անվերջանալի ամենօրյա գործընթաց, քանի որ մեծ հավանականության դեպքում մենք յուրաքանչյուր պատճենի հետ կգտնենք չկրկնվող բլոկների հսկայական կուտակումներ: Ի՞նչ է նշանակում օբյեկտների պահպանման մատակարարների մեծ թվով հարցումներ: Ճիշտ! Ամսվա վերջին հսկայական հաշիվ.

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

Շարունակենք դիտարկել նույն իրավիճակը, բայց բլոկային գեներացիայով։ Առաջին օրը մենք ստեղծում ենք file1 բլոկ a-ից և մետատվյալներից: Մենք ավելացնում ենք սերնդի ժամանակաշրջանը և անփոփոխությունը, սա նշանակում է, որ ֆայլը ջնջելու հնարավորությունը կլինի վեցերորդ օրը: Եթե ​​երկրորդ օրը մենք ստեղծենք File2, որը բաղկացած է b բլոկից և a արգելափակման հղումից, ապա ոչինչ չի պատահում ակնկալվող ջնջման ամսաթվին: Նա կանգնեց այնպես, ինչպես վեցերորդ օրը: Եվ այսպիսով մենք փորձում ենք գումար խնայել հարցումների քանակի վրա: Միակ իրավիճակը, երբ ժամկետը կարող է փոխվել, այն է, եթե սերնդի ժամկետը լրացել է: Այսինքն, եթե երրորդ օրը նոր File3-ը պարունակում է a արգելափակման հղում, ապա կավելացվի սերունդ 2, քանի որ Gen1-ն արդեն սպառվել է: Իսկ a բլոկը ջնջելու ակնկալվող ամսաթիվը կտեղափոխվի ութերորդ օր: Սա մեզ թույլ է տալիս կտրուկ նվազեցնել կրկնօրինակված բլոկների ժամկետը երկարացնելու հարցումների քանակը, ինչը հաճախորդներին խնայում է տոննա գումար:

Տեխնոլոգիան ինքնին հասանելի է S3 և S3-ի հետ համատեղելի ապարատների օգտագործողների համար, որոնց արտադրողները երաշխավորում են, որ դրանց ներդրումը չի տարբերվում Amazon-ից: Այստեղից է գալիս օրինական հարցի պատասխանը, թե ինչու Azure-ը չի աջակցվում. նրանք ունեն նմանատիպ հատկություն, բայց այն աշխատում է բեռնարկղերի, այլ ոչ թե առանձին օբյեկտների մակարդակով: Ի դեպ, Amazon-ն ինքն ունի օբյեկտի կողպում երկու ռեժիմով՝ համապատասխանության և կառավարման: Երկրորդ դեպքում, կա հավանականություն, որ ադմիններից վերև գտնվող ամենամեծ ադմինը և արմատներից վերև գտնվող արմատը, չնայած օբյեկտի կողպմանը, դեռ ջնջում են տվյալները: Համապատասխանության դեպքում ամեն ինչ ամուր է գամված, և ոչ ոք չի կարող ջնջել կրկնօրինակները։ Նույնիսկ Amazon-ի ադմինները (ըստ նրանց պաշտոնական հայտարարությունների): Սա այն ռեժիմն է, որը մենք աջակցում ենք:

Եվ, ինչպես միշտ, մի քանի օգտակար հղումներ.

• Մոտ Բլոկի սերունդ ամեն մանրամասնությամբ։
• մասին ամբողջ տեղեկատվությունը Veeam Backup & Replication 10 իր լավագույն դեպքում
• О Հզորության մակարդակ մանրամասնորեն

Source: www.habr.com