{"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\/hr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Kapacitetni Tier (ili kako ga mi zovemo internu \u2014 kapitir) pojavio se jo\u0161 u vrijeme Veeam Backup and Replication 9.5 Update 4 pod imenom Archive Tier. Ideja koja stoji iza njega je omogu\u0107iti premje\u0161tanje sigurnosnih kopija koje su ispale iz takozvanog operativnog prozora vra\u0107anja na objektna spremi\u0161ta. Ovo je pomagalo u osloba\u0111anju prostor na disku korisnicima kojima je to bilo potrebno. Ova opcija nazivala se Move Mode.<\/p>\n<p>Za izvr\u0161enje ove jednostavne (kako se \u010dini) radnje bilo je dovoljno ispuniti dva uvjeta: sve to\u010dke iz premje\u0161tane sigurnosne kopije moraju biti izvan prethodno spomenutog operativnog prozora vra\u0107anja, koji se uo\u010dava u korisni\u010dkom su\u010delju. I drugo: lanac mora biti u takozvanom \u201ezape\u010da\u0107enom obliku\u201c (sealed backup chain ili Inactive Backup Chain). Odnosno, s vremenom u ovom lancu ne dolazi do promjena.<\/p>\n<p>Me\u0111utim, u VBR v10 koncept je oboga\u0107en novim funkcijama \u2014 uvedeni su Copy Mode, Sealed Mode i stvar s te\u0161ko izgovorivim imenom Immutability.<\/p>\n<p>O ovim zanimljivim stvarima danas \u0107emo razgovarati. Prvo o tome kako je to funkcioniralo u VBR9.5u4, a zatim o promjenama u desetoj verziji.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI neka mi oproste ljubitelji \u010distog jezika, ali previ\u0161e termina jednostavno nije mogu\u0107e prevesti.<br \/>\nTako da \u0107e ovdje biti mnogo anglicizama.<br \/>\nI mnogo GIF-ova. <br \/>\nI slika.<\/p>\n<ul>\n<li>Bez ikakvih \u017ealjenja. Autor \u010dlanka.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Kako je bilo<\/h1>\n<p>\nPa, zapo\u010dnimo s obradom operativnog prozora vra\u0107anja i zape\u010da\u0107ene sigurnosne kopije (ili kako ih nazivaju u dokumentaciji Inactive Backup Chain). Bez njihovog razumijevanja daljnje obja\u0161njenje ne\u0107e biti mogu\u0107e.<\/p>\n<p>Kao \u0161to mo\u017eemo vidjeti na slici, imamo neku sigurnosnu kopiju s blokovima podataka, koja je smje\u0161tena na Performance tier SOBR repozitoriju, na koji je povezan Capacity Tier. Na\u0161e operativno prozor vra\u0107anja je tri dana.<\/p>\n<p>Prema tome, .vbk stvoren u ponedjeljak pe\u010dati prethodni lanac, \u010dije je prozra\u010dje postavljeno na tri dana. I, stoga, mo\u017eemo mirno po\u010deti premje\u0161tati u kapacitetni tier sve \u0161to je starije od tri dana.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAli \u0161to se zapravo podrazumijevalo pod zape\u010da\u0107enim lancem i \u0161to se moglo slati u kapacitetni tier u update 4?<\/p>\n<p>Za Forward Incremental oznaka zape\u010da\u0107enja lanca je stvaranje nove pune sigurnosne kopije. I nije va\u017eno kako ta puna sigurnosna kopija nastaje: uzimaju se u obzir i synthetic full, i active full sigurnosne kopije.<\/p>\n<p>U slu\u010daju Reverse, to su svi datoteke koje ne ulaze u operativni prozor. <\/p>\n<p>U slu\u010daju Forward increment s rollback-ovima, to su svi rollback-ovi i .vbk, ako na performance extentu postoji jo\u0161 jedan .vbk.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSada razmotrimo varijantu rada s Backup Copy lancima. Ovdje se prevozilo samo ono \u0161to spada pod GFS retention. Jer sve \u0161to se nalazi u novijim backup copy lancima mo\u017ee biti na bilo koji na\u010din promijenjeno.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSada zavirimo ispod haube. Tamo se odvija proces koji se naziva dehidratacija \u2014 ostavljanje praznih backup datoteka na extentu i prebacivanje blokova iz tih datoteka na capacity tier. Za optimizaciju ovog procesa koristi se takozvani indeks dehidratacije koji omogu\u0107uje ne kopiranje blokova koji su ve\u0107 bili kopirani u capacity tier. <\/p>\n<p>Pogledajmo kako to izgleda na primjeru: pretpostavimo da imamo .vbk koji je iza\u0161ao iz operativnog prozora i pripada zape\u010da\u0107enoj lancu. To zna\u010di da imamo potpuno pravo premjestiti ga u capacity tier. U trenutku premje\u0161tanja stvara se metadatna datoteka u capacity tieru i blokovi datoteke koja se premje\u0161ta. U metadatnoj datoteci na razini referenci opisuje se od kojih blokova se sastoji na\u0161a datoteka. U slu\u010daju na slici, na\u0161a prva datoteka sastoji se od blokova a, b, c, a u metadatama su sadr\u017eane reference na te blokove. Kada se pojavi druga .vbk datoteka, spremna za premje\u0161tanje i sastavljena od blokova a, b i d, analiziraju\u0107i indeks dehidratacije, shva\u0107amo da treba premjestiti samo blok d. A njezina metadatna datoteka \u0107e sadr\u017eavati reference na dva prethodna bloka i jedan novi.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrema tome, proces vra\u0107anja tih praznih blokova podacima naziva se rehidratacija. Ovdje se koristi vlastiti indeks rehidratacije, oslanjaju\u0107i se na najstariju .vbk datoteku na lokalnom performance extentu. Dakle, ako korisnik \u017eeli vratiti datoteku iz capacity tiera, prvo stvaramo indeks blokova najstarijeg potpunog backup-a i premje\u0161tamo iz capacity tiera samo nedostaju\u0107e blokove. U slu\u010daju prikazanom na slici, kako bismo rehidratirali FullBackup1.vbk prema indeksu rehidratacije, nedostaje nam samo blok C, koji uzimamo iz capacity tiera. Ako kao capacity tier slu\u017ei oblakni objektni storage, to omogu\u0107uje u\u0161tedu ogromnih koli\u010dina novca.<\/p>\n<p>Ovdje se mo\u017ee \u010diniti da je ova tehnologija identi\u010dna onoj koja se koristi u WAN akceleratorima, ali to je samo privid. U akceleratorima se vr\u0161i globalna deduplikacija, dok se ovdje koristi lokalna unutar svakog datoteke na odre\u0111enoj offsetu. To se doga\u0111a zbog razlike u zadacima: ovdje trebamo kopirati velike datoteke punih sigurnosnih kopija, i prema na\u0161im istra\u017eivanjima, \u010dak i ako izme\u0111u njih pro\u0111e du\u017ei vremenski period, takav algoritam deduplikacije daje najbolje rezultate.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAli vi\u0161e indeksa bogu indeksa! Tu je i indeks za vra\u0107anje podataka! Kada pokrenemo vra\u0107anje stroja smje\u0161tenog u kapacitetu, \u010ditat \u0107emo samo jedinstvene blokove podataka koji nisu u performansama.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Kako je postalo<\/h1>\n<p>\nS ovim smo zavr\u0161ili uvodni dio. On je prili\u010dno detaljan, ali, kao \u0161to je re\u010deno, bez tih detalja ne mo\u017ee se objasniti kako nove funkcije funkcioniraju. Stoga bez dodatnih uvoda prelazimo na prvo.<\/p>\n<h3>Copy mode<\/h3>\n<p>\nU velikoj mjeri temelji se na postoje\u0107im tehnologijama, me\u0111utim nosi sa sobom potpuno druga\u010diju logiku kori\u0161tenja.\u00a0<\/p>\n<p>Cilj ovog na\u010dina rada je osigurati da svi podaci smje\u0161teni na lokalnom ekstentu imaju kopiju u kapacitetu.<\/p>\n<p>Ako usporedimo direktno Move i Copy na\u010dine rada, ispada ovako:<\/p>\n<ul>\n<li>Mo\u017ee se premje\u0161tati samo zaklju\u010dena niz. U slu\u010daju na\u010dina rada kopiranja prevozi se apsolutno sve, bez obzira na to \u0161to se doga\u0111a u sigurnosnoj kopiji.<\/li>\n<li>Premje\u0161tanje se aktivira kada datoteke iza\u0111u iz okvira operativne sigurnosne kopije, dok se kopiranje aktivira odmah, \u010dim se pojavi datoteka sigurnosne kopije.<\/li>\n<li>Pra\u0107enje novih podataka za kopiranje doga\u0111a se stalno, dok se premje\u0161tanje aktivira svaka 4 sata.<\/li>\n<\/ul>\n<p>\nU razmatranju novog na\u010dina rada predla\u017eem da idemo od jednostavnih primjera do slo\u017eenih.<\/p>\n<p>U najjednostavnijem slu\u010daju jednostavno se pojavljuju nove datoteke s inkrementima, i jednostavno ih kopiramo u kapacitet. Bez obzira na to koji na\u010din se koristi u sigurnosnoj kopiji, bez obzira na to pripada li zatvorenoj seriji ili ne, bez obzira na to je li isteklo na\u0161e operativno okno. Samo smo uzeli i kopirali.<\/p>\n<p>Proces koji stoji iza ovoga i dalje je dehidratacija na na\u010din koji je gore opisan. U re\u017eimu kopiranja tako\u0111er se prati kako ne bismo kopirali blokove koji ve\u0107 postoje u na\u0161em objektu. Jedina razlika je \u0161to, dok smo u re\u017eimu premje\u0161tanja zamjenjivali stvarne datoteke datotekama praznim datotekama, ovdje ih ne diramo i ostavljamo sve kakvo jest. U ostalom, ovo je posve isti indeks dehidratacije koji pomno nastoji u\u0161tedjeti va\u0161 novac i vrijeme.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPostavlja se pitanje \u2014 ako pogledamo u korisni\u010dko su\u010delje, postoji mogu\u0107nost odabira obje opcije istovremeno. Kako \u0107e raditi ovaj kombinirani na\u010din?<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHajde da istra\u017eimo.<\/p>\n<p>Po\u010detak je standardan: stvara se datoteka sigurnosne kopije i odmah se kopira. Uz nju se stvara inkrement i tako\u0111er se kopira. To se doga\u0111a sve dok ne shvatimo da su datoteke iza\u0161le iz na\u0161eg operativnog prozora i da je nastala zape\u010da\u0107ena poveznica. U tom trenutku radimo operaciju dehidratacije i zamjenjujemo te datoteke praznim datotekama. Naravno, ponovo na kapacitetu ni\u0161ta ne kopiramo.<\/p>\n<p>Za svu ovu zanimljivu logiku odgovara samo jedna oznaka u su\u010delju: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>A za\u0161to nam je potreban ovaj Copy re\u017eim? <\/h3>\n<p>\n\u010cak je bolje preformulirati pitanje \u2014 od kojih rizika se \u0161titimo pomo\u0107u njega? Koji problem nam poma\u017ee rije\u0161iti?<\/p>\n<p>Odgovor je o\u010dit: naravno, to je obnova podataka. Ako imamo potpunu kopiju lokalnih podataka u objektu, nije va\u017eno \u0161to se dogodi s na\u0161im proizvodom, uvijek mo\u017eemo obnoviti podatke iz datoteka koje se nalaze u uvjetnoj Amazon.<\/p>\n<p>Stoga, hajde da pro\u0111emo kroz mogu\u0107e scenarije, od najjednostavnijeg do slo\u017eenijeg.<\/p>\n<p>Najjednostavnija nepogoda koja mo\u017ee pasti na na\u0161e glave \u2014 to je nedostupnost jedne od datoteka u sigurnosnoj kopiji.<\/p>\n<p>Tu\u017enija pri\u010da \u2014 jedan od ekstenta na\u0161eg SOBR repozitorija je pao.<\/p>\n<p>Jo\u0161 gore postaje kada cijeli SOBR repozitorij postane nedostupan, ali radi kapacitet.<br \/>\nA najgore od svega \u2014 to je kada umre server za sigurnosnu kopiju i va\u0161a prva \u017eelja je poku\u0161ati dotr\u010dati do kanadske granice za deset minuta.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA sada hajde da razradimo svaku situaciju zasebno.<\/p>\n<p>Kada izgubi jedan (ili, da, \u010dak nekoliko) backup datoteka, samo treba pokrenuti proces skeniranja repozitorija, a izgubljena datoteka \u0107e biti zamijenjena datotekom prazninom. A uz pomo\u0107 procesa rehidratacije (o kojem je bilo rije\u010di na po\u010detku \u010dlanka) korisnik mo\u017ee preuzeti podatke iz kapacitetnog tira u lokalnu pohranu.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSada je situacija slo\u017eenija. Pretpostavimo da na\u0161 SOBR sastoji od dva ekstenziona koja rade u Performance modu, \u0161to zna\u010di da su na\u0161i .vbk i .vib nerazmjerno raspore\u0111eni po njima. I u nekom trenutku jedan od ekstenziona postaje nedostupan, a korisnik mora hitno obnoviti ma\u0161inu, \u010diji dio podataka se nalazi ba\u0161 na tom ekstenziju. <\/p>\n<p>Korisnik pokre\u0107e \u010darobnjaka za oporavak, bira to\u010dku na koju \u017eeli obnoviti, a \u010darobnjak u procesu rada shvata da svi potrebni podaci za oporavak nisu lokalno dostupni i da ih treba preuzeti iz kapacitetnog tira. Pri tome, blokovi koji su ostali na lokalnoj pohrani ne\u0107e se preuzimati iz oblaka. Hvala indek\u0441\u0443 povratka (da, o njemu je tako\u0111er bilo rije\u010di na po\u010detku \u010dlanka).<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPodvrsta ovog slu\u010daja \u2014 cijeli SOBR repozitorij postaje nedostupan. U tom slu\u010daju nemamo \u0161to kopirati s lokalnih pohrana, i svi blokovi se preuzimaju iz oblaka.<\/p>\n<p>I najzanimljivija situacija \u2014 backup server je umro. Ovdje postoje dvije opcije: admin je pametan i radio je konfiguracijske backup-e, ili je admin sam sebi zlobni Buratino i nije napravio konfiguracijski backup.<\/p>\n<p>U prvom slu\u010daju, bit \u0107e dovoljno samo negdje postaviti \u010distu instalaciju VBR-a i obnoviti njegovu bazu iz backupa standardnim sredstvima. Na kraju ovog procesa sve \u0107e se vratiti na svoje mjesto. Ili \u0107e se obnova izvr\u0161iti prema jednom od scenarija iznad.<\/p>\n<p>No, ako je administrator ili sebi neprijatelj, ili je sigurnosna kopija konfiguracije tako\u0111er do\u017eivjela mitolo\u0161ku nesre\u0107u, tada ga ovdje ne\u0107emo prepustiti samom sebi. Za ovaj slu\u010daj uveli smo novu proceduru koja se zove Import Object Storage. Ona omogu\u0107ava presko\u010diti ru\u010dni proces ponovne izrade SOBR repozitorija i njegovog povezivanja s kapacitetom tira, a jednostavno dodati objektno skladi\u0161te u su\u010delje Veeam i pokrenuti Import Storage Repository proceduru. Jedina prepreka koja mo\u017ee stati izme\u0111u vas i va\u0161ih sigurnosnih kopija jest zahtjev za unosom lozinke ako su va\u0161e sigurnosne kopije bile \u0161ifrirane.<\/p>\n<p>\u0160to se ti\u010de Copy Mode-a, mislim da je to sve, a prelazimo na<\/p>\n<h3>Sealed Mode<\/h3>\n<p>\nGlavna ideja je da se na odabranom ekstentu SOBR repozitorija ne mogu pojaviti nove sigurnosne kopije. Do verzije 10 imali smo samo Maintenance Mode, kada je potpuno zabranjen bilo kakav rad s repozitorijem. To je bio pravi hardcore na\u010din isklju\u010denja skladi\u0161ta iz rada, gdje je dostupna samo tipka Evacuate koja je jednokratno premje\u0161tala sigurnosne kopije na drugi ekstent.<\/p>\n<p>A Sealed mode je svojevrstan \u201emeki\u201c oblik: zabranjujemo stvaranje novih sigurnosnih kopija i postepeno uklanjamo stare prema odabranom retentionu, ali u tom procesu ne gubimo mogu\u0107nost oporavka iz spremljenih to\u010daka. Vrlo korisna stvar kada nam se pribli\u017eava kraj vijeka trajanja opreme i treba ju zamijeniti, ili je jednostavno potrebno osloboditi za ne\u0161to va\u017enije, a ne mo\u017eemo jednostavno sve prenijeti. Ili nije mogu\u0107e izbrisati. <\/p>\n<p>Prema tome, princip rada je prili\u010dno jednostavan: treba zabraniti sve write operacije (pojavljuje se novih podataka), ostavljaju\u0107i read (restoracije) i delete (retention).<\/p>\n<p>Oba moda se mogu koristiti istovremeno, samo treba uzeti u obzir da Maintenance ima vi\u0161i prioritet.<\/p>\n<p>Kao primjer razmotrit \u0107emo SOBR sastavljen od dva ekstenta. Pretpostavimo da su prvih \u010detvrt dana sigurnosne kopije kreirane u na\u010dinu Forward Forever Incremental, a zatim zapsealed ekstent. To dovodi do toga da zapo\u010dinjemo stvaranje novog aktivnog full-a na drugom dostupnom ekstentu. Ako je na\u0161 retention \u010detiri, kada cijeli lanac smje\u0161ten na zapelom ekstentu prema\u0161i njegovu granicu, on se s mirnom savje\u0161\u0107u mo\u017ee izbrisati.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPostoje situacije kada se brisanje odvija ranije. Na primjer, to su Forward incremental s periodi\u010dnim punim backupima. Ako su prva dva dana ra\u0111eni puni backupovi, a u \u010detvrtak odlu\u010dimo zape\u010datiti repozitorij, onda \u0107e u petak, kada se stvori novi puni backup, datoteka iz ponedjeljka biti obrisana jer do tog trenutka nema zavisnosti. I sama ta to\u010dka ne ovisi ni o \u010demu. Nakon toga \u010dekamo da se stvore \u010detiri to\u010dke na dostupnom ekstenziju i bri\u0161emo preostale tri koje ne mogu biti neovisno obrisane.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS obzirom na Reverse Incremental, situacija je jednostavnija. U njemu najstarije to\u010dke ne ovise ni o \u010demu i mogu se slobodno brisati. Stoga, \u010dim se stvori novi .vbk na novom ekstenziju, stare .vrb bit \u0107e brisane jednu po jednu.<\/p>\n<p>Usput, za\u0161to svaki put stvaramo novi .vbk: ako ga ne bismo stvarali, a nastavili bismo staru lanac inkrementa, stari .vbk bi se vje\u010dno visio u bilo kojem re\u017eimu, onemogu\u0107avaju\u0107i njegovo brisanje. Stoga je donesena odluka da \u010dim se ekstenzija zape\u010dati, stvaramo puni backup na slobodnom ekstenziju.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSituacija je slo\u017eenija s kapacitetom tira. <\/p>\n<p>Prvo razmotrite copy mode. Pretpostavimo da su se \u010detiri dana aktivno stvarali backupovi, a zatim je kapacitet tir zape\u010datiran. Ne bri\u0161emo ni\u0161ta, ve\u0107 strpljivo do\u010dekujemo reteniciju, nakon \u010dega bri\u0161emo podatke s kapacitetnog tira.<\/p>\n<p>Otprilike isto se doga\u0111a u move mode \u2014 \u010dekamo reteniciju, bri\u0161emo stare u lokalnom skladi\u0161tu, bri\u0161emo pohranjeno u objektnoj pohrani.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZanimljiv primjer s Forever forward incremental. Postavljamo reteniciju na tri to\u010dke i po\u010dinjemo s izradom backupova u ponedjeljak, koji se redovito kopiraju u oblak. Nakon pe\u010datenja pohrane, backupovi se nastavljaju stvarati, dr\u017ee\u0107i tri to\u010dke, ali podaci pohranjeni u kapacitetnom tiru ostaju zavisni i ne mogu se obrisati. Stoga \u010dekamo \u010detvrtak, kada na\u0161 .vbk izlazi iz okvira retenicije, i tek tada mirno bri\u0161emo \u010ditav spremljeni lanac.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI mala napomena: svi primjeri ovdje prikazani su s jednim strojem. Ako imate vi\u0161e strojeva u backupu, njihova \u0107e retenicija biti razli\u010dita ovisno o tome je li napravljen Active Full ili ne.<\/p>\n<p>Na tome, u principu, zavr\u0161avamo. Tako da prelazimo na najhardkor zna\u010daj \u2014 <\/p>\n<h3>Imutabilnost <\/h3>\n<p>\nKao i s prethodnim stavkama, prvo \u0107emo objasniti koju problematiku ova funkcija rje\u0161ava. Kada sa\u010duvamo na\u0161e backupove negdje na skladi\u0161tenje, javlja se sna\u017ena potreba za njihovim o\u010duvanjem, tj. fizi\u010dki zabraniti njihovo brisanje i bilo kakve modifikacije tokom zadanog retentiona. To uklju\u010duje i administratore, \u010dak i pod njihovim root ra\u010dunima. To omogu\u0107ava za\u0161titu od slu\u010dajnog ili namjernog o\u0161te\u0107enja. Oni koji rade s AWS-om, mogli su se susresti s ovom funkcijom pod nazivom Object Lock.<\/p>\n<p>Sada \u0107emo razmotriti na\u010din rada u op\u0107im crtama, a kasnije \u0107emo se posvetiti detaljima. U na\u0161em primjeru, Immutability \u0107e biti uklju\u010den za na\u0161 capacity tier s retention periodom od \u010detiri dana. A u backupu je uklju\u010den na\u010din rada Copy.<\/p>\n<p>Immutability ne utje\u010de na op\u0107i retention. Na primjer, ne dodaje dodatne to\u010dke ili ne\u0161to sli\u010dno. Samo tokom \u010detiri dana osoba ne mo\u017ee izbrisati datoteke backupova. Ako se u ponedjeljak napravi backup, datoteku \u0107e mo\u0107i izbrisati tek u petak.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSvi ranije obja\u0161njeni koncepti dehidratacije, indeksa i metapodataka nastavljaju funkcionirati na isti na\u010din. Ali s jednim uvjetom \u2014 blok se postavlja ne samo za podatke, ve\u0107 i za metapodatke. To je u\u010dinjeno u slu\u010daju da zlo\u0107udni napada\u010d odlu\u010di obrisati na\u0161u bazu metapodataka, kako bi blokovi s podacima ostali korisni i ne pretvorili se u beskorisnu binarnu ka\u0161u.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI sada je do\u0161lo sjajno vrijeme za obja\u0161njenje na\u0161e tehnologije generiranja blokova. Ili block generation. Za ovo razmotrite situaciju koja je dovela do njenog pojavljivanja.<\/p>\n<p>Uzmimo vremensku liniju od \u0161est dana i zabilje\u017eimo vrijeme o\u010dekivanog isteka immutability na dnu. Prvog dana stvaramo datoteku koja se sastoji od bloka a i njegovih metapodataka. Ako je immutability postavljen na tri dana, logi\u010dno je pretpostaviti da \u0107e podaci biti otklju\u010dani i izbrisani \u010detvrtog dana. Drugog dana dodajemo novu datoteku file2, koja se sastoji od bloka b s istim postavkama. Blok a jo\u0161 uvijek treba biti izbrisan \u010detvrtog dana. No tre\u0107eg dana doga\u0111a se stra\u0161na stvar - stvara se datoteka File3, koja se sastoji od novog bloka d i poveznice na stari blok a. To zna\u010di da bi za blok a njegov immutability flag trebao biti ponovno postavljen na novi rok, koji se pomi\u010de na \u0161esti dan. I tu nastaje problem - u stvarnim backupovima takvih blokova nastaje ogromna koli\u010dina. A da bismo produ\u017eili njihov immutability period, potrebno je svaki put izvr\u0161iti ogromnu koli\u010dinu zahtjeva. I zapravo, to \u0107e biti gotovo beskrajan dnevni proces, jer s velikom vjerojatno\u0161\u0107u pri svakom kopiranju nalazimo velike koli\u010dine dedupliciranih blokova. A \u0161to to zna\u010di za veliki broj zahtjeva kod pru\u017eatelja usluga objektnog pohranjivanja? To\u010dno! Ogroman ra\u010dun na kraju mjeseca.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI kako ne bismo svoje omiljene klijente na ravnom mjestu izlo\u017eili velikim tro\u0161kovima, izmi\u0161ljen je mehanizam generiranja blokova. To je dodatno razdoblje koje dodajemo na postavljen period immutability. U donjem primjeru to razdoblje iznosi dva dana. No to je samo za primjer. U stvarnosti se koristi vlastita formula koja daje otprilike deset dodatnih dana uz mjese\u010dni lok. <\/p>\n<p>Nastavimo razmatrati istu situaciju, ali sada s generacijom blokova. U prvom danu kreiramo file1 iz bloka a i metapodataka. Skupljamo razdoblje generacije i nepromjenjivost \u2014 to zna\u010di da \u0107e mogu\u0107nost brisanja datoteke biti na \u0161esti dan. Ako drugog dana stvorimo File2, koji se sastoji od bloka b i reference na blok a, tada se o\u010dekivani datum brisanja ne mijenja. On ostaje na \u0161estom danu. Pri tome nastojimo u\u0161tedjeti novac na broju upita. Jedina situacija kada rok mo\u017ee biti pomaknut je ako je razdoblje generacije isteklo. Drugim rije\u010dima, ako tre\u0107eg dana novi File3 sadr\u017ei referencu na blok a, tada \u0107e biti dodana generacija 2 jer je Gen1 ve\u0107 istekao. O\u010dekivani datum brisanja bloka a pomaknut \u0107e se na osmi dan. To nam omogu\u0107uje drasti\u010dno smanjenje broja upita za produ\u017eenje vremena \u017eivota dedupliranih blokova, \u0161to \u0161tedi puno novca klijentima.<\/p>\n<p><img decoding=\"async\" alt=\"\u0160to se promijenilo u Capacity Tier kada je Veeam postao v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSama tehnologija dostupna je korisnicima S3 i S3-kompatibilnog hardvera, \u010diji proizvo\u0111a\u010di jam\u010de da se njihova implementacija ne razlikuje od Amazonove. O \u043e\u0442\u0441\u0443\u0434\u043d\u043e, odgovor na legitimno pitanje za\u0161to Azure nije podr\u017ean \u2014 oni imaju sli\u010dnu funkciju, ali ona radi na razini kontejnera, a ne pojedina\u010dnih objekata. Usput, u samom Amazonu objekt lock ima dva na\u010dina rada: compliance i governance. U drugom slu\u010daju ostaje mogu\u0107nost da najmo\u0107niji administrator ili root korisnik, unato\u010d objekt lock-u, ipak izbri\u0161e podatke. U slu\u010daju compliance, sve je \u010dvrsto u\u010dvr\u0161\u0107eno i nitko, \u010dak ni administratori Amazona (prema njihovim slu\u017ebenim izjavama), ne mogu izbrisati sigurnosne kopije. Mi podr\u017eavamo upravo ovaj na\u010din.<\/p>\n<p>\nI, tradicionalno, malo korisnih linkova:<\/p>\n<ul>\n<li>O <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Generacija blokova<\/a><\/noindex> u svim detaljima.<\/li>\n<li>Sve informacije o <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> u najboljem svjetlu<\/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> u detaljima<\/li>\n<\/ul>\n<p>Izvor: <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.4 - 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\/hr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\/hr\/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\udd47\u0160to se promijenilo u Capacity Tier-u kada je Veeam postao v10 | ProHoster","description":"Capacity Tier (ili kako ga mi nazivamo unutar na\u0161ih Veeam \u2014 kaptir) pojavio se jo\u0161 u doba Veeam Backup and Replication 9.5 Update 4 pod imenom Archive Tier.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/84809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}