{"id":84809,"date":"2020-06-11T01:42:41","date_gmt":"2020-06-10T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10"},"modified":"2020-06-11T01:42:41","modified_gmt":"2020-06-10T23:42:41","slug":"chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Capacity Tier (v\u00f5i nagu me oma vahel nimetame \u2014 kaptir) tuli algselt v\u00e4lja Veeam Backup and Replication 9.5 Update 4 all nimega Archive Tier. Selle idee oli v\u00f5imaldada liigutada varukoopiaid, mis on v\u00e4ljaspool nii nimetatud operational restore window, objektihoidlasse. See aitas kasutada diskiruumi kasutajatele, kellel seda v\u00e4he oli. Seda valikut nimetati Move Mode.<\/p>\n<p>Selle lihtsa (nagu v\u00f5ib tunduda) tegevuse teostamiseks tuli t\u00e4ita kaks tingimust: k\u00f5ik punktid liigutatavast varukoopiast peavad olema v\u00e4ljaspool \u00fclalmainitud operational restore window, mis on kasutajaliideses selgelt m\u00e4\u00e4ratletud. Teiseks peab ahel olema nii nimetatud \u00absuleeritud\u00bb (sealed backup chain v\u00f5i Inactive Backup Chain). See t\u00e4hendab, et aja jooksul ei toimu selle ahela muutusi.<\/p>\n<p>Kuid VBR v10-s t\u00e4ienes kontseptsioon uute funktsioonidega \u2014 lisandusid Copy Mode, Sealed Mode ja keeruliselt h\u00e4\u00e4ldatav termi Immutability.<\/p>\n<p>T\u00e4na r\u00e4\u00e4gime neist p\u00f5nevates asjadest. Esiteks, kuidas see t\u00f6\u00f6tas VBR9.5u4-s, ja seej\u00e4rel muudatustest k\u00fcmnendas versioonis.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa palun vabandust puhta keele kaitsjate ees, aga liiga palju termineid ei ole v\u00f5imalik t\u00f5lkida.<br \/>\nNii et siia tuleb palju anglicisme.<br \/>\nJa palju giffe. <br \/>\nJa pilte.<\/p>\n<ul>\n<li>Ilma v\u00e4himagi kahetsuseta. Artikli autor.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Kuidas oli<\/h1>\n<p>\nNii et alustame operational restore window'i ja sealed backup'i (v\u00f5i kuidas neid dokumentatsioonis nimetatakse Inactive Backup Chain). Ilma nende m\u00f5istmiseta ei saa edasi seletada.<\/p>\n<p>Nagu n\u00e4eme pildilt, on meil olemas teatud backup-ahel koos andmepakettidega, mis asub Performance tier SOBR-repositooriumis, millega on \u00fchendatud Capacity Tier. Meie operatiivse backup'i aken on kolm p\u00e4eva.<\/p>\n<p>Seega esmasp\u00e4eval loodud .vbk pitseerib eelneva ahela, mille aken on seatud kolme p\u00e4eva peale. Ja seega v\u00f5ib rahulikult alustada vanemate kolme p\u00e4eva varade saatmist kapasitatiirimisse.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAga mida t\u00e4pselt m\u00f5eldi pitseeritud ahela all ja mis v\u00f5idi saata kapasitatiirimisse update 4-s?<\/p>\n<p>Forward Incremental'i puhul on uut t\u00e4iskohustuslikku (full) backup'i loomine ahela pitseerimise tunnuseks. Pole t\u00e4htis, kuidas see t\u00e4iskohustuslik (full) saavutatakse: arvestatakse nii synthetic full kui ka active full backups.<\/p>\n<p>Reverse'i puhul on k\u00f5ik failid, mis ei mahu operatiivse aknasse. <\/p>\n<p>Forward increment'i puhul koos rullimisega on need k\u00f5ik rullimised ja .vbk, kui j\u00f5udluslauses on veel \u00fcks .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nR\u00e4\u00e4gime n\u00fc\u00fcd Backup Copy ahelate t\u00f6\u00f6variandist. Siin viidi \u00e4ra ainult see, mis kuulus GFS hoidmise alla. Sest k\u00f5ik, mis on uuemas backup copy ahelas, v\u00f5ib mingil viisil olla muudetud.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUurime n\u00fc\u00fcd, mis toimub seadme all. Seal toimub protsess, mida nimetatakse deh\u00fcdratsiooniks \u2014 varukoopiafailide t\u00fchikute j\u00e4tmine lausesse ja plokkide t\u00f5stmine nendest failidest kapatsitiirisse. Selle protsessi optimeerimiseks kasutatakse nn deh\u00fcdratsioonin\u00e4idikut, mis ei v\u00f5imalda juba kapatsitiirisse kopeeritud blokke uuesti kopeerida. <\/p>\n<p>Vaata, kuidas see v\u00e4lja n\u00e4eb n\u00e4ite kaudu: oletame, et meil on .vbk, mis on tulnud operatiivaknast ja kuulub suletud ahelasse. See t\u00e4hendab, et meil on t\u00e4ielik \u00f5igus see liigutada kapasitatihti. Liikumise hetkel luuakse kapasitatihti metadatafail ja liigutatava faili plokid. Metadatafaili linkide tasemel on kirjeldatud, millistest plokkidest meie fail koosneb. Pildil olevas n\u00e4ites koosneb meie esimene fail plokkidest a, b, c ja metadatades on lingid nende plokkide juurde. Kui meil on teine .vbk fail, mis on liikumiseks valmis ja koosneb plokkidest a, b ja d, saame deh\u00fcdratsiooni indeksi anal\u00fc\u00fcsimisel aru, et peame liigutama vaid ploki d. Selle metadatafail sisaldab linke kahe eelmise bloki ja \u00fche uue juurde.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeega, nende t\u00fc\u00fcpide andmetega t\u00e4itmise protsessi nimetatakse rehidreerimiseks. Siin kasutatakse juba olemasolevat rehidreerimise indeksit, mis p\u00f5hineb k\u00f5ige vanemal .vbk failil kohaliku j\u00f5udluse ulatuses. See t\u00e4hendab, et kui kasutaja soovib faili taastada kapassiivsetest saadetistest, loome esmalt k\u00f5ige vanema t\u00e4isvarukoopia plokkide indeksi ja kanname kapassiivse saadetise saadud puuduvad plokid. N\u00e4idatud juhul on meil vaja regidreerida FullBackup1.vbk vastavalt rehidreerimise indeksile, mist\u00f5ttu on meil puudu ainult plokk C, mille kannamegi kapassiivsetest saadetistest. Kui kapassiivne saade on pilve objektide salvestus, v\u00f5imaldab see s\u00e4\u00e4sta tohutult raha.<\/p>\n<p>Siin v\u00f5ib tunduda, et see tehnoloogia on sama, mis WAN-kiirendites, kuid see on vaid n\u00e4ilisus. Kiirendites toimub deduplication globaalne tasand, siin kasutatakse aga kohalikke tulemusi iga faili jaoks teatud offset'i ulatuses. See tuleneb lahendatavast probleemist: peame kopeerima suuri faile t\u00e4ielikest varukoopiatest, ja meie uuringute kohaselt, isegi kui nende vahel on suur ajavahemik, annab selline deduplication algoritm parema tulemuse.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAga rohkem indeksit, rohkem indeksit! On olemas ka indeks andmete taastamiseks! Kui me k\u00e4ivitame masina taastamise, mis asub kapasiti aknas, siis loeme ainult unikaalseid andmeplokke, mida ei ole tulemuslikkuse aknas.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Nii on saanud<\/h1>\n<p>\nSissejuhatusega on k\u00f5ik. See on \u00fcsna p\u00f5hjalik, kuid nagu varem \u00f6eldud, ei saa ilma nende detailideta selgitada, kuidas uued funktsioonid toimivad. Seega, ilma liialdava eess\u00f5nna, liigume edasi esimesele.<\/p>\n<h3>Kopeerimisre\u017eiim<\/h3>\n<p>\nJ\u00e4rjest enam p\u00f5hineb see olemasolevatel tehnoloogiatel, kuid sisaldab t\u00e4iesti teistsugust kasutusloogikat.\u00a0<\/p>\n<p>Selle re\u017eiimi eesm\u00e4rk on tagada, et k\u00f5ik lokaalsetel ulatustel asuvad andmed omavad koopiat kapasitiviirus.<\/p>\n<p>Kui v\u00f5rrelda otseselt Move ja Copy re\u017eiime, saab tulemuseks j\u00e4rgmise:<\/p>\n<ul>\n<li>Liigutada saab ainult pitsatatud ahelat. Koopi re\u017eiimi puhul viiakse \u00e4ra absoluutne k\u00f5ik, s\u00f5ltumata sellest, mis varundust\u00f6\u00f6s toimub.<\/li>\n<li>Liikumine toimub, kui failid \u00fcletavad operatiivse varunduse akna piire, kuid kopeerimine toimub kohe, kui varundusfail ilmub.<\/li>\n<li>Uute andmete j\u00e4lgimine kopeerimiseks toimub pidevalt, samas kui liikumine toimus iga 4 tunni tagant.<\/li>\n<\/ul>\n<p>\nUue re\u017eiimi arutlemisel soovitan liikuda lihtsatest n\u00e4idetest keerukamate suunas.<\/p>\n<p>K\u00f5ige elementalmas olukorras ilmuvad meil lihtsalt uued failid koos inkrementidega, ja me kopeerime need lihtsalt kapasitiviirusse. S\u00f5ltumata sellest, millist re\u017eiimi kasutatakse varundust\u00f6\u00f6s, kas see kuulub pitsatatud osa ahelasse v\u00f5i mitte, ning olgu meie operatiivne aken m\u00f6\u00f6dunud v\u00f5i mitte. Lihtsalt v\u00f5tame ja kopeerime.<\/p>\n<p>Protsess, mille taga on deh\u00fcdraatsioon, on endiselt sama, nagu juba eespool mainitud. Kopeerimisre\u017eiimis j\u00e4lgib see ka, et me ei kopeeriks plokke, mis juba meie salvestuses on. Ainsaks erinevuseks on see, et kui liikumisre\u017eiimis asendasime reaalsed failid t\u00fchjade failidega, siis siin me neid kuidagi ei puutu ja j\u00e4tame k\u00f5ik nii, nagu on. \u00dclej\u00e4\u00e4nud osa on t\u00e4pselt sama deh\u00fcdreerimise indeks, mis hoolikalt p\u00fc\u00fcab s\u00e4\u00e4sta teie raha ja aega.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nT\u00f5useb k\u00fcsimus \u2014 kui vaadata UI-d, siis seal on v\u00f5imalus valida m\u00f5lemad valikud samal ajal. Kuidas selline kombineeritud re\u017eiim t\u00f6\u00f6tab?<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHakkame kohe asja selgitama.<\/p>\n<p>Algus on standardne: luuakse varukoopia fail, ja see kopeeritakse kohe. Temaga luuakse inkrement ja see kopeeritakse samuti. Nii toimub kuni hetkeni, mil m\u00f5istame, et failid on meie operatiivaknast v\u00e4ljaulatuvad ja on tekkinud pitseeritud ahel. Sel hetkel viime l\u00e4bi deh\u00fcdreerimise operatsiooni ja asendame need failid t\u00fchjadega. Loomulikult ei kopeeri me uuesti kapatsi tirile midagi.<\/p>\n<p>Kogu selle p\u00f5neva loogika eest vastutab vaid \u00fcks linnuke liideses: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Miks meil on see Copy re\u017eiim? <\/h3>\n<p>\nIsegi parem oleks k\u00fcsimust \u00fcmber s\u00f5nastada \u2014 milliste riskide eest me end selle abil kaitseme? Millist probleemi see aitab lahendada?<\/p>\n<p>Vastus on ilmne: loomulikult on see andmete taastamine. Kui meie objektide salvestuses on t\u00e4ielik koopia lokaalsetest andmetest, siis pole t\u00e4htis, mis meie tootmises juhtub, me saame alati taastada andmed failidest, mis asuvad tinglikus Amazoni s\u00fcsteemis.<\/p>\n<p>Seega, vaatame v\u00f5imalikke stsenaariume lihtsaimast keerulisemani.<\/p>\n<p>Lihtsaim h\u00e4da, mis meie peale v\u00f5ib langeda, on \u00fcksikute failide k\u00e4ttesaamatuse probleem varukopeerimise ahelas.<\/p>\n<p>Karmim lugu on see, et meie SOBR repositooriumi \u00fcks ulatus on katki.<\/p>\n<p>Veel hullem on see, kui kogu SOBR repositoorium muutub k\u00e4ttesaamatuks, kuid kapasitatiivne tiir t\u00f6\u00f6tab.<br \/>\nJa t\u00e4iesti halb on see, kui varukoopiaseerver sureb ja sinu esimene soov on \u00fcritada k\u00fcmne minutiga Kanada piirini joosta.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd vaatame iga olukorda eraldi.<\/p>\n<p>Kui oleme kaotanud \u00fche (ja isegi mitu) varukoopiafaili, siis piisab, kui k\u00e4ivitame reposi reskanimise protsessi, ja kadunud fail asendatakse t\u00fchjaga. Protsessi regidreerimise abil (millest r\u00e4\u00e4giti artikli alguses) saab kasutaja andmed alla laadida kapasitatiivses tiirus kohalikku salvestusse.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd on olukord keerulisem. Kujutame ette, et meie SOBR koosneb kahest ekstensioonist, mis t\u00f6\u00f6tavad j\u00f5udlusre\u017eiimis, mist\u00f5ttu on meie .vbk ja .vib neile eba\u00fchtlaselt jaotatud kihina. Ja mingil hetkel muutub \u00fcks ekstensioon k\u00e4ttesaamatuks ning kasutaja peab kiiresti taastama masina, mille osa andmetest on just sellel ekstensioonil. <\/p>\n<p>Kasutaja k\u00e4ivitab taastamisv\u00f5luri, valib punkti, kuhu soovib taastada, kuid v\u00f5lur j\u00f5uab oma t\u00f6\u00f6 k\u00e4igus arusaamisele, et tal puuduvad k\u00f5ik vajalikud taastamise andmed lokaalsetes salvestustes ning need tuleb alla laadida kapasitatiivsetest tiirudest. Sellega j\u00e4\u00e4vad kohalikku salvestusse j\u00e4\u00e4nud blokid pilvest alla laadimata. T\u00e4nu taastamisindeksile (jah, sellestki r\u00e4\u00e4giti artikli alguses).<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSelle juhtumi alaliik \u2014 kogu SOBR hoidla on muutunud k\u00e4ttesaamatuks. Sel juhul ei ole meil midagi kohalikest ladustustest kopeerida, ja k\u00f5ik plokid laaditakse pilvest alla.<\/p>\n<p>Ja k\u00f5ige huvitavam olukord \u2014 varundusserver on surnud. Siin on kaks varianti: adminn on tubli ja tegi konfiguratsioonivarundusi, v\u00f5i adminn on ise endale kuri Buratino ja ei teinud konfiguratsioonivarundust.<\/p>\n<p>Esimesel juhul piisab, kui kuskil k\u00e4ivitada puhas VBR paigaldus ja taastada oma andmebaas varundusest tavap\u00e4raste vahenditega. Selle protsessi l\u00f5petamisel naaseb k\u00f5ik oma algseisundisse. V\u00f5i taastatakse see m\u00f5ne \u00fclalmainitud stsenaariumi p\u00f5hjal.<\/p>\n<p>Kuid kui administraator on endale vaenlane v\u00f5i varukoopia konfigureerimisega on juhtunud m\u00fctoloogiline eba\u00f5nn, siis me ei j\u00e4ta teda ka sellisel juhul oma saatuse hooleks. Selle jaoks oleme rakendanud uue protseduuri, mida nimetatakse Import Object Storage. See v\u00f5imaldab vahele j\u00e4tta k\u00e4sitsi SOBR-repositooriumi taastamisprotsessi ja selle liitmise kapasitatiivse tiiruga, ning lihtsalt lisada objektide salvestus liidese kaudu ja k\u00e4ivitada Import Storage Repository protsess. Ainus asi, mis v\u00f5ib teie ja teie varukoopiate vahel seista, on palve sisestada parool, kui teie varukoopiad on kr\u00fcpteeritud.<\/p>\n<p>Copy Mode'ist on selleks korraks k\u00f5ik ja liigume edasi<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nP\u00f5hiasi on see, et valitud SOBR-repositooriumi ulatuses ei saa ilmuda uusi varukoopiaid. Enne v10 oli meil ainult Maintenance Mode, kus oli t\u00e4ielikult keelatud igasugune t\u00f6\u00f6 repositooriumiga. Selline karm re\u017eiim salvestusruumi t\u00f6\u00f6lt v\u00e4lja viimiseks, kus on saadaval ainult Evacuate nupp, mis \u00fche korra viib varukoopiad teise ulatusse.<\/p>\n<p>Sealed mode on sarnaste seisundite puhul t\u00e4hendab, et me keelame uute varukoopiate loomise ja j\u00e4rk-j\u00e4rgult kustutame vanad vastavalt valitud retentsioonile, kuid protsessi k\u00e4igus s\u00e4ilitame v\u00f5imaluse taastuda salvestatud punktidest. See on v\u00e4ga kasulik, kui meie seadme eluiga on l\u00f5ppemas ja seda tuleb asendada, v\u00f5i kui seda tuleb lihtsalt vabastada millegi olulisema jaoks, kuid ei ole kohta, kuhu k\u00f5ike \u00fchekorraga \u00fcle kanda. V\u00f5i ei ole v\u00f5imalik kustutada. <\/p>\n<p>Seega on t\u00f6\u00f6p\u00f5him\u00f5te \u00fcsna lihtne: tuleb keelata k\u00f5ik write operatsioonid (uute andmete ilmumine), j\u00e4ttes alles ainult read (taastamised) ja delete (retentsioon).<\/p>\n<p>Kumbagi re\u017eiimi saab kasutada samaaegselt, kuid peab arvestama, et Maintenance'i prioriteet on k\u00f5rgem.<\/p>\n<p>N\u00e4iteks v\u00f5tame SOBR, mis koosneb kahest ekstreemist. Oletame, et esimesed neli p\u00e4eva loodi varukoopiad edasiarendatud Forever Incremental re\u017eiimis ja seej\u00e4rel tihendame ekstree. See toob kaasa uue aktiivse t\u00e4iskoopia loomise teisel saadaval ekstree. Kui meie retentsioon on neli, siis kui kogu ahel, mis asub tihendatud ekstrees, \u00fcletab tema piire, kustutatakse see rahuliku s\u00fcdametunnistusega.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOn olemas olukordi, kus kustutamine toimub varem. N\u00e4iteks on see Forward incremental koos perioodiliste t\u00e4isvarukoopiate tegemisega. Kui esimesel kahel p\u00e4eval teeme t\u00e4isvarukoopiaid ja neljap\u00e4eval otsustame repositooriumi suletult, siis reedel, kui luuakse uus t\u00e4isvarukoopia, eemaldatakse fail esmasp\u00e4evast, sest sellel hetkel pole s\u00f5ltuvusi. Ja see hetk ei s\u00f5ltu kellestki. P\u00e4rast seda ootame, kuni luuakse neli punkti k\u00e4ttesaadaval ulatusel, ja kustutame kolm muud, mida ei saa \u00fcksteisest s\u00f5ltumatult kustutada.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nReverse Incremental on olukordades lihtsam. Seal ei s\u00f5ltu vanimad punktid kellestki ja neid saab rahulikult kustutada. Seet\u00f5ttu, kui uus .vbk luuakse uuel ulatusel, siis vanad .vrb eemaldatakse \u00fcksikult.<\/p>\n<p>Muide, miks me iga kord loome uue .vbk: kui seda ei looda ja j\u00e4tkatakse vana inkremendi ahelat, hakkaks vana .vbk igavesti j\u00e4\u00e4ma igasse re\u017eiimi, takistades selle kustutamist. Seet\u00f5ttu otsustati, et niipea kui ulatus suletakse, loome t\u00e4isvarukoopia vabale ulatusele.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nKapassitiiruga on asjad keerulisemad. <\/p>\n<p>Alustame koopia re\u017eiimist. Oletame, et meil on neli p\u00e4eva aktiivselt varukoopiate loomisega ja seej\u00e4rel on kapatsiti tir suletud. Me ei kustuta midagi, vaid kannatame hoidmise ajast \u00e4ra ning seej\u00e4rel kustutame andmed kapatsiti tirist.<\/p>\n<p>Sarnane protsess toimub ka liikuva re\u017eiimi korral \u2014 ootame hoidmise aega, kustutame vanad andmed kohalikust salvestusest ja kustutame objektisalvestuses hoitavad andmed.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHuvitav n\u00e4ide Forever forward incremental'ist. Seame hoidmise ajaks kolm punkti ja alates esmasp\u00e4evast teeme varukoopiaid, mis korrektselt kopeeritakse pilve. P\u00e4rast salvestusse suletust j\u00e4tkatakse varukoopiate loomist, s\u00e4ilitades kolm punkti, kuid kapatsiti tiris hoitavad andmed j\u00e4\u00e4vad s\u00f5ltuvaks ja ei saa kustutada. Seet\u00f5ttu ootame neljap\u00e4eva, mil meie .vbk \u00fcletab hoidmise aja, ja alles siis kustutame rahulikult kogu salvestatud ahela.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa v\u00e4ike m\u00e4rk: k\u00f5ik n\u00e4ited on siin n\u00e4idatud \u00fche masinaga. Kui teil on varukoopias mitu masinat, siis nende hoidmine s\u00f5ltub sellest, kas on tehtud Active Full v\u00f5i mitte.<\/p>\n<p>Sellega on p\u00f5him\u00f5tteliselt k\u00f5ik. Nii et liigume edasi k\u00f5ige karmima funktsiooni juurde \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nNagu ka varasemate punktide puhul, alustan sellest, millist probleemi see funktsioon lahendab. Kui me laadime oma varukoopiaid kuhugi salvestamiseks, tekib tungiv vajadus tagada nende turvalisus, see t\u00e4hendab f\u00fc\u00fcsiliselt keelata nende kustutamine ja igasugune muutmine m\u00e4\u00e4ratud s\u00e4ilitamisperioodi jooksul. Sealhulgas administratorite poolt, sealhulgas nende juurkontode kaudu. See kaitseb varukoopiaid juhusliku v\u00f5i tahtliku h\u00e4vitamise eest. Kes t\u00f6\u00f6tab AWS-iga, on v\u00f5inud kokku puutuda sellise funktsiooniga nimega Object Lock.<\/p>\n<p>Vaatame n\u00fc\u00fcd re\u017eiimi \u00fcldiselt, seej\u00e4rel s\u00fcveneme \u00fcksikasjadesse. Meie n\u00e4ites on immutamine aktiveeritud meie mahutuse t\u00fc\u00fcbile s\u00e4ilitamise ajaga neli p\u00e4eva. Ja varukoopas on aktiveeritud kopeerimisre\u017eiim.<\/p>\n<p>Immutamine ei suhtle \u00fcldise s\u00e4ilitamisega. N\u00e4iteks ei lisa see lisapunkte ega midagi sarnast. Lihtsalt nelja p\u00e4eva jooksul ei saa inimene kustutada varukoopia faile. Kui esmasp\u00e4eval tehakse varukoopia, siis on failide kustutamine v\u00f5imalik alles reedel.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00f5ik eelnevalt selgitatud deh\u00fcdratsiooni, indeksite ja metaandmete kontseptsioonid toimivad t\u00e4pselt samamoodi. Kuid on \u00fcks tingimus \u2014 blokk kehtib mitte ainult andmete, vaid ka metaandmete jaoks. See on v\u00e4lja t\u00f6\u00f6tatud selleks, et kaitsta meie metaandmete baasi v\u00f5imalike r\u00fcnnakute eest ja et andmeplokid ei muutuks kasutuks binaarseks pudruks.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd on suurep\u00e4rane hetk meie plokkide genereerimise tehnoloogia selgitamiseks. Vaatame olukorda, mis viis selle tekkimiseni.<\/p>\n<p>V\u00f5tame kuue p\u00e4eva ajaskaala ja m\u00e4rgime allapoole oodatava immutability l\u00f5ppemise aja. Loome esimesel p\u00e4eval faili, mis koosneb plokist a ja selle metadatatest. Kui immutability on seadistatud kolme p\u00e4eva peale, on loogiline eeldada, et neljandal p\u00e4eval andmed vabastatakse ja kustutatakse. Teisel p\u00e4eval lisame uue file2, mis koosneb plokist b samade seadistustega. Plokk a tuleb endiselt kustutada neljandal p\u00e4eval. Kuid kolmandal p\u00e4eval juhtub \u00f5udus \u2014 luuakse fail File3, mis koosneb uuest plokist d ja viidatud vanale plokile a. See t\u00e4hendab, et ploki a immutability lipp peab olema m\u00e4\u00e4ratud uue t\u00e4htajaga, mis l\u00fckatakse kuuele p\u00e4evale. Ja siin tekib probleem \u2014 reaalses varukoopias tekib selliseid plokke tohutult palju. Ja et pikendada nende immutability perioodi, tuleb iga kord teha tohutult palju p\u00e4ringuid. Ja tegelikult on see peaaegu l\u00f5pmatu igap\u00e4evane protsess, kuna suure t\u00f5en\u00e4osusega leiame iga kopeerimise k\u00e4igus suuri pakke dedupeeritud plokke. Mis see t\u00e4hendab, kui palju p\u00e4ringuid objekti salvestuspakkujatelt? \u00d5ige! Suur arve kuu l\u00f5pus.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa et mitte n\u00e4idata oma v\u00e4\u00e4rtuslike kliente rahaliselt ebamugavatesse olukordadesse, t\u00f6\u00f6tati v\u00e4lja block generation mehhanism. See on lisaperiood, mille lisame v\u00e4lja pakutud immutability perioodile. Allj\u00e4rgnevas n\u00e4ites on see periood kaks p\u00e4eva. Kuid see on ainult n\u00e4ide. Tegelikult kasutatakse seal oma valemit, mis annab umbes k\u00fcmme t\u00e4iendavat p\u00e4eva kuu lukustamise ajal. <\/p>\n<p>J\u00e4tkame sama olukorra vaatamist, kuid n\u00fc\u00fcd block generation'iga. Loome esimesel p\u00e4eval file1 blokist a ja metandmetest. Kogume kokku genereerimise perioodi ja immutability \u2014 see t\u00e4hendab, et faili kustutamine on v\u00f5imalik alles kuuendal p\u00e4eval. Kui teisel p\u00e4eval loome File2, mis koosneb blokist b ja lingist bloki a juurde, siis eeldatav kustutamise kuup\u00e4ev ei muutu. See j\u00e4\u00e4b kuuendaks p\u00e4evaks, nagu enne. Sellega p\u00fc\u00fcame v\u00e4hendada p\u00e4ringute arvu. Ainus olukord, kus t\u00e4htaeg v\u00f5ib nihkuda, on see, kui genereerimise periood on l\u00f5ppenud. See t\u00e4hendab, et kui kolmandal p\u00e4eval uus File3 sisaldab linki bloki a juurde, lisatakse generation 2, kuna Gen1 on juba l\u00f5ppenud. Ja eeldatav bloki a kustutamise kuup\u00e4ev nihkub kaheksandaks p\u00e4evaks. See v\u00f5imaldab meil dramaatiliselt v\u00e4hendada p\u00e4ringute arvu deduplication'i poolt seotud plokkide eluaja pikendamiseks, mis s\u00e4\u00e4stab klientidele palju raha.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam muutus v10-ks\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTehnoloogia on k\u00e4ttesaadav S3 ja S3-\u00fchilduva riistvara kasutajatele, mille tootjad garanteerivad, et nende rakendus ei erine Amazoni omast. Seega on \u00f5igustatud k\u00fcsimus, miks Azure't ei toetata \u2014 neil on sarnane funktsioon, kuid see t\u00f6\u00f6tab konteinerite tasemel, mitte eraldi objektide tasemel. Muide, Amazoni enda objektide lokaalne s\u00e4ilitamine on saadaval kahes re\u017eiimis: compliance ja governance. Teises re\u017eiimis j\u00e4\u00e4b v\u00f5imalus, et k\u00f5ige suurem admin, kes on adminide \u00fcle, ja root, kes on rootide \u00fcle, vaatamata objekti lokaalsele s\u00e4ilitamisele, ikkagi kustutab andmeid. Compliance re\u017eiimi puhul on k\u00f5ik haamerdatud igaveseks ning varukoopiad ei ole kellelgi kustutatavad. Isegi Amazoni administraatoritel (nagu nad oma ametlikes avaldustes kinnitavad). Me toetame just seda re\u017eiimi.<\/p>\n<p>\nJa, traditsiooniliselt, m\u00f5ned kasulikud lingid:<\/p>\n<ul>\n<li>Umbes <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Block Generation<\/a><\/noindex> k\u00f5ikides detailides.<\/li>\n<li>K\u00f5ik teave <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> parimais variatsioonides<\/li>\n<li>Umbes <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> detailides<\/li>\n<\/ul>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Mida on Capacity Tier'is muutunud, kui Veeam muutus v10 | ProHoster","description":"Capacity Tier (v\u00f5i kuidas me seda enda seas nimetame \u2014 kaptir) sai alguse Veeam Backup and Replication 9.5 Update 4 ajal nimega Archive Tier. Selle idee oli v\u00f5imaldada varukoopiate liigutamist, mis on v\u00e4lja j\u00e4\u00e4nud nii-\u00f6elda operational restore window'ist, objektihoidlatesse. See aitas vabastada kettaruumi, mis","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster","og:description":"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-10T23:42:41+00:00","article:modified_time":"2020-06-10T23:42:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84809","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:49:54","updated":"2022-09-29 08:38:47"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}