Сыйымдылық деңгейі (немесе біз оны Vim ішінде деп атаймыз - captir) Veeam Backup және Replication 9.5 4 жаңартуы кезінде Archive Tier атауымен пайда болды. Оның артындағы идея операциялық қалпына келтіру деп аталатын терезеден түсіп қалған сақтық көшірмелерді нысанды сақтауға жылжытуға мүмкіндік беру болып табылады. Бұл аз пайдаланушылар үшін дискілік кеңістікті босатуға көмектесті. Және бұл опция Move Mode деп аталды.

Бұл қарапайым (мүмкін болғандай) әрекетті орындау үшін екі шартты орындау жеткілікті болды: жылжытылған сақтық көшірмедегі барлық нүктелер UI-де нақты орнатылған жоғарыда аталған операциялық қалпына келтіру терезесінің шекарасынан тыс болуы керек. Екіншісі: тізбек «тұйықталған пішінде» (тұйықталған резервтік тізбек немесе белсенді емес резервтік тізбек) болуы керек. Яғни, уақыт өте келе бұл тізбекте ешқандай өзгерістер болмайды.

Бірақ VBR v10-де концепция жаңа функциялармен толықтырылды - Көшіру режимі, Жабық режим және айтуы қиын "Өзгермеушілік" атауы бар нәрсе пайда болды.

Бұл біз бүгін айтатын қызықты нәрселер. Алдымен, оның VBR9.5u4-те қалай жұмыс істегені туралы, содан кейін оныншы нұсқадағы өзгерістер туралы.

Ал таза тілдің майталмандары кешірсін, бірақ аударылмайтын терминдер өте көп.
Сонымен, мұнда көптеген англицизмдер болады.
Және көптеген гифтер.
Және суреттер.

• Кішкене өкінбестен. Мақала авторы.

Қалай болды

Ал, операциялық қалпына келтіру терезесін және мөрленген сақтық көшірмені талдаудан бастайық (немесе олар белсенді емес сақтық көшірме тізбегі құжаттамасында аталады). Олардың түсінігі болмаса, одан әрі түсіндіру мүмкін болмайды.

Суретте көріп отырғанымыздай, бізде Сыйымдылық деңгейі қосылған репозиторийдің SOBR өнімділік деңгейінде орналасқан деректер блоктары бар сақтық көшірме тізбегі бар. Біздің операциялық сақтық көшірме тереземіз үш күн.

Тиісінше, дүйсенбіде жасалған .vbk терезесі үш күнге орнатылған алдыңғы тізбекті мөрлейді. Бұл үш күннен асқан барлық заттарды ату алаңына қауіпсіз тасымалдауға болатынын білдіреді.

Бірақ тығыздалған тізбек деген нені білдіреді және 4-жаңартуда сыйымдылықты түсіру полигонына не жіберуге болады?

Forward Incremental, тізбекті тығыздау белгісі жаңа толық резервтік көшірме жасау болып табылады. Бұл толық сақтық көшірменің қалай алынғаны маңызды емес: синтетикалық толық және белсенді толық сақтық көшірмелер де қарастырылады.

Кері жағдайда бұл барлық файлдар операциялық терезеге түспейді.

Кері қайтарулармен алға ұлғайту жағдайында бұлардың барлығы кері қайтарулар және .vbk, егер өнімділік ауқымында басқа .vbk болса.

Енді сақтық көшірме тізбектерімен жұмыс істеу нұсқасын қарастырайық. Мұнда тек GFS сақтауға жататын заттар тасымалданды. Өйткені соңғы сақтық көшірме тізбегінде сақталған барлық нәрсені бір жолмен өзгертуге болады.

Енді сорғыштың астына қарайық. Онда дегидратация деп аталатын процесс орын алады - сақтық көшірме файлдарын көлемде қалдыру және блоктарды осы файлдардан сыйымдылық түсіру диапазонына апару. Бұл процесті оңтайландыру үшін сусыздандыру индексі деп аталатын көрсеткіш пайдаланылады, ол қазірдің өзінде қуатты түсіру диапазонына көшірілген блоктарды көшірмеуге мүмкіндік береді.

Мысал арқылы бұл қалай көрінетінін көрейік: Бізде транзакция терезесінен шыққан және мөрленген тізбекке жататын .vbk бар делік. Бұл біздің оны сыйымдылық ату полигонына ауыстыруға толық құқығымыз бар екенін білдіреді. Жылжыту кезінде метадеректер файлы тасымалданатын файлдың сыйымдылық сызықшасында және блоктарында жасалады. Сілтеме деңгейіндегі метадеректер файлы файлымыздың қандай блоктардан тұратынын сипаттайды. Суреттегі жағдайда біздің бірінші файлымыз a, b, c блоктарынан тұрады және метадеректерде осы блоктарға сілтемелер бар. Бізде жылжытуға дайын және a, b және d блоктарынан тұратын екінші .vbk файлы болғанда, біз сусыздандыру индексін талдай отырып, тек d блогын тасымалдау керек екенін түсінеміз. Оның метадеректер файлында екі алдыңғы және бір жаңа блокқа сілтемелер болады.

Тиісінше, бұл бос орындарды деректермен толтыру процесі регидратация деп аталады. Ол жергілікті өнімділік ауқымындағы ең ескі .vbk файлына негізделген өзінің регидратация индексін әлдеқашан пайдаланады. Яғни, егер пайдаланушы сыйымдылықты түсіру диапазонынан файлды қайтарғысы келсе, біз алдымен ең ескі толық резервтік көшірменің блоктарының индексін жасаймыз және сыйымдылықты түсіру галереясынан жетіспейтін блоктарды ғана тасымалдаймыз. Суретте көрсетілген жағдайда, FullBackup1.vbk регидратация индексі бойынша регидратациялау үшін бізге тек С блогы қажет, біз оны сыйымдылық түсіру қашықтығынан аламыз. Сақтау бұлты нысаны сыйымдылық түсіру қашықтығы ретінде қызмет етсе, бұл үлкен ақшаны үнемдеуге мүмкіндік береді.

Бұл жерде бұл технология WAN үдеткіштерінде қолданылатын технологиямен бірдей болып көрінуі мүмкін, бірақ ол солай көрінеді. Үдеткіштерде деупликация жаһандық болып табылады; мұнда жергілікті қайталану әр файлдың ішінде белгілі бір ығысуда қолданылады. Бұл шешілетін тапсырмалардың айырмашылығына байланысты орын алады: мұнда біз үлкен толық сақтық көшірме файлдарын көшіруіміз керек және біздің зерттеулеріміз бойынша, олардың арасында ұзақ уақыт өтсе де, бұл қайталау алгоритмі ең жақсы нәтиже береді.

Бірақ индекстер құдайы үшін көбірек индекстер! Сондай-ақ деректерді қалпына келтіруге арналған индекс бар! Сыйымдылық жолағында орналасқан машинаны қалпына келтіруді бастағанда, біз өнімділік жолағында жоқ бірегей деректер блоктарын ғана оқимыз.

Бұл қалай болды?

Мұның бәрі кіріспе бөлімі үшін. Бұл өте егжей-тегжейлі, бірақ жоғарыда айтылғандай, бұл мәліметтерсіз жаңа функциялардың қалай жұмыс істейтінін түсіндіру мүмкін емес. Сондықтан, көп ұзамай, біріншісіне көшейік.

Көшіру режимі

Ол негізінен қолданыстағы технологияларға негізделген, бірақ пайдаланудың мүлдем басқа логикасын жүзеге асырады. 

Бұл режимнің мақсаты жергілікті деңгейде орналасқан барлық деректердің сыйымдылық сызықшасында көшірмесі болуын қамтамасыз ету.

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

• Тек тығыздалған тізбекті жылжытуға болады. Көшіру режимі жағдайында сақтық көшірме тапсырмасында не болып жатқанына қарамастан, барлығы толығымен тасымалданады.
• Жылжыту файлдар операциялық сақтық көшірме терезесінің шекарасынан шыққан кезде іске қосылады және көшіру сақтық көшірме файлы пайда болған бойда іске қосылады.
• Көшіру үшін жаңа деректерді бақылау үнемі жүзеге асырылады, ал жылжыту үшін ол 4 сағат сайын іске қосылды.

Жаңа режимді қарастыра отырып, мен қарапайым мысалдардан күрделіге көшуді ұсынамын.

Ең көп таралған жағдайда, бізде қадамдары бар жаңа файлдар бар және біз оларды жай ғана сыйымдылық түсіру диапазонына көшіреміз. Сақтық көшірме жұмысында қандай режим қолданылатынына қарамастан, оның тізбектің мөрленген бөлігіне жататынына немесе жатпағанына қарамастан, біздің операциялық тереземіздің мерзімі аяқталғанына қарамастан. Олар оны алып, көшіріп алды.

Мұның артындағы процесс жоғарыда сипатталғандай әлі де сусыздандыру болып табылады. Көшіру режимінде ол біздің жадымызда бұрыннан бар блоктарды көшірмеуімізді қамтамасыз етеді. Жалғыз айырмашылығы, егер фильм режимінде біз нақты файлдарды жалған файлдармен ауыстырсақ, мұнда біз оларға ешқандай қол тигізбейміз және бәрін сол күйінде қалдырамыз. Әйтпесе, бұл сіздің ақшаңызды және уақытыңызды үнемдеуге тырысатын дәл сол сусыздандыру индексі.

Сұрақ туындайды - егер сіз UI-ге қарасаңыз, екі опцияны бір уақытта таңдау мүмкіндігі бар. Мұндай аралас режим қалай жұмыс істейді?

Келіңіздер, түсінеміз.

Бастауы стандартты: сақтық көшірме файлы жасалады және дереу көшіріледі. Оған өсім жасалады және де көшіріледі. Бұл файлдардың операциялық терезеден шығып кеткенін және жабық тізбек пайда болғанын түсінгенге дейін болады. Осы кезде біз сусыздандыру операциясын орындаймыз және бұл файлдарды жалған файлдармен ауыстырамыз. Әрине, біз түсіру ауқымына ештеңені қайта көшірмейміз.

Барлық осы қызықты логика интерфейстегі тек бір құсбелгіге жауап береді: Сақтық көшірмелерді жасалған бойда нысан сақтау орнына көшіріңіз.

Бұл Көшіру режимі бізге не үшін қажет?

Сұрақты былайша қайталаған дұрыс: оның көмегімен біз қандай қауіптерден қорғаймыз? Ол бізге қандай мәселені шешуге көмектеседі?

Жауап анық: әрине, бұл деректерді қалпына келтіру. Егер бізде нысан қоймасында жергілікті деректердің толық көшірмесі болса, өнімімізге не болғанына қарамастан, біз әрқашан шартты Amazon-да орналасқан файлдардан деректерді қалпына келтіре аламыз.

Сондықтан ең қарапайымнан күрделіге дейін ықтимал сценарийлерді қарастырайық.

Біздің басымызға түсуі мүмкін ең қарапайым бақытсыздық - сақтық көшірме тізбегіндегі файлдардың бірінің қол жетімсіздігі.

Ең өкініштісі, біздің SOBR репозиторийінің бір бөлігі бұзылды.

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

Енді әр жағдайды бөлек қарастырайық.

Бір (тіпті бірнеше) сақтық көшірме файлдарын жоғалтқанда, бізге тек репозиторийді қайта қарап шығу процесін бастау керек, ал жоғалған файл жалған файлмен ауыстырылады. Ал регидратация процесін қолдана отырып (бұл мақаланың басында талқыланды) пайдаланушы деректерді түсіру ауқымынан жергілікті жадқа жүктей алады.

Қазір жағдай күрделірек. Біздің SOBR өнімділік режимінде жұмыс істейтін екі экстенттен тұрады деп есептейік, бұл біздің .vbk және .vib олардың үстіне біркелкі емес қабатта таралғанын білдіреді. Уақыт өте келе экстенттердің бірі қолжетімсіз болып қалады және пайдаланушы деректерінің бір бөлігі дәл осы дәрежеде жатқан машинаны шұғыл түрде қалпына келтіруі керек.

Пайдаланушы қалпына келтіру шеберін іске қосады, қалпына келтіргісі келетін нүктені таңдайды және шебер жұмыс істеу кезінде жергілікті қалпына келтіру үшін қажетті деректердің барлығына ие емес екенін түсінеді, сондықтан сыйымдылықты түсіруден жүктеп алу керек. галерея. Сонымен бірге жергілікті жадта қалған блоктар бұлттан жүктелмейді. Қалпына келтіру индексіне даңқ (иә, бұл мақаланың басында да айтылды).

Бұл жағдайдың ішкі түрі - бүкіл SOBR репозиторийіне қол жетімсіз болып қалды. Бұл жағдайда бізде жергілікті жадтан көшіретін ештеңе жоқ және барлық блоктар бұлттан жүктеледі.

Ал ең қызық жағдай резервтік сервер өлді. Мұнда екі нұсқа бар: әкімші тамаша және конфигурацияның сақтық көшірмелерін жасады, ал әкімші зұлым Пиноккионың өзі және конфигурацияның сақтық көшірмесін жасамаған.

Бірінші жағдайда, оған VBR таза қондырғысын бір жерде орналастыру және стандартты құралдарды пайдаланып оның дерекқорын сақтық көшірмеден қалпына келтіру жеткілікті болады. Бұл процестің соңында бәрі қалыпты жағдайға оралады. Немесе ол жоғарыдағы сценарийлердің біріне сәйкес қалпына келтіріледі.

Бірақ егер әкімші өзінің жауы болса немесе конфигурацияның сақтық көшірмесі де эпикалық сәтсіздікке ұшыраса, онда біз оны тағдырдың рақымына қалдырмаймыз. Бұл жағдайда біз Import Object Storage деп аталатын жаңа процедураны енгіздік. Ол SOBR репозиторийін қолмен қайта жасау процесін өткізіп жіберуге және кейіннен қайта қарап шығу арқылы оған сыйымдылықты түсіру диапазонын қосуға және Vim интерфейсіне сақтау нысанын қосуға және Импорт сақтау репозиторийі процедурасын орындауға мүмкіндік береді. Сіз және сақтық көшірмелеріңіздің арасына кедергі болатын жалғыз нәрсе - сақтық көшірмелеріңіз шифрланған болса, құпия сөзді енгізу сұрауы.

Мұның бәрі Көшіру режимі туралы болуы мүмкін және біз оған көшеміз

Жабық режим

Негізгі идея жаңа сақтық көшірмелер репозиторийдің таңдалған SOBR ауқымында пайда болмайды. v10 нұсқасына дейін бізде репозиториймен жұмыс істеуге толық тыйым салынған кезде ғана техникалық қызмет көрсету режимі болған. Сақтық көшірмелерді бір реттік басқа көлемге тасымалдайтын «Эвакуация» түймесі ғана қол жетімді болатын жадты өшіруге арналған қатты режим.

Жабық режим - бұл «жұмсақ» опцияның бір түрі: біз жаңа сақтық көшірмелерді жасауға тыйым саламыз және таңдалған сақтауға сәйкес ескілерін біртіндеп жоямыз, бірақ бұл процесте біз сақталған нүктелерден қалпына келтіру мүмкіндігін жоғалтпаймыз. Өте пайдалы нәрсе, не бізде оның қызмет ету мерзімі аяқталуға жақын аппараттық құрал болса және оны ауыстыру қажет болса немесе біз оны маңыздырақ нәрсеге босатуымыз керек, бірақ оны алып, барлығын бірден жылжытатын жер жоқ. Немесе оны жою мүмкін емес.

Тиісінше, жұмыс принципі өте қарапайым: барлық жазу операцияларына (жаңа деректердің пайда болуына), оқуды қалдыруға (қалпына келтіру) және жоюға (сақтау) тыйым салу қажет.

Екі режимді де бір уақытта пайдалануға болады, бірақ Техникалық қызмет көрсетудің басымдылығы жоғары екенін есте сақтаңыз.

Мысал ретінде екі ауқымнан тұратын SOBR-ды қарастырайық. Алғашқы төрт күн ішінде біз Мәңгілік ұлғаймалы режимде сақтық көшірмелерді жасадық делік, содан кейін біз ауқымды бекітеміз.Бұл екінші қолжетімді көлемде жаңа белсенді толықты құруды бастауымызға әкеледі. Егер біздің сақтауымыз төрт болса, онда мөрленген деңгейде орналасқан бүкіл тізбек оның шегінен шығып кеткенде, ол таза ар-ұжданмен жойылады.

Жою ертерек болатын жағдайлар бар. Мысалы, бұл кезеңдік толық сандармен алға қадам. Егер біз алғашқы екі күнде толық сақтық көшірмелерді жасасақ және бейсенбіде репозиторийді жабуды шешсек, онда жұмада, жаңа сақтық көшірме жасалғанда, дүйсенбіге арналған файл жойылады, себебі бұл нүктеге тәуелділік жоқ. Ал нүктенің өзі ешкімге тәуелді емес. Содан кейін біз қол жетімді деңгейде төрт нүкте жасалғанша күтеміз және бір-бірінен тәуелсіз жою мүмкін емес қалған үшеуін жоямыз.

Reverse Incremental көмегімен істер оңайырақ. Онда ең ескі нүктелер ештеңеге байланысты емес және оларды қауіпсіз жоюға болады. Сондықтан жаңа .vbk жаңа көлемде жасалғанда, ескі .vrbs бірінен соң бірі жойылады.

Айтпақшы, неге біз әр уақытта жаңа .vbk жасаймыз: егер біз оны жасамай, ескі қадамдар тізбегін жалғастырсақ, онда ескі .vbk кез келген режимде шексіз ұзақ уақыт бойы қатып, оның жойылуын болдырмайды. Сондықтан, ауқым мөрлене салысымен, біз бос көлемде толық резервтік көшірмені жасаймыз деп шешілді.

Сыйымдылығы ату қашықтығымен бәрі күрделірек.

Алдымен көшіру режимін қарастырайық. Біз төрт күн бойы белсенді түрде резервтік көшірмелерді жасадық деп есептейік, содан кейін сыйымдылықты түсіру алаңы мөрленді. Біз ештеңені жоймаймыз, бірақ сақтауға кішіпейілділікпен шыдаймыз, содан кейін біз қуатты түсіру ауқымынан деректерді жоямыз.

Жылжыту режимінде шамамен бірдей нәрсе орын алады - біз өңдеуді күтеміз, жергілікті жадтағы ескісін жоямыз және нысан қоймасында сақталғанын жоямыз.

Forever forward инкременті бар қызықты мысал. Біз сақтауды үш нүктеге орнатамыз және дүйсенбіде бұлтқа үнемі көшірілетін сақтық көшірмелерді жасай бастаймыз. Жадты тығыздағаннан кейін үш нүктені сақтай отырып, сақтық көшірмелер жасау жалғаса береді, бірақ сыйымдылық жолағында сақталған деректер тәуелді болып қалады және оларды жою мүмкін емес. Сондықтан, біз .vbk сақтау мүмкіндігінен асып кеткен бейсенбіге дейін күтеміз, содан кейін ғана біз барлық сақталған тізбекті тыныштықпен жоямыз.

Және кішігірім жауапкершіліктен бас тарту: мұнда барлық мысалдар бір машинамен көрсетілген. Сақтық көшірмеде олардың бірнешеуі болса, олардың ретуштері Active Full жасалғанына немесе жасалмағанына байланысты әр түрлі болады.

Бұл, негізінен, бар нәрсе. Сонымен, ең қатал функцияға көшейік -

Өзгермейтіндігі

Алдыңғы тармақтардағыдай, біріншіден, бұл функция қандай мәселені шешеді. Сақтық көшірмелерді сақтау үшін бір жерге жүктеп салғаннан кейін, олардың қауіпсіздігіне кепілдік беруге, яғни оларды жоюға және берілген сақтау кезінде кез келген өзгертуге физикалық түрде тыйым салуға қатты ұмтылыс пайда болады. Әкімшілерді қоса алғанда, олардың түбірлік тіркелгілері астында. Бұл оларды кездейсоқ немесе қасақана зақымданудан қорғауға мүмкіндік береді. AWS-пен жұмыс істейтін кез келген адам Object Lock деп аталатын ұқсас мүмкіндікті кездестірген болуы мүмкін.

Енді жалпы түрде режимді қарастырайық, содан кейін егжей-тегжейлі қарастырайық. Біздің мысалда төрт күндік сақтау мүмкіндігімен түсіру ауқымы үшін Өзгермеушілік қосылады. Ал сақтық көшірмеде Көшіру режимі қосылған.

Өзгермеушілік жалпы ұстаумен ешбір түрде әрекеттеспейді. Мысалы, ол қосымша ұпайларды немесе сол сияқты ештеңені қоспайды. Тек адам төрт күн ішінде сақтық көшірме файлдарын жоя алмайды. Егер сіз дүйсенбі күні сақтық көшірме жасасаңыз, оның файлын жұмада ғана жоя аласыз.

Сусыздандыру, индекстер және метадеректер туралы бұрын түсіндірілген барлық тұжырымдамалар дәл солай жұмысын жалғастыруда. Бірақ бір шартпен - блок тек деректер үшін ғана емес, метадеректер үшін де орнатылады. Бұл айлакер шабуылдаушы біздің метадеректер дерекқорымызды өшіруді шешсе және деректер блоктарының пайдасыз екілік мушқа айналуына жол бермеу үшін жасалады.

Қазір блокты генерациялау технологиясын түсіндірудің тамаша уақыты. Немесе блок құру. Мұны істеу үшін оның пайда болуына әкелген жағдайды қарастырыңыз.

Алты күндік уақыт шкаласын алайық және одан төмен өзгермейтіндіктің күтілетін аяқталу уақытын белгілейміз. Бірінші күні біз a деректер блогынан және оның метадеректерінен тұратын файлды аламыз және жасаймыз. Егер өзгермейтіндік үш күнге орнатылса, төртінші күні деректер құлпы ашылады және жойылады деп ойлау қисынды. Екінші күні біз бірдей параметрлері бар b блогынан тұратын жаңа файл2 қосамыз. Блок a әлі төртінші күні жойылуы керек. Бірақ үшінші күні қорқынышты нәрсе орын алады - жаңа d блогынан және ескі а блогына сілтемеден тұратын File3 файлы жасалады. Бұл блок үшін және оның өзгермейтін жалаушасы алтыншы күнге ауыстырылатын жаңа күнге қалпына келтірілуі керек дегенді білдіреді. Міне, мәселе туындайды - нақты сақтық көшірмелерде мұндай блоктардың көп саны бар. Және олардың өзгермейтін мерзімін ұзарту үшін әр жолы көптеген сұраулар жасау керек. Шындығында, бұл күнделікті шексіз дерлік процесс болады, өйткені жоғары ықтималдықпен біз әр көшірмеден дедупликацияланған блоктардың үлкен дестелерін табамыз. Нысанды сақтау провайдерлерінен сұраныстардың көп саны нені білдіреді? Дұрыс! Айдың соңында үлкен есепшот.

Сіздің сүйікті клиенттеріңізді қомақты ақшаға әшкере етпеу үшін блок құру механизмі ойлап табылды. Бұл белгіленген өзгермейтін кезеңге қосатын қосымша кезең. Төмендегі мысалда бұл кезең екі күн. Бірақ бұл мысал ғана. Шындығында, олар ай сайынғы құлыптау кезінде шамамен он қосымша күн беретін өздерінің формуласын пайдаланады.

Бірдей жағдайды қарастыруды жалғастырайық, бірақ блок генерациясымен. Бірінші күні біз a блогынан және метадеректерден file1 жасаймыз. Біз генерация кезеңі мен өзгермейтінді қосамыз - бұл файлды жою мүмкіндігі алтыншы күні болатынын білдіреді. Егер екінші күні біз b блогынан және a блогына сілтемеден тұратын File2 жасасақ, күтілетін жою күніне ештеңе болмайды. Ол алтыншы күндегідей тұрды. Осылайша, біз сұраныстар санын үнемдеуге тырысамыз. Мерзімді ауыстыруға болатын жалғыз жағдай, егер генерациялау мерзімі өтіп кетсе. Яғни, үшінші күні жаңа File3-де a блоктау сілтемесі болса, Gen2 мерзімі әлдеқашан біткендіктен 1-буын қосылады. Ал блокты жоюдың күтілетін күні сегізінші күнге ауысады. Бұл бізге дедупликацияланған блоктардың қызмет ету мерзімін ұзарту туралы сұраулардың санын күрт азайтуға мүмкіндік береді, бұл клиенттерге бір тонна ақшаны үнемдейді.

Технологияның өзі S3 және S3-үйлесімді жабдықты пайдаланушылар үшін қол жетімді, олардың өндірушілері олардың орындалуы Amazon-дан ерекшеленбейтініне кепілдік береді. Демек, Azure неге қолдау көрсетпейді деген заңды сұраққа жауап - олардың ұқсас мүмкіндігі бар, бірақ ол жеке нысандар емес, контейнерлер деңгейінде жұмыс істейді. Айтпақшы, Amazon-да екі режимде нысанды құлыптау бар: сәйкестік және басқару. Екінші жағдайда, әкімшілер мен түбірлердің үстіндегі ең үлкен әкімші нысанның құлыпталуына қарамастан, әлі де деректерді жояды. Сәйкестік жағдайында бәрі мықтап бекітілген және резервтік көшірмелерді ешкім жоя алмайды. Тіпті Amazon әкімшілері (ресми мәлімдемелері бойынша). Бұл біз қолдайтын режим.

Және, әдеттегідей, кейбір пайдалы сілтемелер:

• туралы Блок құру әрбір бөлшекте.
• туралы барлық ақпарат Veeam Backup & Replication 10 ең жақсы жағдайда
• О Сыйымдылық деңгейі егжей-тегжейлі

Ақпарат көзі: www.habr.com