Capacity Tier (же биз аны Vim ичинде деп атагандай - captir) Veeam Backup жана Replication 9.5 Update 4 доорунда Archive Tier деген ат менен пайда болгон. Анын артында турган идея - операциялык калыбына келтирүү деп аталган терезеден түшүп калган камдык көчүрмөлөрдү объект сактагычка жылдыруу. Бул азыраак болгон колдонуучулар үчүн диск мейкиндигин тазалоого жардам берди. Жана бул параметр Move Mode деп аталды.

Бул жөнөкөй (көрүлгөндөй) аракетти аткаруу үчүн эки шартты аткаруу жетиштүү болду: көчүрүлгөн камдык көчүрмөнүн бардык пункттары UIде ачык коюлган, жогоруда айтылган оперативдүү калыбына келтирүү терезесинин чегинен тышкары болушу керек. Ал эми экинчи: чынжыр деп аталган "мөөрүлгөн түрдө" болушу керек (пломбаланган резервдик чынжыр же жигердүү эмес резервдик чынжыр). Башкача айтканда, убакыттын өтүшү менен бул чынжырда эч кандай өзгөрүүлөр болбойт.

Бирок VBR v10до концепция жаңы функциялар менен толукталды - Көчүрмө режими, Мөөр басылган режим жана айтууга кыйын болгон Immutability деген нерсе пайда болду.

Булар биз бүгүн сүйлөшө турган кызыктуу нерселер. Биринчиден, ал VBR9.5u4те кандай иштегени, андан кийин онунчу версиядагы өзгөрүүлөр жөнүндө.

Ал эми таза тилдин чемпиондору кечирип коюшсун, бирок которо албаган терминдер өтө көп.
Ошентип, бул жерде бир тонна англисизмдер болот.
Жана көп GIF.
Жана сүрөттөр.

• Кичине өкүнбөй. Макаланын автору.

Болгондой

Келгиле, оперативдүү калыбына келтирүү терезесин жана мөөр басылган камдык көчүрмөнү талдоодон баштайлы (же алар жигердүү эмес резервдик чынжырдын документтеринде айтылгандай). Алардын түшүнүгү болбосо, андан ары түшүндүрүү мүмкүн эмес.

Сүрөттө көрүп тургандай, бизде маалымат блоктору бар резервдик чынжыр бар, ал кубаттуулук деңгээли туташтырылган репозиторийдин SOBR Performance деңгээлинде жайгашкан. Биздин оперативдүү резервдик терезе үч күн.

Демек, дүйшөмбү күнү түзүлгөн .vbk терезеси үч күнгө коюлган мурунку чынжырды мөөр басат. Жана бул үч күндөн улуураак нерселердин баарын атуу аянтчасына аман-эсен ташый баштасаңыз болот дегенди билдирет.

Бирок мөөр басылган чынжыр деген эмнени билдирген жана 4-жаңыртуунун кубаттуулугуна эмне жөнөтүлүшү мүмкүн?

Forward Incremental, чынжырды мөөр басуунун белгиси жаңы толук камдык көчүрмөнү түзүү болуп саналат. Жана бул толук камдык көчүрмө кандайча алынганы маанилүү эмес: синтетикалык толук жана активдүү толук камдык көчүрмөлөр да каралат.

Тескерисинче, бул бардык файлдар операциялык терезеге түшпөйт.

Артка кайтаруу менен алдыга өсүү учурунда, булар артка кайтаруу жана .vbk, эгерде аткаруу деңгээлинде башка .vbk бар болсо.

Эми Камдык көчүрмө чынжырлары менен иштөө вариантын карап көрөлү. Бул жерде GFS сактоого кирген нерселер гана ташылган. Анткени акыркы камдык көчүрмө чынжырларында сакталган нерселердин баары тигил же бул жол менен өзгөртүлүшү мүмкүн.

Эми капоттун астын карап көрөлү. Ал жерде, суусуздануу деп аталган процесс пайда болот - бош резервдик файлдарды масштабда калтыруу жана бул файлдардан блокторду сыйымдуулуктун чегине сүйрөө. Бул процессти оптималдаштыруу үчүн суусуздануу индекси деп аталган индекс колдонулат, ал буга чейин кубаттуулуктагы атуу диапазонуна көчүрүлгөн блокторду көчүрүүдөн качууга мүмкүндүк берет.

Мисал менен мунун кандай болорун карап көрөлү: Келгиле, бизде транзакция терезесинен чыккан жана мөөр басылган чынжырга таандык .vbk бар дейли. Бул биздин аны сыйымдуулук менен атуу полигонуна которууга толук укугубуз бар экендигин билдирет. Жылдыруу учурунда метадайындар файлы өткөрүлүп берилген файлдын сыйымдуулугунун сызыкчасында жана блокторунда түзүлөт. Шилтеме деңгээлиндеги метаберилиштер файлы биздин файлдын кандай блоктордон турганын сүрөттөйт. Сүрөттөгү учурда биздин биринчи файлыбыз a, b, c блокторунан турат жана метаберилиштер бул блокторго шилтемелерди камтыйт. Бизде экинчи .vbk файлы болгондо, жылдырууга даяр жана a, b жана d блокторунан турган, биз суусуздануу индексин талдап, d блогун гана өткөрүп берүү керектигин түшүнөбүз. Анын метадайындар файлы мурунку эки блокко жана бир жаңысына шилтемелерди камтыйт.

Демек, бул боштуктарды кайра маалыматтар менен толтуруу процесси регидратация деп аталат. Ал мурунтан эле жергиликтүү аткаруу даражасы боюнча эң эски .vbk файлынын негизинде өзүнүн регидратация индексин колдонот. Башкача айтканда, эгерде колдонуучу файлды кубаттуулуктагы атуу диапазонунан кайтарууну кааласа, биз адегенде эң эски толук камдык блоктордун индексин түзөбүз жана сыйымдуулук атуу галереясынан жетишпеген блокторду гана өткөрүп беребиз. Сүрөттө көрсөтүлгөн учурда, FullBackup1.vbk регидратациялоо индексине ылайык регидратациялоо үчүн бизге кубаттуулуктагы атуу тилкесинен алынган С блогу гана керек. сактоо булут объект сыйымдуулугу атуу полигону катары кызмат кылган болсо, бул акчанын эбегейсиз өлчөмдө үнөмдөөгө мүмкүндүк берет.

Бул жерде бул технология WAN Accelerators колдонулган технология менен бирдей сезилиши мүмкүн, бирок ал ошондой көрүнөт. Акселераторлордо дедупликация глобалдуу болуп саналат; бул жерде локалдык дедупликация ар бир файлдын ичинде белгилүү бир офсетте колдонулат. Бул чечилип жаткан милдеттердин айырмачылыгынан улам болот: бул жерде биз чоң толук резервдик файлдарды көчүрүп алышыбыз керек жана биздин изилдөөбүз боюнча, алардын ортосунда узак убакыт өтсө дагы, бул дедупликация алгоритми эң жакшы натыйжаны берет.

Бирок индекстердин кудайы үчүн көбүрөөк индекстер! Маалыматтарды калыбына келтирүү үчүн индекс да бар! Биз кубаттуулук сызыкчасында жайгашкан машинаны калыбына келтире баштаганда, биз аткаруу сызыкчасында жок уникалдуу маалымат блокторун гана окуйбуз.

Бул кантип болду?

Мунун баары киришүү бөлүгү үчүн. Бул кыйла майда-чүйдөсүнө чейин, бирок жогоруда айтылгандай, бул майда-чүйдөсүнө чейин жаңы функциялардын кантип иштээрин түшүндүрүү мүмкүн эмес. Андыктан, көпкө созулбай, биринчисине өтөбүз.

Көчүрмө режими

Ал негизинен учурдагы технологияларга негизделген, бирок колдонуунун такыр башка логикасын камтыйт. 

Бул режимдин максаты - жергиликтүү деңгээлде жайгашкан бардык маалыматтардын кубаттуулук сызыкчасында көчүрмөсү болушун камсыз кылуу.

Жылдыруу жана көчүрүү режимдерин салыштырсаңыз, ал төмөнкүдөй болот:

• Мөөр басылган чынжырды гана жылдырууга болот. Көчүрмө режиминде, резервдик жумушта эмне болуп жатканына карабастан, бардыгы өткөрүлүп берилет.
• Жылдыруу файлдар оперативдүү резервдик көчүрүү терезесинин чегинен чыгып кеткенде, ал эми көчүрүү камдык файл пайда болору менен иштетилет.
• Көчүрүү үчүн жаңы маалыматтардын мониторинги тынымсыз ишке ашат, ал эми жылдыруу үчүн 4 саатта бир жолу иштетилип турат.

Жаңы режимди карап чыгууда мен жөнөкөй мисалдардан татаалдарына өтүүнү сунуштайм.

Эң кеңири таралган учурда, бизде жөн гана өсүштөр менен жаңы файлдар бар жана биз аларды жөн гана сыйымдуулук атуу диапазонуна көчүрөбүз. Камдык жумушта кандай режим колдонулганына карабастан, чынжырдын мөөр басылган бөлүгүнө таандыкпы же жокпу, биздин операциялык терезебиздин мөөнөтү бүткөнүнө карабастан. Жөн эле алып, көчүрүп алышкан.

Мунун артында процесс дагы эле жогоруда айтылгандай суусузданууда. Көчүрмө режиминде, ал ошондой эле сактагычыбыздагы блокторду көчүрүп албашыбызды камсыздайт. Бир гана айырмасы, эгерде кино режиминде биз чыныгы файлдарды жасалма файлдар менен алмаштырсак, бул жерде биз аларга эч кандай тийбейбиз жана бардыгын мурункудай калтырабыз. Болбосо, бул кылдаттык менен акчаны жана убакытты үнөмдөө үчүн аракет кылган так ошол эле суусуздануу индекси болуп саналат.

Суроо туулат - эгер сиз UIди карасаңыз, бир эле учурда эки вариантты тандоо мүмкүнчүлүгү бар. Мындай айкалыштырылган режим кантип иштейт?

Келгиле, аны аныктайлы.

Башталышы стандарттуу: камдык файл түзүлөт жана дароо көчүрүлөт. Ага кошумча түзүлөт, ошондой эле көчүрүлөт. Бул файлдар биздин иштөө терезебизден чыгып кеткенин жана мөөр басылган чынжыр пайда болгонун түшүнгөн учурга чейин болот. Бул учурда биз суусуздандыруу операциясын жасайбыз жана бул файлдарды жасалма файлдар менен алмаштырабыз. Албетте, биз кубаттуулугу атуу тилкесинде кайра эч нерсе көчүрүп жок.

Мунун баары кызыктуу логика интерфейстеги бир гана кутуча үчүн жооп берет: камдык көчүрмөлөрдү түзүлөөрү менен объект сактагычка көчүрүңүз.

Бул Көчүрүү режими бизге эмне үчүн керек?

Суроону мындайча кайталаганыбыз жакшы: анын жардамы менен биз кандай коркунучтардан коргойбуз? Ал бизге кандай көйгөйдү чечүүгө жардам берет?

Жооп айкын: албетте, бул маалыматтарды калыбына келтирүү. Эгерде бизде объект сактагычта жергиликтүү маалыматтардын толук көчүрмөсү бар болсо, анда биздин продукт кандай болбосун, биз ар дайым шарттуу Amazonдо жайгашкан файлдардан маалыматтарды калыбына келтире алабыз.

Андыктан, келгиле, эң жөнөкөйдөн татаалга чейин мүмкүн болгон сценарийлерди карап көрөлү.

Биздин башыбызга түшө турган эң жөнөкөй кырсык - бул резервдик чынжырдагы файлдардын биринин жеткиликсиздиги.

Эң өкүнүчтүүсү, биздин СОБР репозиторийибиздин бир жери бузулду.

Бүтүндөй SOBR репозиторийине жеткиликсиз болуп калганда, ал ого бетер начарлайт, бирок кубаттуулук атуу тилкеси иштеп жатат.
Жана баары чындап эле жаман - бул резервдик сервер өлүп калганда жана сиздин биринчи каалооңуз - он мүнөттүн ичинде Канаданын чек арасына чуркоо аракети.

Эми ар бир жагдайды өзүнчө карап көрөлү.

Биз бир (жана бир нече) камдык файлдарды жоготкондо, биз репозиторийлерди кайра издөө процессин башташыбыз керек жана жоголгон файл жасалма файл менен алмаштырылат. Жана регидратация процессин колдонуу менен (макаланын башында талкууланган), колдонуучу кубаттуулуктагы атуу диапазонунан маалыматтарды жергиликтүү сактоого жүктөп ала алат.

Азыр абал татаалыраак. Биздин SOBR Performance режиминде иштеген эки экстенттен турат деп ойлойлу, бул биздин .vbk жана .vib алардын үстүнө бир калыпта эмес катмарда таралганын билдирет. Жана кайсы бир убакта, экстенттердин бири жеткиликсиз болуп калат жана колдонуучу тез арада машинаны калыбына келтириши керек, анын маалыматтарынын бир бөлүгү дал ушул даражада.

Колдонуучу калыбына келтирүү устасын ишке киргизет, ал калыбына келтиргиси келген чекитти тандайт жана уста иштеп жатып, ал жергиликтүү калыбына келтирүү үчүн зарыл болгон бардык маалыматтарга ээ эмес экенин түшүнөт, ошондуктан кубаттуулуктан түшүрүп алуу керек. галерея. Ошол эле учурда, жергиликтүү сактагычта калган блоктор булуттан түшүрүлбөйт. Калыбына келтирүү индексине даңк (ооба, бул макаланын башында да айтылган).

Бул иштин бир түрү бүт SOBR репозиторийине жеткиликсиз болуп калган. Бул учурда, бизде жергиликтүү сактагычтан көчүрө турган эч нерсе жок, жана бардык блоктор булуттан жүктөлөт.

Ал эми эң кызыктуу жагдай – резервдик сервер өлүп калган. Бул жерде эки вариант бар: администратор сонун жана конфигурациянын камдык көчүрмөсүн жасаган, ал эми администратор өзү жаман Пиноккио жана конфигурациянын камдык көчүрмөсүн жасаган эмес.

Биринчи учурда, ага жөн гана VBRдин таза орнотуусун бир жерге жайгаштыруу жана стандарттык каражаттарды колдонуу менен камдык көчүрмөдөн анын маалымат базасын калыбына келтирүү жетиштүү болот. Бул процесстин аягында баары өз нугуна келет. Же жогорудагы сценарийлердин бирине ылайык калыбына келтирилет.

Бирок, эгерде администратор өзүнүн душманы болсо, же конфигурациянын камдык көчүрмөсү да эпикалык ката кетирсе, анда биз аны тагдырдын ырайымына калтырбайбыз. Бул үчүн биз Import Object Storage деп аталган жаңы процедураны киргиздик. Ал SOBR репозиторийин кол менен кайра түзүү процессин өткөрүп жиберүүгө жана андан кийин кайра издөө менен ага кубаттуулуктагы атуу диапазонун кошууга жана Vim интерфейсине сактоо объектисин кошууга жана Import Storage Repository процедурасын иштетүүгө мүмкүндүк берет. Сиз менен камдык көчүрмөлөрүңүздүн ортосуна тоскоол боло турган жалгыз нерсе, эгерде камдык көчүрмөлөрүңүз шифрленген болсо, сырсөздү киргизүү өтүнүчү.

Бул, балким, Көчүрүү режими жөнүндө жана биз ага өтөбүз

Мөөр режими

Негизги идея жаңы камдык көчүрмөлөр репозиторийдин тандалган SOBR масштабында пайда болушу мүмкүн эмес. V10го чейин бизде Тейлөө режими болгон, анда репозиторий менен иштөөгө толугу менен тыюу салынган. Сактагычты жабуу үчүн катуу режимдин бир түрү, анда бир гана жолу резервдик көчүрмөлөрдү башка өлчөмдө ташыган Эвакуация баскычы бар.

Ал эми Мөөр басылган режим бул "жумшак" опциянын бир түрү: биз жаңы резервдик көчүрмөлөрдү түзүүгө тыюу салабыз жана тандалган сактоого ылайык эскилерин акырындык менен жок кылабыз, бирок процессте биз сакталган пункттардан калыбына келтирүү мүмкүнчүлүгүн жоготпойбуз. Өмүрүнүн аягына жакындап калган жабдыктын бир бөлүгү болсо жана аны алмаштыруу керек болгондо, же биз аны маанилүүрөөк бир нерсеге бошотушубуз керек болгондо, бул абдан пайдалуу нерсе, бирок аны алып, баарын дароо жылдырууга эч кандай жер жок. Же аны жок кылуу мүмкүн эмес.

Демек, иштөө принциби абдан жөнөкөй: бардык жазуу операцияларына (жаңы маалыматтардын пайда болушуна), окууну (калыбына келтирүү) жана өчүрүүнү (сактоо) калтырууга тыюу салуу керек.

Эки режим тең бир убакта колдонулушу мүмкүн, бирок Тейлөөнүн артыкчылыктуулугун унутпаңыз.

Мисал катары, эки масштабдан турган СОБРди карап көрөлү. Алгачкы төрт күн ичинде биз Forward Forever Incremental режиминде камдык көчүрмөлөрдү түздүк деп ойлойлу, андан кийин биз масштабды бекитебиз.Бул биз экинчи жеткиликтүү деңгээлде жаңы активдүү толукту түзүүнү демилгелегенибизге алып келет. Эгерде биздин кармап калуу төрт болсо, анда мөөр менен жабылган бүт чынжыр анын чегинен чыгып кеткенде, таза абийир менен жок кылынат.

Жок кылуу мурда пайда болгон жагдайлар бар. Мисалы, бул мезгил-мезгили менен толуктоо менен алдыга өсүү. Эгерде биз биринчи эки күндө толук камдык көчүрмөлөрдү түзүп, бейшемби күнү репозиторийди мөөр коюуну чечсек, анда жума күнү, жаңы камдык көчүрмө түзүлгөндө, дүйшөмбүдөгү файл жок кылынат, анткени бул жагынан эч кандай көз карандылык жок. Ал эми пункттун өзү эч кимден көз каранды эмес. Андан кийин биз төрт чекит жеткиликтүү деңгээлде түзүлгөнгө чейин күтөбүз жана калган үчөөнү жок кылабыз, аларды бири-биринен көз карандысыз жок кылуу мүмкүн эмес.

Reverse Incremental менен нерселер жөнөкөй. Анда эң эски пункттар эч нерседен көз каранды эмес жана коопсуз жок кылынышы мүмкүн. Ошондуктан, жаңы .vbk жаңы деңгээлде түзүлөөрү менен, эски .vrbs бир-бирден жок кылынат.

Айтмакчы, эмне үчүн биз ар бир жолу жаңы .vbk түзөбүз: эгерде биз аны түзбөй, бирок эски өсүү чынжырын уланта берсек, анда эски .vbk каалаган режимде чексиз узак убакытка тоңуп, анын өчүрүлүшүнө тоскоол болмок. Ошондуктан, масштаб мөөр басылгандан кийин, биз эркин масштабда толук резервдик көчүрмөнү түзөбүз деп чечтик.

Сыйлыктуу атуу тиричилиги менен нерселер татаалыраак.

Биринчиден, көчүрүү режимин карап көрөлү. Биз төрт күн бою жигердүү камдык көчүрмөлөрдү түзүп жатабыз деп ойлойлу, андан кийин кубаттуулуктагы атуу аянтчасы жабылды. Биз эч нерсени жок кылбайбыз, бирок момундук менен сактоого чыдайбыз, андан кийин биз кубаттуулуктагы атуу тилкесинен маалыматтарды жок кылабыз.

Болжол менен ушундай эле нерсе жылдыруу режиминде болот - биз ретушту күтөбүз, жергиликтүү сактагычтагы эскисин жок кылабыз жана объект сактагычында сакталганын өчүрөбүз.

Forever forward incremental менен кызыктуу мисал. Биз сактоону үч пунктка орнотобуз жана дүйшөмбү күнү булутка үзгүлтүксүз көчүрүлүп турган камдык көчүрмөлөрдү жасай баштайбыз. Сактагыч мөөр басылгандан кийин, үч пунктту сактоо менен камдык көчүрмөлөр түзүлө берет, бирок сыйымдуулук сызыкчасында сакталган маалыматтар көз каранды бойдон калууда жана жок кылынбайт. Ошондуктан, биз бейшембиге чейин күтөбүз, качан биздин .vbk кармап калуу чегинен чыгып кетет, ошондо гана биз бардык сакталган чынжырды тынчтандырабыз.

Ал эми кичинекей баш тартуу: бул жерде бардык мисалдар бир машина менен көрсөтүлгөн. Эгерде сиздин камдык көчүрмөңүздө алардын бир нечеси бар болсо, анда алардын ретушу Active Full жасалганына же жасалбаганына жараша айырмаланат.

Бул, негизинен, баары бар. Келгиле, эң оор өзгөчөлүктөргө өтөбүз -

Өзгөрүлбөс

Мурунку пункттардагыдай эле, биринчи нерсе бул функция кандай маселени чечет. Камдык көчүрмөлөрүбүздү сактоо үчүн бир жерге жүктөсөк, алардын коопсуздугуна кепилдик берүү, башкача айтканда, аларды жок кылууга жана берилген сактоо учурунда кандайдыр бир өзгөртүүгө физикалык түрдө тыюу салууга катуу каалоо пайда болот. Анын ичинде администраторлор, анын ичинде алардын түпкү аккаунттары астында. Бул аларды кокусунан же атайылап бузулуудан коргоого мүмкүндүк берет. AWS менен иштеген ар бир адам Object Lock деп аталган окшош функцияга туш болушу мүмкүн.

Эми жалпысынан режимди карап көрөлү, анан майда-чүйдөсүнө чейин карап көрөлү. Биздин мисалда, Өзгөрүлбөөчүлүк төрт күндүк сактоо менен биздин кубаттуу атуу полигонубуз үчүн иштетилет. Ал эми Көчүрмө режими камдык көчүрмөдө иштетилген.

Өзгөрбөстүк кандайдыр бир жол менен жалпы кармоо менен өз ара аракеттенбейт. Мисалы, кошумча упайларды же ушуга окшогон нерселерди кошпойт. Бул жөн гана адам төрт күндүн ичинде камдык файлдарды жок кыла албайт. Эгер сиз дүйшөмбү күнү камдык көчүрмөнү жасасаңыз, анда анын файлын жума күнү гана өчүрө аласыз.

Бардык мурда түшүндүрүлгөн суусуздануу, индекстер жана метаберилиштер так ошол эле бойдон иштей берет. Бирок бир шарт менен - ​​блок маалымат үчүн гана эмес, метадайындар үчүн да орнотулат. Бул айлакер чабуулчу биздин метаберилиштер базабызды жок кылууну чечкен учурда жана маалымат блоктору пайдасыз бинардык былжырга айланып кетпеши үчүн жасалат.

Азыр биздин блокторду түзүү технологиясын түшүндүрүү үчүн сонун убакыт. Же блок түзүү. Бул үчүн, анын пайда болушуна алып келген жагдайды карап көрөлү.

Келгиле, алты күндүк убакыт шкаласын алалы жана андан төмөн өзгөрүлбөстүктүн күтүлүп жаткан мөөнөтүн белгилейбиз. Биринчи күнү биз маалымат блогунан жана анын метадайындарынан турган файлды алып, түзөбүз. Эгерде өзгөрбөстүк үч күнгө коюлса, төртүнчү күнү маалыматтар кулпусу ачылып, жок кылынат деп айтуу логикага ылайыктуу. Экинчи күнү биз жаңы файлды кошобуз2, ошол эле орнотуулары менен б блогунан турган. Блок а дагы төртүнчү күнү алып салуу керек. Бирок үчүнчү күнү коркунучтуу нерсе болот - жаңы d блогунан жана эски а блогуна шилтемеден турган File3 файлы түзүлөт. Бул блок жана анын өзгөрбөс желекчеси алтынчы күнгө которулган жаңы датага кайра коюлушу керек дегенди билдирет. Жана бул жерде бир көйгөй туулат - чыныгы камдык көчүрмөдө мындай блоктордун көп саны бар. Жана алардын өзгөрбөс мөөнөтүн узартуу үчүн, ар бир жолу көп сандагы суроо-талаптарды жасоо керек. Чындыгында, бул дээрлик чексиз күнүмдүк процесс болот, анткени жогорку ыктымалдуулук менен биз ар бир көчүрмө менен дедупликацияланган блоктордун чоң стектерин табабыз. Объекттерди сактоо провайдерлеринин көп сандагы суроо-талаптары эмнени билдирет? Туура! Айдын аягында чоң эсеп.

Ал эми сүйүктүү кардарларыңызды олуттуу акчага ачыкка чыгарбоо үчүн блокторду түзүү механизми ойлоп табылган. Бул биз белгиленген өзгөрбөс мөөнөткө кошо турган кошумча мөөнөт. Төмөндөгү мисалда бул мөөнөт эки күн. Бирок бул бир гана мисал. Чынында, алар бир айлык кулпу учурунда болжол менен он кошумча күн берет, өз формуласын колдонушат.

Келгиле, ошол эле жагдайды карап көрөлү, бирок блоктук генерация менен. Биринчи күнү биз a блокунан жана метаберилиштерден file1 түзөбүз. Биз генерация мезгилин жана өзгөрбөстүктү кошобуз - бул файлды жок кылуу мүмкүнчүлүгү алтынчы күнү болот дегенди билдирет. Эгерде экинчи күнү биз File2 түзсөк, б блогунан жана а блокко шилтемеден турган болсо, анда күтүлгөн жок кылуу датасына эч нерсе болбойт. Ал алтынчы күнү кандай болсо, ошондой турду. Ошентип, биз суроо-талаптардын санын үнөмдөөгө аракет кылып жатабыз. Мөөнөтү жылдырылышы мүмкүн болгон бир гана жагдай, эгерде генерация мөөнөтү өтүп кетсе. Башкача айтканда, үчүнчү күнү жаңы File3 a бөгөттөө үчүн шилтемени камтыса, анда Gen2 мөөнөтү бүткөндүктөн 1-муун кошулат. Ал эми блокту жок кылуунун күтүлгөн күнү сегизинчи күнгө жылат. Бул бизге дедупликацияланган блоктордун иштөө мөөнөтүн узартуу боюнча суроо-талаптардын санын кескин кыскартууга мүмкүндүк берет, бул кардарларга бир тонна акчаны үнөмдөйт.

Технологиянын өзү S3 жана S3 шайкеш жабдыктарынын колдонуучулары үчүн жеткиликтүү, алардын өндүрүүчүлөрү аларды ишке ашыруу Amazonдан айырмаланбайт деп кепилдик беришет. Демек, Azure эмне үчүн колдоого алынбайт деген мыйзамдуу суроого жооп - алардын окшош өзгөчөлүгү бар, бирок ал жеке объектилерде эмес, контейнерлердин деңгээлинде иштейт. Айтмакчы, Amazonдун өзү объектилерди эки режимде кулпуга ээ: шайкештик жана башкаруу. Экинчи учурда, администраторлордун үстүндөгү эң чоң администратор жана тамырлардын үстүндөгү тамыр объекттин кулпусуна карабастан, дагы эле маалыматтарды жок кылуу мүмкүнчүлүгү бар. Талапка ылайык келгенде, бардыгы бекем кагылган жана камдык көчүрмөлөрдү эч ким жок кыла албайт. Ал тургай Amazon администраторлору (алардын расмий билдирүүлөрүнө ылайык). Бул биз колдогон режим.

Жана, адаттагыдай эле, кээ бир пайдалуу шилтемелер:

• боюнча Блок түзүү ар бир майда-чүйдөсүнө чейин.
• жөнүндө бардык маалыматтар Veeam Backup & Replication 10 эң жакшы
• О Кубаттуулук деңгээли майда-чүйдөсүнө чейин

Source: www.habr.com