{"id":97729,"date":"2020-10-21T08:42:22","date_gmt":"2020-10-21T06:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving"},"modified":"2020-10-21T08:42:22","modified_gmt":"2020-10-21T06:42:22","slug":"otkuda-berutsya-logi-veeam-log-diving","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Odakle dolaze logovi? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Odakle<\/p>\n

Nadaljujemo z na\u0161im potopom v zanimiv svet te\u017eavskega re\u0161evanja po dnevnikih. V prej\u0161njem \u010dlanku<\/a><\/noindex> smo se dogovorili o pomenu osnovnih izrazov in z enim o\u010desom pogledali na splo\u0161no strukturo Veeam, kot enotne aplikacije. Naloga na to temo je razumeti, kako se oblikujejo dnevni\u0161ke datoteke, katera informacija je v njih prikazana in zakaj izgledajo tako, kot izgledajo.<\/p>\n

Kaj menite, kaj sploh so ti \"dnevniki\"? Po mnenju ve\u010dine naj bi dnevnikom vsake aplikacije pripadala vloga nekak\u0161ne vsemogo\u010dne entitete, ki ve\u010dino \u010dasa pre\u017eivi nekje na obrobju, a se v pravem trenutku pojavi iz ni\u010d v sijo\u010dih oklepih in vse re\u0161i. To pomeni, da naj bi v njih bilo vse, od najmanj\u0161ih napak v vsakem komponentu do posameznih transakcij baze. In da bi se po napaki takoj zapisalo, kako jo popraviti. In vse to bi se moralo prilegati v nekaj megabajtov, najve\u010d. To je pa\u010d samo besedilo! Zelo napolnjeni besedilni dokumenti ne morejo zasedati ve\u010d deset gigabajtov, nekje sem to sli\u0161al!<\/p>\n

Torej, dnevniki<\/h2>\n

V resni\u010dnem svetu so dnevniki le arhiv diagnosti\u010dnih informacij. In kaj tam shraniti, od kje dobiti informacije za shranjevanje in kako podrobne naj bodo, se odlo\u010dijo sami razvijalci. Nekateri gredo po poti minimalizma in shranjujejo zapise na nivoju VKLOP\/IZKLOP, drugi pa skrbno zbirajo vse, kar lahko dose\u017eejo. Obstaja tudi vmesna mo\u017enost z mo\u017enostjo izbire tako imenovane ravni bele\u017eenja, kjer sami dolo\u010dite, koliko podrobnih informacij \u017eelite shraniti in koliko imate odve\u010dnega prostora na diskih =) Pri VBR je teh nivojev kar \u0161est, mimogrede. In, verjemite, no\u010dete videti, kaj se dogaja pri najpodrobnej\u0161em bele\u017eenju s prostim prostorom na va\u0161em disku.<\/p>\n

Dobro. Pribli\u017eno smo razumeli, kaj \u017eelimo shraniti, a se postavlja zakonito vpra\u0161anje: kje dobiti te informacije? Del dogodkov za dnevnik, seveda, oblikujemo sami z na\u0161imi notranjimi procesi. Ampak kaj storiti, ko pride do interakcije z zunanjim okoljem? Da se ne bi zna\u0161li v peklenski zmedi popravkov in re\u0161itev, ima Veeam tendenco, da ne izmi\u0161lja \u017ee izumljenih izumov. Vedno, ko je \u017ee na voljo API, vgrajena funkcija v sistemu, knji\u017enica itd., dajemo prednost pripravljenim re\u0161itvam, preden za\u010dnemo graditi svoje zapletene re\u0161itve. \u010ceprav jih je tudi kar nekaj. Zato je pri analizi dnevnikov pomembno razumeti, da ve\u010dina napak izhaja iz sporo\u010dil tretjih API-jev, sistemskih klicev in drugih knji\u017enic. V tem primeru se vloga VBR zmanj\u0161uje na posredovanje teh napak v dnevni\u0161ke datoteke tak\u0161ne, kot so. Glavna naloga uporabnika je, da se nau\u010di razumeti, katera vrstica je od koga in za kaj ta \"kdor\" odgovarja. Zato, \u010de vas koda napake iz dnevnika VBR pripelje na stran MSDN, je to normalno in pravilno.<\/p>\n

Kot smo se dogovorili prej: Veeam je tako imenovana aplikacija, ki temelji na SQL. To pomeni, da so vse nastavitve, vse informacije in sploh vse, kar je potrebno za normalno delovanje, shranjene v njegovi bazi. Od tod enostavna resnica: kar ni v dnevnikih, je verjetno v bazi. Vendar to \u0161e ni \u010dude\u017ena re\u0161itev: nekaterih stvari ni ne v lokalnih dnevnikih komponent Veeam ne v njegovi bazi. Zato se je treba nau\u010diti preu\u010devati dnevnike gostitelja, dnevnike lokalnega ra\u010dunalnika in dnevnike vsega, kar sodeluje v postopku varnostnega kopiranja in restavracije. V\u010dasih pa so nujne informacije povsem odsotne. Tak\u0161na je pot. <\/p>\n

Nekoliko primera takvih API-ja<\/h4>\n

Ta seznam si ne prizadeva biti izjemno popoln, zato ga ni potrebno obravnavati kot dokon\u010dno resnico. Njegova naloga je le prikazati najpogostej\u0161e stranske API-je in tehnologije, ki se uporabljajo v na\u0161ih izdelkih.<\/p>\n

Po\u010de\u0107emo sa VMware<\/strong>. <\/p>\n

Prvi na listi bi\u0107e vSphere API<\/strong>. Uporablja se za avtentikacijo, branje hierarhije, ustvarjanje in brisanje posnetkov, poizvedovanje o napravah in \u0161e marsi\u010dem (zelo veliko) drugem. Funkcionalnost re\u0161itve je zelo \u0161iroka, zato vsem, ki jih zanima, priporo\u010dam VMware vSphere API Reference za razli\u010dico 5.5<\/u><\/a><\/noindex> in 6.0<\/u><\/a><\/noindex>. Za aktuelnije verzije sve se lako prona\u0111e na Google-u.<\/p>\n

VIX API<\/strong>. \u010crna magija hipervizorja, za katero obstaja poseben seznam napak<\/u><\/a><\/noindex>. VMware API za delo s datotekami na gostitelju brez povezave z njimi po omre\u017eju. Zadnja mo\u017enost, ko je treba datoteko poslati na stroj, do katerega ni bolj\u0161ega kanala za povezavo. Predstavlja bole\u010dine in trpljenje, \u010de je datoteka velika, gostitelj pa obremenjen. A tu velja pravilo, da je celo 56,6 Kb\/s bolj\u0161e kot 0 Kb\/s. V Hyper-V se ta opcija imenuje PowerShell Direct. A to je bilo samo do prihoda<\/p>\n

vSphere Web Services API<\/strong> Od vSphere 6.0 naprej (pribli\u017eno, ker je bil ta API prvi\u010d predstavljen v razli\u010dici 5.5) se uporablja za delo s gostujo\u010dimi stroji in je \u017ee skoraj povsod nadomestil VIX. V bistvu je to \u0161e en API za upravljanje z vSphere. Tistim, ki jih zanima, lahko priporo\u010dam, da se seznanijo z odli\u010dnim<\/u><\/a><\/noindex> ro\u010dno knjigo. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Knji\u017enica, o kateri se je delno govorilo v tem \u010dlanku<\/u><\/a><\/noindex>. Uporablja se za branje virtualnih diskov. Pred \u010dasom je bila del VIX, vendar je bila s\u010dasoma izdvojena v samostojen izdelek. Tako kot njen naslednik uporablja iste kode napak kot VIX. Toda iz nekega razloga v samem SDK ni nobenega opisa teh napak. Zato je bilo s preizku\u0161anjem ugotovljeno, da napake VDDK z drugimi kodami predstavljajo le prevod iz binarne v decimalno kodo. Sestavljena je iz dveh delov \u2013 prvi del predstavlja nedokumentirane informacije o kontekstu, drugi del pa so klasi\u010dne VIX\/VDDK napake. Na primer, \u010de vidimo:<\/p>\n

VDDK error: 21036749815809.Unknown error<\/code><\/p>\n

Potem to preprosto pretvorimo v hex in dobimo 132200000001. Nepodaten za\u010detek 132200 preprosto odlo\u017eimo, preostali del pa bo na\u0161a koda napake (VDDK 1: Neznana napaka). O najpogostej\u0161ih VDDK napakah je bila pred kratkim objavljena posebna \u010dlanek<\/u><\/a><\/noindex>.<\/p>\n

Zdaj poglejmo na Windows<\/strong>. <\/p>\n

Tukaj lahko najdete vse, kar potrebujete in je pomembno za nas, v standardnem Event Viewer<\/strong>. Vendar pa obstaja ena te\u017eava: po stari tradiciji Windows bele\u017ei nepopoln besedilni opis napake, temve\u010d le njen \u0161tevil\u010dni zapis. Na primer, napaka 5 je \"Dostop zavrnjen\", napaka 1722 pa je \"RPC stre\u017enik ni na voljo\", in 10060 je \"Povezava je potekla\". Seveda je dobro, \u010de se spomni\u0161 najbolj znanih, toda kako biti z doslej nevidenimi? <\/p>\n

In order to not make life feel too sweet, errors are also stored in hexadecimal form, prefixed with 0x8007. For example, 0x8007000e \u2014 this actually means 14, Out of Memory. The reason and purpose of this is a mystery. However, a complete list of errors can be downloaded for free without SMS from the development center<\/u><\/a><\/noindex>.<\/p>\n

By the way, sometimes there are other prefixes besides 0x8007. In such unfortunate situations, to understand HRESULT (\u201cresult handle\u201d), you need to delve even deeper into dokumentacijo<\/u><\/a><\/noindex> for developers. In everyday life, I wouldn't advise you to do this, but if you find yourself backed into a corner or just curious, now you know what to do.<\/p>\n

But the folks at Microsoft have shown some compassion and introduced a utility ERR<\/u><\/a><\/noindex>. This is a small piece of console happiness that can translate error codes into human-readable language without using Google. It works approximately like this.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# for hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# An internal error occurred.\n# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f\n# for hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# An internal error occurred.\n# 2 matches found for \"0x54f\"<\/code><\/pre>\n
A legitimate question arises: why do we not write the interpretation in the logs immediately and leave these mysterious codes? The answer lies in third-party applications. When you call a WinAPI function yourself, decoding its response is easy because there is even a special WinAPI call for that. But as mentioned earlier, our logs contain everything that comes to us in responses. For deciphering, we would need to constantly monitor this stream of consciousness, extract pieces with Windows errors, decode them and insert them back. Let's be honest, it's not the most thrilling task.<\/p>\n
Windows File Management API <\/strong>is used in various ways when working with files. Creating files, deleting them, opening them for writing, managing attributes, and much more.<\/p>\n
The aforementioned PowerShell Direct<\/strong> serves as an analogue of the VIX API in the world of Hyper-V. Unfortunately, it's not as flexible: it comes with a lot of functional limitations, doesn't work with every version of the host, and far from all guests.<\/p>\n
RPC<\/strong> (Remote Procedure Call) I believe there is not a single person who has worked with Windows who hasn't encountered RPC-related errors. Contrary to popular belief, it is not a single protocol, but any client-server protocol that satisfies a set of parameters. However, if we see an RPC error in our logs, in 90% of cases, it will be an error from Microsoft RPC, which is part of DCOM (Distributed Component Object Model). There is a vast amount of documentation on this topic online, although much of it is quite outdated. But if there's a strong desire to study the subject, I can recommend articles \u0160ta je RPC?<\/u><\/a><\/noindex>, Kako RPC funkcioni\u0161e<\/u> <\/a><\/noindex>i duga\u010dak spisak RPC gre\u0161aka<\/u><\/a><\/noindex>.<\/p>\n
The primary causes of RPC errors in our logs are failed attempts at interaction between VBR components (server > proxy, for example), and most often due to communication issues.<\/p>\n
The top error among all is The RPC server is unavailable (1722). In simple terms, the client could not establish a connection to the server. There is no definitive answer as to why, but usually, it's a problem with authentication or network access to port 135. The latter is characteristic of infrastructures with dynamically assigned ports. There is even material on this topic. posebna KB<\/u><\/a><\/noindex>. And from Microsoft \u2014 opse\u017ean vodi\u010d<\/u><\/a><\/noindex> o pronala\u017eenju uzroka kvara.<\/p>\n
Druga najpopularnija gre\u0161ka: There are no more endpoints available from the endpoint mapper (1753). RPC klijent ili server nisu mogli dodeliti port. Obi\u010dno se javlja kada je server (u na\u0161em slu\u010daju gost ma\u0161ina) bio pode\u0161en na dinami\u010dko dodeljivanje portova iz uskog opsega koji je istekao. A ako se gleda sa strane klijenta (u na\u0161em slu\u010daju VBR servera), to zna\u010di da na\u0161 VeeamVssAgent ili nije pokrenut, ili nije registrovan kao RPC interfejs. Na ovu temu tako\u0111e postoji posebna KB<\/u><\/a><\/noindex>.<\/p>\n
I da zavr\u0161imo Top-3 RPC gre\u0161ke, prisetimo se RPC function call failed (1726). Pojavljuje se ako je veza uspostavljena, ali RPC zahtevi ne funkcioni\u0161u. Na primer, tra\u017eimo informacije o statusu VSS (mo\u017eda se upravo sada pravi shadow copy, a mi poku\u0161avamo da pristupimo), a u odgovoru nam dolazi ti\u0161ina i ignorisanje.<\/p>\n
Windows Tape Backup API <\/strong>potrebno za rad s trakastim bibliotekama ili pogonima. Kao \u0161to sam spomenuo na po\u010detku: pisanje vlastitih drajvera i mu\u010denje sa podr\u0161kom za svaki ure\u0111aj nam nikako nije zadovoljstvo. Zato Veeam nema svoje drajvere. Sve ide preko standardnog API-ja, \u010diju podr\u0161ku ostvaruju sami dobavlja\u010di hardvera. Tako da zapravo ima mnogo vi\u0161e smisla, zar ne?<\/p>\n
SMB\/CIFS<\/strong> Everyone tends to write them next to each other, although not everyone remembers that CIFS (Common Internet File System) is just a private version of SMB (Server Message Block). So there's nothing wrong with generalizing these concepts. Samba is the Linux\/Unix implementation, which has its own peculiarities, but I digress. What's important here is that when Veeam requests to write something along the UNC path (serverdirectory), the server uses the hierarchy of file system drivers, including mup and mrxsmb, to write to the share. Accordingly, these drivers will also generate errors.<\/p>\n
Ne mo\u017ee se pro\u0107i bez Winsock API<\/strong>. Ako se ne\u0161to treba uraditi putem mre\u017ee, VBR radi preko Windows Socket API-ja, poznatijeg kao Winsock. Tako da, ako vidimo u logu vezu IP:Port, to je to. U slu\u017ebenoj dokumentaciji postoji dobar spisak mogu\u0107ih chyb<\/u><\/a><\/noindex>.<\/p>\n
The aforementioned WMI<\/strong> (Windows Management Instrumentation) \u2014 to je nekak\u0161en vseobsegajo\u010d API za upravljanje vsega in vseh v svetu Windows. Na primer, pri delu s Hyper-V se skoraj vsi zahteve do gostitelja izvajajo prav preko njega. Skratka, gre za popolnoma nezamenljivo in izjemno mo\u010dno orodje. Pri poskusih ugotoviti, kje in kaj je odpovedalo, v veliki meri pomaga vgrajeno orodje WBEMtest.exe.<\/p>\n
In zadnji na seznamu, a nikakor ne manj pomemben \u2014 VSS<\/strong> (Volume Shadow Storage). Tema je toliko neiscrpna i misteriozna koliko je i mnogo o njoj napisano dokumentacije. Shadow Copy se najlak\u0161e razume kao posebna vrsta snimka, kojim zapravo i jeste. Zahvaljuju\u0107i njemu, u VMware-u je mogu\u0107e raditi aplikacijski konzistentne bekape, a u Hyper-V-u \u010dak gotovo sve. Imam plan da napi\u0161em poseban \u010dlanak s nekim sa\u017eetkom o VSS-u, ali za sada mo\u017eete poku\u0161ati pro\u010ditati ovo opis<\/u><\/a><\/noindex>. Samo budite oprezni, jer poku\u0161aj razumevanja VSS-a na brzinu mo\u017ee dovesti do povreda mozga.<\/p>\n
Na tome, mislim da mo\u017eemo stati. Smatram da je zadatak obja\u0161njenja najosnovnijih stvari ispunjen, tako da u slede\u0107em poglavlju ve\u0107 \u0107emo gledati logove. Ali ako imate pitanja, slobodno ih postavite u komentarima.<\/p>\n<\/p>\n
Izvor: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d… \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433\u0430 \u043f\u043e \u043b\u043e\u0433\u0430\u043c. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0434\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438\u0441\u044c \u043e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0438 \u0431\u0430\u0437\u043e\u0432\u044b\u0445 \u0442\u0435\u0440\u043c\u0438\u043d\u043e\u0432 \u0438 \u043e\u0434\u043d\u0438\u043c \u0433\u043b\u0430\u0437\u043a\u043e\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043e\u0431\u0449\u0443\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 Veeam, \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0417\u0430\u0434\u0430\u0447\u0430 \u043d\u0430 \u044d\u0442\u0443 — \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f \u043b\u043e\u0433 \u0444\u0430\u0439\u043b\u044b, \u0447\u0442\u043e \u0437\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0432 \u043d\u0438\u0445 \u043e\u0442\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0430 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442 \u043a\u0430\u043a \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442. \u041a\u0430\u043a \u0432\u044b \u0434\u0443\u043c\u0430\u0435\u0442\u0435, \u0447\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97730,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97729","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Odkod prihajajo dnevniku? Veeam Log Diving | ProHoster","description":"Nadaljujemo z na\u0161im potopom v fascinanten svet ugibanj...","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\u041e\u0442\u043a\u0443\u0434\u0430 \u0431\u0435\u0440\u0443\u0442\u0441\u044f \u043b\u043e\u0433\u0438? Veeam Log Diving | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d...","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","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-10-21T06:42:22+00:00","article:modified_time":"2020-10-21T06:42:22+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97729","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 10:14:39","updated":"2022-09-30 13:30:55","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}