{"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\/nl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Waar komen de logs vandaan? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Waar<\/p>\n

We blijven duiken in de fascinerende wereld van troubleshooting via logs. In vorig artikel<\/a><\/noindex> we hebben de betekenis van basisbegrippen besproken en hebben een blik geworpen op de algehele structuur van Veeam als een enkele applicatie. De taak nu is om te begrijpen hoe logbestanden worden gevormd, welke informatie erin wordt weergegeven en waarom ze eruitzien zoals ze eruitzien.<\/p>\n

Wat denkt u, wat zijn deze 'logs' eigenlijk? Volgens velen zouden de logs van elke applicatie de rol moeten hebben van een almachtige entiteit die het grootste deel van de tijd ergens op de achtergrond verblijft, maar op het juiste moment uit het niets verschijnt in glanzende harnassen en iedereen redt. Dat wil zeggen, ze zouden alles moeten bevatten, van de kleinste fouten in elk onderdeel tot afzonderlijke transacties van de database. En na een fout zou er meteen moeten worden genoteerd hoe deze te verhelpen. En dit alles moet in een paar megabytes passen, niet meer. Het is tenslotte maar tekst! Tekstbestanden kunnen geen tientallen gigabytes groot zijn, dat heb ik ergens gehoord!<\/p>\n

So, logs<\/h2>\n

In the real world, logs are merely an archive of diagnostic information. Deciding what to store, where to obtain the information for storage, and how detailed it should be is up to the developers themselves. Some take the minimalist approach, storing only ON\/OFF level records, while others diligently gather everything they can reach. There's also an intermediate option with the ability to select the so-called Logging Level, where you specify how detailed the information you want to store is and how much extra space you have on your disks. VBR has six such levels, by the way. And believe me, you don\u2019t want to see what happens during maximum detailed logging when there is free space on your disk.<\/p>\n

Goed. We hebben ongeveer begrepen wat we willen opslaan, maar de legitieme vraag rijst: waar halen we deze informatie vandaan? Een deel van de gebeurtenissen voor logging worden natuurlijk door ons zelf gevormd via onze interne processen. Maar wat te doen wanneer er interactie is met een externe omgeving? Om niet in de duistere chaos van haperende en zelfgebouwde oplossingen te belanden, heeft Veeam de neiging om geen al uitgevonden uitvindingen opnieuw uit te vinden. Altijd wanneer er al een werkende API, een ingebouwde functie in het systeem, een bibliotheek, enz. beschikbaar is, geven we de voorkeur aan de kant-en-klare opties voordat we beginnen met het bouwen van onze eigen slimme oplossingen. Hoewel er daarvan ook genoeg zijn. Daarom is het belangrijk om bij het analyseren van logs te begrijpen dat een groot deel van de fouten afkomstig is van berichten van externe API's, systeemaanroepen en andere bibliotheken. In dit geval is de rol van VBR het doorsturen van deze fouten naar de logbestanden zoals ze zijn. De belangrijkste taak van de gebruiker is te leren begrijpen welke regel van wie komt, en waarvoor deze 'wie' verantwoordelijk is. Daarom is het normaal en correct als een foutcode uit de VBR-log u naar een pagina op MSDN leidt.<\/p>\n

Zoals eerder afgesproken: Veeam is een zogenaamd SQL-based applicatie. Dit betekent dat alle instellingen, alle informatie en eigenlijk alles wat nodig is voor een normale werking, wordt opgeslagen in zijn database. Hieruit volgt een eenvoudige waarheid: wat niet in de logs staat, staat waarschijnlijk in de database. Maar dit is geen wondermiddel: sommige dingen staan noch in de lokale logs van de Veeam-componenten, noch in zijn database. Daarom moet je leren de logs van de host, de logs van de lokale machine en de logs van alles wat betrokken is bij het backup- en herstelproces te bestuderen. En soms is de benodigde informatie helemaal nergens te vinden. Dat is de realiteit. <\/p>\n

Enkele voorbeelden van dergelijke API's<\/h4>\n

Deze lijst heeft niet de ambitie om volledig te zijn, dus zoek er niet naar de ultieme waarheid. Het doel ervan is slechts om de meest voorkomende externe API's en technologie\u00ebn te tonen die in onze producten worden gebruikt.<\/p>\n

Laten we beginnen met VMware<\/strong>. <\/p>\n

De eerste in de lijst zal zijn vSphere API<\/strong>. Wordt gebruikt voor authenticatie, het lezen van hi\u00ebrarchie\u00ebn, het maken en verwijderen van snapshots, het opvragen van informatie over machines en nog veel (erg veel) ander. De functionaliteit van de oplossing is zeer breed, dus ik kan iedereen die ge\u00efnteresseerd is aanraden om de   VMware vSphere API Reference voor versie 5.5<\/u><\/a><\/noindex> en 6.0<\/u><\/a><\/noindex>. Voor de meer actuele versies is alles eenvoudig te vinden via Google.<\/p>\n

VIX API<\/strong>. Zwarte magie van de hypervisor, waarvoor er een aparte foutenlijst<\/u><\/a><\/noindex>. VMware API voor het werken met bestanden op de host zonder deze via het netwerk te verbinden. Een laatste redmiddel wanneer je een bestand op een machine moet plaatsen waarvoor er geen betere verbinding meer mogelijk is. Het zorgt voor veel pijn en lijden als het bestand groot is en de host druk bezet. Maar er geldt de regel dat zelfs 56,6 Kb\/s beter is dan 0 Kb\/s. In Hyper-V wordt een soortgelijk iets PowerShell Direct genoemd. Maar dat was alleen zo tot de komst van<\/p>\n

vSphere Web Services API<\/strong> . Sinds vSphere 6.0 (ongeveer, aangezien dit API voor het eerst werd gepresenteerd in versie 5.5) wordt het gebruikt voor het werken met gastmachines en heeft het VIX praktisch overal verdrongen. In wezen is dit weer een API voor het beheren van vSphere. Voor ge\u00efnteresseerden kan ik aanraden om de uitstekende<\/u><\/a><\/noindex> handleiding te bestuderen. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Een bibliotheek waar deels in dit document omheen werd gesproken. Het wordt gebruikt voor het lezen van virtuele schijven. Vroeger maakte het deel uit van VIX, maar met de tijd is het in een apart product geplaatst. Als erfgenaam gebruikt het echter dezelfde foutcodes als VIX. Maar om een of andere reden staat er in de SDK zelf geen beschrijving van deze fouten. Daarom is door middel van ervaring vastgesteld dat VDDK-fouten met andere codes slechts een vertaling zijn van binaire naar decimale code. Het bestaat uit twee delen \u2013 de eerste helft bevat niet-gedocumenteerde informatie over de context, en de tweede helft zijn de traditionele VIX\/VDDK-fouten. Bijvoorbeeld, als we zien: artikel<\/u><\/a><\/noindex>. Wordt gebruikt voor het lezen van virtuele schijven. Vroeger was het onderdeel van VIX, maar is in de loop van de tijd in een apart product geplaatst. Als rechtmatige opvolger gebruikt het echter dezelfde foutcodes als VIX.  Maar om de een of andere reden bevat de SDK zelf geen beschrijving van deze fouten. Daarom is door ervaring vastgesteld dat VDDK-fouten met andere codes gewoon een vertaling zijn van binaire naar decimale code. Het bestaat uit twee delen - de eerste helft bevat niet gedocumenteerde informatie over de context, terwijl de tweede helft de traditionele VIX\/VDDK-fouten zijn. Bijvoorbeeld, als we zien:<\/p>\n

Dan converteren we dit gerust naar hex en krijgen we 132200000001. Het niet-informatieve begin 132200 laten we gewoon vallen, en de rest zal onze foutcode zijn (VDDK 1: Onbekende fout). Onlangs was er een aparte<\/code><\/p>\n

Dan converteren we dit zonder aarzeling naar hex en krijgen we 132200000001. Het oninformatieve begin 132200 laten we gewoon weg, en de rest zal onze foutcode zijn (VDDK 1: Onbekende fout). Onlangs was er net een aparte artikel<\/u><\/a><\/noindex>.<\/p>\n

Windows Hier is alles wat we nodig hebben en belangrijk is te vinden in de standaard<\/strong>. <\/p>\n

Event Viewer . Maar er is \u00e9\u00e9n probleem: volgens een oude traditie logt Windows niet de volledige fouttekst, maar alleen het nummer. Bijvoorbeeld, fout 5 is \u2018Toegang geweigerd\u2019, en 1722 is \u2018De RPC-server is niet beschikbaar\u2019, en 10060 is \u2018De verbinding is verlopen\u2019. Natuurlijk is het geweldig als je de meest bekende codes onthoudt, maar hoe zit het met tot nu toe ongeziene fouten?<\/strong>. Maar er is \u00e9\u00e9n probleem: volgens de oude traditie logt Windows niet de volledige fouttekst, maar alleen het nummer ervan. Bijvoorbeeld, fout 5 is 'Toegang geweigerd', fout 1722 is 'De RPC-server is niet beschikbaar', en 10060 is 'Verbindingstime-out'. Natuurlijk is het geweldig als je de meest bekende fouten herinnert, maar wat te doen met tot nu toe onbekenden? <\/p>\n

En om het leven niet al te zoet te maken, worden fouten ook nog eens in hexadecimale vorm opgeslagen, met het voorvoegsel 0x8007. Bijvoorbeeld, 0x8007000e - dat is eigenlijk 14, Out of Memory. Waarom en voor wie dit zo is gedaan - blijft een mysterie. Echter, de volledige lijst met fouten kan gratis en zonder sms worden gedownload van de devcentra<\/u><\/a><\/noindex>.<\/p>\n

Overigens komen er soms ook andere prefixes voor, en niet alleen 0x8007. In zo'n trieste situatie moet je nog dieper graven om HRESULT (\"result handle\") te begrijpen documentatie<\/u><\/a><\/noindex> voor ontwikkelaars. In het dagelijks leven raad ik je aan om dit niet te doen, maar als je echt in de knel zit of gewoon nieuwsgierig bent, weet je nu wat je moet doen.<\/p>\n

Maar de vrienden bij Microsoft hebben ons een beetje genade getoond en presenteerden de utility ERR<\/u><\/a><\/noindex>. Dit is een klein stukje consolegeluk dat foutcodes naar menselijk leesbare tekst kan vertalen zonder Google. Het werkt ongeveer zo.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# voor hex 0x54f \/ decimaal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Een interne fout is opgetreden.\n# als een HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f\n# voor hex 0x54f \/ decimaal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Een interne fout is opgetreden.\n# 2 overeenkomsten gevonden voor \"0x54f\"<\/code><\/pre>\n
Er rijst een legitieme vraag: waarom schrijven we de verklaring niet meteen in de logs, maar laten we deze mysterieuze codes staan? Het antwoord ligt in externe applicaties. Wanneer je zelf een WinAPI-aanroep doet, is het niet moeilijk om de respons ervan te ontcijferen, want er is al een speciale WinAPI-aanroep voor. Maar zoals al gezegd, komt alles wat in de antwoorden naar ons toe komt in onze logs terecht. En voor het ontcijferen hiervan zou je constant deze stroom van bewustzijn moeten monitoren, stukken met Windows-fouten eruit moeten filteren, deze moeten ontcijferen en weer terug moeten invoegen. Laten we eerlijk zijn, het is geen boeiende bezigheid.<\/p>\n
Windows File Management API <\/strong>wordt op verschillende manieren gebruikt bij het werken met bestanden. Het aanmaken van bestanden, verwijderen, openen voor schrijven, werken met attributen, en nog veel meer.<\/p>\n
De eerder genoemde PowerShell Direct<\/strong> is vergelijkbaar met de VIX API in de wereld van Hyper-V. Helaas is het niet zo flexibel: er zijn veel functionele beperkingen, het werkt niet met elke versie van de host en zeker niet met alle gasten.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Ik denk niet dat er iemand is die met Windows heeft gewerkt en nog nooit fouten met RPC heeft gezien. Ondanks de populaire misvatting is dit geen enkele protocol, maar ieder client-serverprotocol dat aan bepaalde parameters voldoet. Echter, als we een RPC-fout in onze logs zien, is dit in 90% van de gevallen een fout van Microsoft RPC, dat onderdeel is van DCOM (Distributed Component Object Model).  Er is een enorme hoeveelheid documentatie over dit onderwerp beschikbaar, maar het merendeel ervan is behoorlijk verouderd. Maar als er een sterke wens is om het onderwerp te bestuderen, kan ik de artikelen aanbevelen Wat is RPC?<\/u><\/a><\/noindex>, Hoe werkt RPC<\/u> <\/a><\/noindex>en een lange lijst van RPC-fouten<\/u><\/a><\/noindex>.<\/p>\n
De belangrijkste oorzaken van RPC-fouten in onze logs zijn mislukkingen in de interactie tussen de VBR-componenten (server > proxy, bijvoorbeeld) en het komt meestal door verbindingsproblemen.<\/p>\n
De topfout onder alle fouten is de fout The RPC server is unavailable (1722). Eenvoudig gezegd, de client kon geen verbinding maken met de server. Waarom en hoe - er is geen eenduidig antwoord, maar meestal is het een probleem met authenticatie of met netwerktoegang tot poort 135. Dit laatste is kenmerkend voor infrastructuren met dynamische poorttoewijzing. hierover is er zelfs specifieke KB<\/u><\/a><\/noindex>. En bij Microsoft - uitgebreide gids<\/u><\/a><\/noindex> voor het vinden van de oorzaken van de storing.<\/p>\n
De op \u00e9\u00e9n na meest voorkomende fout: There are no more endpoints available from the endpoint mapper (1753). De RPC-client of server kon geen poort toewijzen. Dit gebeurt meestal wanneer de server (in ons geval de gastmachine) is ingesteld op dynamische poorten uit een beperkt bereik, dat vol is. En als we vanuit de clientzijde (in ons geval de VBR-server) kijken, betekent dit dat onze VeeamVssAgent of niet is gestart, of niet is geregistreerd als RPC-interface. Ook over dit onderwerp is er specifieke KB<\/u><\/a><\/noindex>.<\/p>\n
En om de top 3 RPC-fouten af te ronden, herinneren we ons de RPC function call failed (1726). Dit verschijnt als de verbinding is gemaakt, maar de RPC-verzoeken niet worden verwerkt. Bijvoorbeeld, we vragen om informatie over de status van VSS (misschien wordt er op dat moment een schaduwkopie gemaakt), maar we krijgen stilte en negeren als antwoord.<\/p>\n
Windows Tape Backup API <\/strong>is nodig voor het werken met tape bibliotheken of drives. Zoals ik aan het begin al zei: het schrijven van je eigen drivers en daarna worstelen met de ondersteuning van elk apparaat geeft ons absoluut geen plezier. Daarom heeft Veeam geen eigen drivers. Alles gaat via de standaard API, waarvan de ondersteuning door de hardwareleveranciers zelf wordt gerealiseerd. Dat is veel logischer, toch?<\/p>\n
SMB\/CIFS<\/strong> Iedereen heeft de gewoonte om ze naast elkaar te schrijven, hoewel niet iedereen zich herinnert dat CIFS (Common Internet File System) gewoon een particuliere versie van SMB (Server Message Block) is. Er is dus niets verkeerd aan het generaliseren van deze concepten. Samba is al een Linux\/Unix-implementatie en heeft zijn eigen bijzonderheden, maar dat terzijde. Wat hier belangrijk is: wanneer Veeam vraagt om iets via een UNC-pad (serverdirectory) te schrijven, gebruikt de server de hi\u00ebrarchie van besturingssystemen, inclusief mup en mrxsmb, om naar het share te schrijven. Dienovereenkomstig zullen ook deze stuurprogramma's fouten genereren.<\/p>\n
Kun je absoluut niet zonder Winsock API<\/strong>. Als er iets over het netwerk moet gebeuren, werkt VBR via de Windows Socket API, die in de volksmond bekend staat als Winsock. Dus als we in de log een combinatie van IP:Port zien, dan is dat het. In de offici\u00eble documentatie is er een goede lijst van mogelijke fouten<\/u><\/a><\/noindex>.<\/p>\n
De eerder genoemde WMI<\/strong> (Windows Management Instrumentation) \u2014 een allesomvattende API voor het beheer van alles en iedereen in de wereld van Windows. Bij voorbeeld, bij het werken met Hyper-V verlopen vrijwel alle aanvragen naar de host via dit API. Kortom, een onmisbaar en krachtig hulpmiddel. Bij pogingen om te achterhalen waar en wat er mis is gegaan, is de ingebouwde tool WBEMtest.exe zeer nuttig.<\/p>\n
En de laatste op de lijst, maar zeker niet de minste \u2014 VSS<\/strong> (Volume Shadow Storage). Het onderwerp is zo onuitputtelijk en mysterieus als er documentatie over is geschreven. Shadow Copy is het gemakkelijkst te begrijpen als een soort snapshot, wat het in wezen ook is. Dankzij dit kunnen we in VMware application-consistente backups maken, en in Hyper-V eigenlijk bijna alles. Ik ben van plan een apart artikel te maken met een soort samenvatting over VSS, maar tot nu toe kun je proberen deze beschrijving<\/u><\/a><\/noindex>. Wees alleen voorzichtig, want de poging om VSS in \u00e9\u00e9n klap te begrijpen kan leiden tot hersentrauma.<\/p>\n
Laten we hier maar mee stoppen. Ik beschouw de taak om de meest basale zaken uit te leggen als voltooid, dus in het volgende hoofdstuk zullen we naar de logs kijken. Maar als je nog vragen hebt, aarzel dan niet ze in de reacties te stellen.<\/p>\n<\/p>\n
Bron: 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\udd47Waar komen de logs vandaan? Veeam Log Diving | ProHoster","description":"Laten we onze duik in de fascinerende wereld van het voorspellen voortzetten...","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}