{"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 sai v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Capacity Tier (v\u00f5i nagu me seda oma sees nimetame \u2014 kaptir) ilmus juba Veeam Backup and Replication 9.5 Update 4 ajal nimega Archive Tier. Selle idee on anda v\u00f5imalus liikuda varukoopiatele, mis on j\u00e4\u00e4nud v\u00e4lja nii nimetatud operatiivse taastamise aknast, objektivaramudesse. See aitas vabastada kettaruumi kasutajatele, kellel seda oli v\u00e4he. Ning seda valikut nimetatakse Move Mode.<\/p>\n<p>Selle lihtsa (kui nii saab \u00f6elda) tegevuse teostamiseks tuli j\u00e4rgida kahte tingimust: k\u00f5ik punktid liigutatavast varukoopiast peavad j\u00e4\u00e4ma v\u00e4lja nimetatud operatiivse taastamise aknast, mis on m\u00e4\u00e4ratud selgelt kasutajaliideses. Ja teine: ahel peab olema nii nimetatud 'pitseeritud kujul' (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 kontseptsioon on rikastunud uute funktsioonidega \u2014 ilmus Copy Mode, Sealed Mode ja keeruliselt h\u00e4\u00e4ldatav omadus Immutability.<\/p>\n<p>Just nendest p\u00f5nevustest me t\u00e4na r\u00e4\u00e4gime. Esiteks, kuidas see t\u00f6\u00f6tas VBR9.5u4-s, ja siis k\u00fcmnenda versiooni muudatustest.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa olgu mind andestatud puhta keele toetajate poolt, kuid liiga palju termineid ei ole v\u00f5imalik t\u00f5lkida.<br \/>\nNii et siin on palju anglicisme.<br \/>\nJa palju gif'e. <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>\nNoh, alustame operatiivse taastamise akna ja pitsitatud varukoopia (v\u00f5i kuidas neid dokumentatsioonis nimetatakse Inactive Backup Chain) anal\u00fc\u00fcsiga. Ilma nende m\u00f5istmiseta ei saa edasist selgitada.<\/p>\n<p>Nagu n\u00e4eme pildilt, on meil mingi varukoopia ahel andmeplokkidega, mis asub Performance tier SOBR hoidlas, millele on \u00fchendatud Capacity Tier. Meie operatiivse varukoopia akna pikkus on kolm p\u00e4eva.<\/p>\n<p>Seega, esmasp\u00e4eval loodud .vbk pitsitab eelneva ahela, mille aken on m\u00e4\u00e4ratud kolmeks p\u00e4evaks. Ja seega v\u00f5ib rahulikult alustada k\u00f5ike, mis on vanem kui need kolm p\u00e4eva, \u00fcleviimist kapasitati tier'i.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAga mida t\u00e4pselt m\u00f5eldi pitsitatud ahela all ja mis v\u00f5is Update 4-s Capacity Tier'i minna?<\/p>\n<p>Eesmine Incremental puhul on pitsitamise m\u00e4rgiks uue t\u00e4is varukoopia loomine. Ja ei ole oluline, kuidas see t\u00e4is varukoopia saadakse: loetakse nii s\u00fcnteetilised t\u00e4is- kui ka aktiivsed t\u00e4is varukoopiad.<\/p>\n<p>Tagurpidi on k\u00f5ik failid, mis j\u00e4\u00e4vad v\u00e4lja operatiivse akna. <\/p>\n<p>Forward increment'i puhul koos rullimistamiseks, on k\u00f5ik rullimist piirid ja .vbk, kui perforeerimise ulatuses on veel \u00fcks .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd vaatame varukoopia ahelate t\u00f6\u00f6varianti. Siin viidi \u00e4ra ainult GFS hoidmise alla kuuluv. Sest k\u00f5ik, mis on uuemates backup copy ahelates, v\u00f5ib olla mingil viisil muudetud.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd vaatame, mis toimub kapoti all. Seal toimub protsess, mida nimetatakse deh\u00fcpraatideks \u2014 t\u00fchjade varufailide j\u00e4tmine ulatusesse ja plokkide t\u00f5stmine nendest failidest mahtude aega. Selle protsessi optimeerimiseks kasutatakse nn deh\u00fcpraatide indeksit, mis v\u00f5imaldab mitte kopeerida plokke, mis on juba mahu tingimusse kopeeritud. <\/p>\n<p>Vaatame, kuidas see n\u00e4eb v\u00e4lja n\u00e4ite p\u00f5hjal: oletame, et meil on .vbk, mis on v\u00e4lja l\u00e4inud operatiivaknast ja kuulub suletud ahelasse. See t\u00e4hendab, et meil on t\u00e4ielik \u00f5igus seda mahtude aega kanda. \u00dcleviimise hetkedel luuakse mahtude ajal metaandmefail ja \u00fcle kantud faili plokid. Metaandmefaili linkide tasandil kirjeldatakse, millistest plokkidest meie fail koosneb. Pildil on meie esime fail koondunud plokkidest a, b, c ja metaandmetes on lingid nendele plokkidele. Kui meil on teisene .vbk fail, mis on valmis \u00fcleviimiseks ja koosneb plokkidest a, b ja d, m\u00f5istame, anal\u00fc\u00fcsides deh\u00fcpraati indeksi, et peame \u00fcle viima ainult ploki d. Ja selle metaandmefail sisaldab linke kahe varasema ploki ja \u00fche uue kohta.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSeega, nende t\u00fchikute t\u00e4itmise protsessi nimetatakse regidratatsiooniks. Siin kasutatakse juba oma regidratatsiooni indeksit, mis p\u00f5hineb k\u00f5ige vanemal .vbk failil kohalikes perforeerimise ulatustes. See t\u00e4hendab, et kui kasutaja soovib faili tagasi tuua mahtude ajast, loome esmalt k\u00f5ige vanema t\u00e4ieliku varukoopia plokkide indeksi ja kanname mahtude ajast tagasi ainult puuduvad plokid. N\u00e4idatud olukorras, et regidreerida FullBackup1.vbk vastavalt regidratatsiooni indeksi n\u00f5udmistele, on meil puudu ainult plokk C, mille me kanname mahtude ajast. Kui mahtude ajaks on pilve objektide salvestus, v\u00f5imaldab see s\u00e4\u00e4sta tohutult raha.<\/p>\n<p>Siin v\u00f5ib tunduda, et see tehnoloogia sarnaneb WAN kiirendites kasutatavale, kuid see on vaid n\u00e4ilisus. Kiirendites toimub globaale deduplikatsioon, siinkohal kasutatakse kohaliku deduplikatsiooni mehhanismi iga faili teatud offseti ulatuses. See tuleneb lahendatavate probleemide erinevusest: siin peame kopeerima suuri t\u00e4isvarukoopia faile ja meie uuringute kohaselt annab selline deduplikatsioonine algoritm parima tulemuse, isegi kui nende vahel on suur ajavahemik.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAga rohkem indekseid jumalate indekseid! On veel andmete taastamise indeks! Kui k\u00e4ivitame masina taastamise, mis asub kapasititeeditarustuses, loeme ainult unikaalseid andmeplokke, mida ei ole j\u00f5udluse tarus.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Kuidas on muutunud<\/h1>\n<p>\nSissejuhatava osa osas on k\u00f5ik. See on \u00fcsna p\u00f5hjalik, kuid nagu eespool mainitud, ei saa me ilma nende detailideta selgitada, kuidas uued funktsioonid t\u00f6\u00f6tavad. Seega liigume ilma \u00fclearuste sissejuhatusteta esimesele teemale.<\/p>\n<h3>Kopeerimisre\u017eiim<\/h3>\n<p>\nP\u00f5him\u00f5tteliselt p\u00f5hineb see olemasolevatel tehnoloogiatel, kuid toob kaasa t\u00e4iesti teistsuguse kasutusloogika.\u00a0<\/p>\n<p>Selle re\u017eiimi eesm\u00e4rk on tagada, et k\u00f5ik andmed, mis asuvad kohalikul ulatusel, omavad koopiaid kapasititeeditarust.<\/p>\n<p>Kui v\u00f5rrelda otseselt Liikumis- ja Kopeerimisre\u017eiime, siis tulemused on j\u00e4rgmised:<\/p>\n<ul>\n<li>Liikuda saab ainult pitseeritud ahelaga. Kopeerimisre\u017eiimis viiakse \u00fcle k\u00f5ik, s\u00f5ltumata sellest, mis toimub varukoopia t\u00f6\u00f6s.<\/li>\n<li>Liikumine aktiveerub siis, kui failid \u00fcletavad varukoopiate operatiivakna piire, samas kui kopeerimine aktiveerub kohe, kui varukoopia fail ilmub.<\/li>\n<li>Uute andmete j\u00e4lgimine kopeerimiseks toimub pidevalt, samas kui liikumine toimib iga 4 tunni j\u00e4rel.<\/li>\n<\/ul>\n<p>\nUue re\u017eiimi arutamisel soovitan liikuda alates lihtsatest n\u00e4idetest keerukamate suunas.<\/p>\n<p>K\u00f5ige lihtsamas variandis ilmnevad meil lihtsalt uued failid koos inkremendiga ja me kopeerime need kapasititeeditarusse. Olenemata sellest, millist re\u017eiimi kasutatakse varukoopia t\u00f6\u00f6s, olenemata sellest, kas see kuulub pitseeritud osa ahelasse v\u00f5i mitte, olenemata sellest, kas meie operatiivaken on m\u00f6\u00f6dunud. Lihtsalt v\u00f5tame ja kopeerime.<\/p>\n<p>Protsess, mis sellega kaasneb, on endiselt deh\u00fcdreerimine, nagu eelnevalt kirjeldatud. Kopeerimisre\u017eiimis j\u00e4lgib ta ka, et me ei kopeeriks bloke, mis juba meie objektide salvestuses on. Ainus erinevus on see, et kui liikumisre\u017eiimis asendasime reaalsed failid t\u00fchjade failidega, siis siin me neid \u00fcldse ei puutu ja j\u00e4tame k\u00f5ik nii, nagu on. \u00dclej\u00e4\u00e4nud on just selline deh\u00fcdreerimise indeks, mis p\u00fc\u00fcab hoolikalt s\u00e4\u00e4sta teie raha ja aega.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00fcsimus on \u2014 kui vaadata kasutajaliidest (UI), siis seal on v\u00f5imalus valida m\u00f5lemat valikut korraga. Kuidas selline kombineeritud re\u017eiim t\u00f6\u00f6tab?<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHakkame m\u00f5tlema.<\/p>\n<p>Standard algus: luuakse varukoopia fail ja see kopeeritakse kohe. Sellele luuakse inkrement ja see kopeeritakse samuti. Nii toimub kuni hetkeni, mil me m\u00f5istame, et failid on v\u00e4lja tulnud meie tegevusaknast ja on tekkinud suletud ahel. Sel hetkel teostame deh\u00fcdreerimise operatsiooni ja asendame selle failid t\u00fchjadega. Loomulikult ei kopeeri me uuesti kapatsitiirele midagi.<\/p>\n<p>Kogu selle p\u00f5neva loogika taga on vaid \u00fcks linnuke liideses: Kopeeri varukoopiad objektide salvestusse kohe p\u00e4rast nende loomist.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Aga miks me seda Kopeerimise re\u017eiimi vajame? <\/h3>\n<p>\nIsegi paremini oleks k\u00fcsida: milliste riskide eest me end selle abil kaitseme? Millist probleemi ta aitab meil lahendada?<\/p>\n<p>Vastus on ilmne: muidugi, see on andmete taastamine. Kui meil on objektide salvestuses t\u00e4ielik koopia kohalikest andmetest, siis pole oluline, mis meie tootmises juhtub, me saame alati andmed taastada failidest, mis asuvad tingimuslikult Amazoni serveris.<\/p>\n<p>Seega, las k\u00e4ime l\u00e4bi v\u00f5imalikud stsenaariumid, alates k\u00f5ige lihtsamast kuni keerukamate juurde.<\/p>\n<p>Lihtsaim mure, mis meie pea kohale v\u00f5ib langeda, on \u00fche faili k\u00e4ttesaamatus varukoopiate ahelas.<\/p>\n<p>Karmim lugu on see, et \u00fcks meie SOBR-repositooriumi ekstrektidest on katki.<\/p>\n<p>Isegi hullem on see, kui kogu SOBR-repositoorium on k\u00e4ttesaamatu, kuid kapatsitiir t\u00f6\u00f6tab.<br \/>\nJa olukord on t\u00e4iesti halb, kui varukoopia server sureb ja sinu esimene soov on proovida k\u00fcmne minuti jooksul kanada piiri joosta.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" 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 me kaotasime \u00fche (jah, isegi mitu) varukoopiat, siis piisab, kui k\u00e4ivitada repositooriumi skaneerimise protsess, ja kadunud fail asendatakse t\u00fchja failiga. Ja taaskasutamise protsessi abil (mille kohta r\u00e4\u00e4giti artikli alguses) saab kasutaja alla laadida andmed mahutustasandilt kohalikku salvestusse.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nN\u00fc\u00fcd on olukord keerulisem. Oletame, et meie SOBR koosneb kahest ekstensioonist, mis t\u00f6\u00f6tavad j\u00f5udluse re\u017eiimis, seega on meie .vbk ja .vib nende vahel \u00fcsna ebatasaselt jaotatud. Ja mingil hetkel muutub \u00fcks ekstensioon k\u00e4ttesaamatuks, kuid kasutaja peab kiiresti taastama masina, mille osad andmed asuvad just selles ekstensioonis. <\/p>\n<p>Kasutaja k\u00e4ivitab taastamisviisardi, valib punkt, kuhu soovib taastada, ja viisard t\u00f6\u00f6 k\u00e4igus m\u00f5istab, et tal ei ole vajalikku taastamiseks vajalikku andmeid kohalikult ning seet\u00f5ttu tuleb need alla laadida mahutustasandilt. Samuti ei laadi pilvest alla blokid, mis on j\u00e4\u00e4nud kohalikku salvestusse. T\u00e4nu taastamise indeksile (jah, ka sellest r\u00e4\u00e4giti artikli alguses).<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSelle juhtumi alaliik \u2013 kogu SOBR repositoorium on muutunud k\u00e4ttesaamatuks. Sellisel juhul ei ole meil midagi kopeerida kohalikest salvestustest ja k\u00f5ik blokid laevad pilvest alla.<\/p>\n<p>Ja k\u00f5ige huvitavam olukord \u2013 varundusserver on l\u00e4bi. Siin on kaks varianti: admin on tubli ja tegi konfiguratsiooni varukoopiaid, v\u00f5i admin on ise endale kuri Buratino ja ei teinud konfiguratsiooni varukoopiat.<\/p>\n<p>Esimesel juhul piisab lihtsalt puhta VBR installatsiooni kuskil \u00fcles seadmisest ja tema andmebaasi taastamisest varukoopiast tavap\u00e4raste vahenditega. Selle protsessi l\u00f5puks naaseb k\u00f5ik oma kohale. V\u00f5i taastatakse see \u00fche eelneva stsenaariumi kohaselt.<\/p>\n<p>Kuid kui administraator on endale ise vaenlane v\u00f5i on varukoopia konfiguratsioon kaotanud kaasaegse eba\u00f5nne, siis isegi siin me ei j\u00e4ta teda saatuse hooleks. Selle juhtumi jaoks oleme k\u00e4ivitanud uue protseduuri nimega Import Object Storage. See v\u00f5imaldab v\u00e4ltida k\u00e4sitsi SOPR-i reposiitri taastamise protsessi ning selle maht\u00fctleva kapi \u00fchendamist, vaid lihtsalt lisada objektide salvestuse liideses ja k\u00e4ivitada Import Storage Repository protseduur. Ainus, mis v\u00f5ib teie ja teie varukoopiate vahel teele seista, on palve sisestada parool, kui teie varukoopiad on kr\u00fcpteeritud.<\/p>\n<p>Sellega Copy Mode kohta on k\u00f5ik ja liigume edasi<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nP\u00f5hjus on selles, et valitud SOBR reposiitri ulatuses ei saa ilmneda uusi varukoopiaid. Kuni v10-ni oli meil ainult hooldusre\u017eiim, kus igasugune t\u00f6\u00f6 reposiitariga oli t\u00e4ielikult keelatud. See oli selline karm re\u017eiim, kus oli saadaval ainult Evacuate nupp, mis korduvasti t\u00f5i varukoopiad teise ulatusse.<\/p>\n<p>Sealed mode on omamoodi \"pehme\" variant: keeldume uute varukoopiate loomisel ja j\u00e4rk-j\u00e4rgult kustutame vanu vastavalt valitud s\u00e4ilitamisele, kuid protsessis ei kaota me v\u00f5imalust taastuda salvestatud punktidest. V\u00e4ga kasulik asi, kui meie seadme eluiga on l\u00f5ppemas ja seda tuleb asendada, v\u00f5i tuleb lihtsalt midagi olulisemat selle jaoks vabastada, samas ei ole v\u00f5imalik k\u00f5ike korraga \u00fcle tuua. V\u00f5i ei saa kustutada. <\/p>\n<p>Seega t\u00f6\u00f6p\u00f5him\u00f5te on \u00fcsna lihtne: tuleb keelata k\u00f5ik kirjutamisoperatsioonid (uudsete andmete ilmumine), j\u00e4ttes lugemis- (taastused) ja kustutamis- (s\u00e4ilitamine) tegevused.<\/p>\n<p>M\u00f5lemat re\u017eiimi saab kasutada samaaegselt, kuid tuleb arvestada, et hoolduse prioriteet on k\u00f5rgem.<\/p>\n<p>N\u00e4itena vaatame SOBR-i, mis koosneb kahest ulatusest. Oletame, et esimestel neljal p\u00e4eval loodi varukoopiad Forward Forever Incremental re\u017eiimis, ja siis me pitseerime ulatuse. See viib selleni, et me k\u00e4ivitame uue aktiivse t\u00e4isloomise loomise teises k\u00e4ttesaadavas ulatuses. Kui meie s\u00e4ilitamine on neli, siis kui kogu kett, mis asub pitseeritud ulatuses, \u00fcletab selle piire, saab see rahuliku s\u00fcdamega kustutada.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" 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, see on Forward incremental koos perioodiliste full backup'idega. Kui esimesed kaks p\u00e4eva oli meil tehtud full backup'id, ja neljap\u00e4eval otsustame reposiiti pitseerida, siis reede hommikul, kui luuakse uus full backup, eemaldatakse esmasp\u00e4eva fail, kuna sellel punktidel ei ole s\u00f5ltuvusi. Ja see punkt iseenesest ei s\u00f5ltu kelleltki. P\u00e4rast seda ootame, kuni tehakse neli punkti saadaval oleval ulatusel ja kustutame kolm \u00fclej\u00e4\u00e4nud, mis ei saa \u00fcksteisest s\u00f5ltumatult eemaldatud olla.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nReverse Incrementali korral on asjad lihtsamad. Seal ei s\u00f5ltu vanimad punktid kellestki ja need saab rahulikult eemaldada. Seet\u00f5ttu, kui uus .vbk luuakse uuel ulatusel, vanad .vrb eemaldatakse \u00fckshaaval.<\/p>\n<p>Muide, miks me iga kord uue .vbk loome: kui seda ei tehta ja j\u00e4tkatakse vana inkrementide jada, siis vana .vbk j\u00e4\u00e4ks igavesti rippuma, takistades selle kustutamist. Seet\u00f5ttu on otsustatud, et kohe kui ulatus pitseeritakse, loome uue full backup'i vabale ulatusele.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAsjad on keerulisemad kapasitatiivse tihedusega. <\/p>\n<p>Esmalt vaatame copy re\u017eiimi. Oletame, et nelja p\u00e4eva jooksul loodi aktiivselt varukoopiaid, ja siis pitseeriti kapasitatiivne tihedus. Me ei kustuta midagi, vaid kannatlikult kannatame s\u00e4ilitamise aja, mille j\u00e4rel kustutame andmed kapasitatiivse tihedusega.<\/p>\n<p>P\u00f5him\u00f5tteliselt toimub sama ka move re\u017eiimis \u2014 ootame s\u00e4ilitamise aega, kustutame vana kohalikus ladustamises, ja kustutame objektide salvestuses hoitava.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHuvitav n\u00e4ide Forever forward incremental'i kohta. Seame s\u00e4ilitamise ajaks kolm punkti ja hakkame esmasp\u00e4evast alustama varukoopiaid, mis kopeeritakse usinalt pilve. P\u00e4rast ladustamise pitseerimist j\u00e4tkub varukoopiate loomine, s\u00e4ilitades kolm punkti, kuid kapasitatiivse tiheduse andmed j\u00e4\u00e4vad s\u00f5ltuvaks ja ei saa kustutada. Seet\u00f5ttu ootame neljap\u00e4eva, kui meie .vbk j\u00e4\u00e4b s\u00e4ilitamise ajast v\u00e4lja, ja alles siis kustutame kogu salvestatud jada rahulikult.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa v\u00e4ike t\u00e4psustus: k\u00f5ik siin toodud n\u00e4ited puudutavad \u00fchte masinat. Kui teil on varukoopias mitu, siis nende s\u00e4ilitamine v\u00f5ib erineda s\u00f5ltuvalt sellest, kas on tehtud Active Full v\u00f5i mitte.<\/p>\n<p>Peale seda ongi k\u00f5ik. Nii et liigume edasi k\u00f5ige karmima funktsiooni juurde \u2014 <\/p>\n<h3>Immutability <\/h3>\n<p>\nNagu ka eelnevate punktide puhul, r\u00e4\u00e4gime esmalt sellest, millist probleemi see funktsioon lahendab. Niipea, kui salvestame oma varukoopiad kuhugi, tekib suur soov tagada nende s\u00e4ilimine, see t\u00e4hendab f\u00fc\u00fcsiliselt keelata nende kustutamine ja igasugused muudatused m\u00e4\u00e4ratud retentsiooniperioodi jooksul. See kehtib ka administraatorite ja nende juurkontode puhul. See kaitseb varukoopiaid juhusliku v\u00f5i tahtliku kahjustamise eest. Need, kes t\u00f6\u00f6tavad AWS-iga, on v\u00f5inud kohtuda sellise funktsiooniga nimega Object Lock.<\/p>\n<p>N\u00fc\u00fcd vaatame re\u017eiimi \u00fcldiselt ja seej\u00e4rel s\u00fcveneme detailidesse. Meie n\u00e4ites on Immutability aktiveeritud meie mahutite jaoks, mille retentsiooniperiood on neli p\u00e4eva. Varukoopias on aktiveeritud Copy re\u017eiim.<\/p>\n<p>Immutability ei m\u00f5juta \u00fcldist retentsiooniperioodi. N\u00e4iteks ei lisa see lisapunkte ega midagi sellist. Lihtsalt nelja p\u00e4eva jooksul ei saa inimene varukoopia faile kustutada. Kui esmasp\u00e4eval varukoopia teha, saab selle faili kustutada ainult reedel.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00f5ik varem selgitatud deh\u00fcdratsiooni, indeksite ja metaandmete kontseptsioonid t\u00f6\u00f6tavad t\u00e4pselt samamoodi. Kuid \u00fche tingimuse t\u00e4itmisega \u2014 blokk kehtestatakse mitte ainult andmete, vaid ka metaandmete osas. See on tehtud selleks, et olukordades, kus kurjategija proovib meie metaandmebaasi kustutada, ei muutuks andmeblokkides olevad andmed kasutu binaarseks segaduseks.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa n\u00fc\u00fcd on suurep\u00e4rane aeg selgitada meie plokkide genereerimise tehnoloogiat. V\u00f5i block generation. Selleks vaatame olukorda, mis viis selle tekkimiseni.<\/p>\n<p>V\u00f5tame ajaskaala kuue p\u00e4eva jooksul ja t\u00e4histame allpool oodatud immutability l\u00f5ppemise aega. Loome esimesel p\u00e4eval faili, mis koosneb plokist a ja selle metaandmetest. Kui immutability on seadistatud kolme p\u00e4eva jooksul, on loogiline eeldada, et neljandal p\u00e4eval andmed avatakse ja kustutatakse. Teisel p\u00e4eval lisame uue file2, mis koosneb plokist b samade seadistustega. Plokk a peab endiselt olema kustutatud neljandal p\u00e4eval. Kuid kolmandal p\u00e4eval juhtub \u00f5uduste aeg \u2014 luuakse fail File3, mis koosneb uuest plokist d ja lingist vana ploki a peale. See t\u00e4hendab, et ploki a immutability lipp peab olema uuesti seatud uue t\u00e4htaja jaoks, mis nihkub kuuendale p\u00e4evale. Siin tekib probleem \u2014 tegelikes varukoopiate plokkides tekib tohutu hulk. Ja kuna immutability perioodi pikendamiseks tuleb iga kord teha tohutu hulk p\u00e4ringuid, kujuneb tegelikult v\u00e4lja peaaegu l\u00f5pmatu igap\u00e4evane protsess, kuna suure t\u00f5en\u00e4osusega leiame iga kopeerimise korral suured kuhjad deduplica kohta. Ja mis t\u00e4hendab suur hulk p\u00e4ringute korral objektide salvestuspakkujate juures? \u00d5ige! Suur arve kuu l\u00f5puks.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJa et mitte oma armastatud kliente suure raha eest t\u00fchja kohta j\u00e4tta, loodi block generation mehhanism. See on lisaperiood, mida me lisame seatud immutability perioodile. Allolevas 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 puhul. <\/p>\n<p>J\u00e4tkame sama olukorra vaatlemist, kuid juba block generation'i kontekstis. Looma esimesel p\u00e4eval file1 plokist a ja metaandmetest. Koondame genereerimisperioodi ja immutability \u2014 see t\u00e4hendab, et faili kustutamise v\u00f5imalus on kuuendal p\u00e4eval. Kui teisel p\u00e4eval loome File2, mis koosneb plokist b ja lingist plokile a, siis oodatav kustutamise kuup\u00e4ev ei muutu. See j\u00e4\u00e4b kuuendaks p\u00e4evaks. Ja me \u00fcritame s\u00e4\u00e4sta raha p\u00e4ringute arvu pealt. Ainus olukord, kus t\u00e4htaega saab nihutada, on siis, kui genereerimisperiood on l\u00f5ppenud. See t\u00e4hendab, et kui kolmandal p\u00e4eval uus File3 sisaldab linki plokile a, siis lisandub genereerimine 2, kuna Gen1 on juba l\u00f5ppenud. Oodatav ploki a kustutamise kuup\u00e4ev nihkub kaheksandale p\u00e4evale. See v\u00f5imaldab meil dramaatiliselt v\u00e4hendada p\u00e4ringute arvu deduplicaeritud plokkide eluea pikendamiseks, mis s\u00e4\u00e4stab kliente tohutult raha.<\/p>\n<p><img decoding=\"async\" alt=\"Mis on muutunud Capacity Tieris, kui Veeam sai v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTehnoloogia on saadaval S3 ja S3 \u00fchilduvate seadmete kasutajatele, mille tootjad garantii, et nende rakendus ei erine Amazoni omast. Seega on vastus seaduslikule k\u00fcsimusele, miks Azure't ei toetata \u2014 neil on sarnane funktsioon, kuid see t\u00f6\u00f6tab konteinerite tasemel, mitte eraldi objektide tasemel. Muide, Amazoni enda obkject lock on kahes re\u017eiimis: compliance ja governance. Teises re\u017eiimis j\u00e4\u00e4b v\u00f5imalus, et suurim administraator, kes on \u00fcle administreerijatest ja juur juurtest, hoolimata obkject lock'ist, suudab andmeid siiski kustutada. Compliance'i korral on k\u00f5ik naelutatud kindlalt ja varukoopiad ei saa keegi kustutada. Isegi Amazoni administraatorid (nende ametlike avalduste kohaselt). Me toetame just seda re\u017eiimi.<\/p>\n<p>\nJa traditsiooniliselt m\u00f5ned kasulikud lingid:<\/p>\n<ul>\n<li>K\u00fcsimus <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Block Generation<\/a><\/noindex> k\u00f5igis \u00fcksikasjades.<\/li>\n<li>Kogu teave <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> parimal v\u00f5imalikul viisil<\/li>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> \u00fcksikasjades<\/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 5.0.1.1 - 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.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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\udd47Mis muutus Capacity Tier'is, kui Veeam sai v10 | ProHoster","description":"Capacity Tier (v\u00f5i nagu me seda enda vahel nimetame \u2014 kaptir) ilmus juba Veeam Backup and Replication 9.5 Update 4 ajal nimega Archive Tier.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}