{"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\/it\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Da dove provengono i registri? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Da<\/p>\n

Continuiamo il nostro viaggio nell'affascinante mondo del troubleshooting attraverso i log. In articolo precedente<\/a><\/noindex> abbiamo concordato il significato dei termini di base e abbiamo dato un'occhiata alla struttura generale di Veeam, come un'unica applicazione. Il compito per questo \u00e8 capire come vengono generati i file di log, che tipo di informazioni contengono e perch\u00e9 appaiono nel modo in cui appaiono.<\/p>\n

Cosa pensate che siano questi \"log\"? Secondo la maggior parte, ai log di qualsiasi applicazione dovrebbe essere riservato il ruolo di un'entit\u00e0 onnipotente, che per la maggior parte del tempo giace in un angolo, ma nel momento giusto appare dal nulla in una brillante armatura e salva tutti. Dovrebbero contenere tutto, dagli errori minimi in ogni componente fino a singole transazioni del database. E dopo un errore, dovrebbe essere sempre indicato come correggerlo. E tutto questo dovrebbe stare in un paio di megabyte, non di pi\u00f9. \u00c8 solo testo! Non possono i file di testo occupare decine di gigabyte, l'ho sentito da qualche parte!<\/p>\n

Quindi, i registri<\/h2>\n

Nel mondo reale, i registri sono semplicemente archivi di informazioni diagnostiche. E cosa conservare, da dove prendere le informazioni da archiviare e quanto dettagliate devono essere, spetta agli stessi sviluppatori. Alcuni seguono la strada del minimalismo, conservando registrazioni di accensione\/spegnimento, mentre altri si affannano a raccogliere tutto ci\u00f2 che possono. Anche se c'\u00e8 un'opzione intermedia che consente di scegliere il cosiddetto Livello di Logging, dove tu stesso indichi quanto dettagliate vuoi che siano le informazioni che conservi e quanto spazio extra hai sui dischi =) A proposito, VBR ha sei di questi livelli. E, credetemi, non volete vedere cosa succede con la registrazione pi\u00f9 dettagliata quando avete spazio libero sul vostro disco.<\/p>\n

Bene. Abbiamo pi\u00f9 o meno compreso cosa vogliamo conservare, ma sorge una legittima domanda: da dove prendere queste informazioni? Parte degli eventi da registrare, ovviamente, li generiamo noi stessi attraverso i nostri processi interni. Ma cosa fare quando si verifica un'interazione con l'ambiente esterno? Per non cadere in un caos assordante di soluzioni traballanti e insensate, Veeam tende a non reinventare l'acqua calda. Ogni volta che esiste gi\u00e0 un'API pronta, una funzione integrata nel sistema, una libreria, ecc., daremo la priorit\u00e0 a queste opzioni pronte prima di iniziare a costruire le nostre soluzioni ingegnose. Anche se ce ne sono molte di quelle inventate. Pertanto, durante l'analisi dei log, \u00e8 importante comprendere che la maggior parte degli errori proviene da messaggi di API esterne, chiamate di sistema e altre librerie. In questo caso, il compito di VBR \u00e8 quello di inoltrare questi errori nei file di log cos\u00ec come sono. E il compito principale dell'utente \u00e8 imparare a capire quale riga proviene da chi e per cosa risponde questo \"chi\". Quindi, se il codice errore dal log VBR ti porta a una pagina MSDN, \u00e8 normale e corretto.<\/p>\n

Come concordato in precedenza: Veeam \u00e8 un'applicazione basata su SQL. Significa che tutte le impostazioni, tutte le informazioni e tutto ci\u00f2 che \u00e8 necessario per un funzionamento normale sono tutti memorizzati nel suo database. Da qui una semplice verit\u00e0: ci\u00f2 che non si trova nei log, probabilmente \u00e8 presente nel database. Ma non \u00e8 una soluzione universale: alcune informazioni non si trovano n\u00e9 nei log locali dei componenti Veeam n\u00e9 nel suo database. Quindi \u00e8 necessario imparare a studiare i log dell'host, i log della macchina locale e i log di tutto ci\u00f2 che partecipa al processo di backup e ripristino. A volte, pu\u00f2 anche capitare che le informazioni necessarie non siano affatto disponibili. Questo \u00e8 il cammino. <\/p>\n

Alcuni esempi di tali API<\/h4>\n

Questo elenco non si propone di essere di completa esaustivit\u00e0, quindi non cercate la verit\u00e0 in ultima istanza. Il suo obiettivo \u00e8 solo mostrare le API e le tecnologie di terze parti pi\u00f9 comuni utilizzate nei nostri prodotti.<\/p>\n

Iniziamo con VMware<\/strong>. <\/p>\n

Il primo della lista sar\u00e0 vSphere API<\/strong>. Viene utilizzato per l'autenticazione, la lettura della gerarchia, la creazione e cancellazione di snapshot, la richiesta di informazioni sulle macchine e molto (molto) altro. La funzionalit\u00e0 della soluzione \u00e8 molto ampia, quindi consiglio a tutti gli interessati di consultare il VMware vSphere API Reference per la versione 5.5<\/u><\/a><\/noindex> e 6.0<\/u><\/a><\/noindex>. Per le versioni pi\u00f9 aggiornate si trova facilmente su Google.<\/p>\n

VIX API<\/strong>. Magia nera del hypervisor, per la quale esiste un elenco separato di errori<\/u><\/a><\/noindex>. VMware API per lavorare con i file sull'host senza collegamento di rete. Una soluzione di ultima istanza, quando \u00e8 necessario caricare un file su una macchina per la quale non c'\u00e8 un canale di comunicazione migliore. Si tratta di dolore e sofferenza, se il file \u00e8 grande e l'host \u00e8 sovraccarico. Ma qui vale la regola che anche 56,6 Kb\/s \u00e8 meglio di 0 Kb\/s. In Hyper-V, una cosa simile si chiama PowerShell Direct. Ma questo \u00e8 stato solo fino all'arrivo<\/p>\n

vSphere Web Services API<\/strong> A partire da vSphere 6.0 (circa, poich\u00e9 questo API \u00e8 stato presentato per la prima volta nella versione 5.5) \u00e8 utilizzato per lavorare con le macchine virtuali ed ha praticamente sostituito VIX ovunque. In effetti, \u00e8 un altro API per gestire vSphere. Consiglio a chi \u00e8 interessato di studiare eccellente<\/u><\/a><\/noindex> manuale. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Una libreria di cui si \u00e8 parlato parzialmente in questo abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer.<\/u><\/a><\/noindex>. Viene utilizzato per leggere i dischi virtuali. Una volta faceva parte di VIX, ma nel tempo \u00e8 stato estratto come prodotto separato. Tuttavia, come suo successore, utilizza gli stessi codici di errore di VIX. Ma per qualche motivo, nel SDK non c'\u00e8 alcuna descrizione di questi errori. Pertanto, \u00e8 stato scoperto empiricamente che gli errori VDDK con altri codici sono semplicemente una traduzione da codice binario a decimale. Consiste in due parti: la prima met\u00e0 rappresenta informazioni non documentate sul contesto, mentre la seconda parte contiene gli errori tradizionali di VIX\/VDDK. Ad esempio, se vediamo:<\/p>\n

Errore VDDK: 21036749815809.Errore sconosciuto<\/code><\/p>\n

Allora convertiamolo tranquillamente in hex e otteniamo 132200000001. Iniziamo poco informativo 132200 lo scartiamo e il resto sar\u00e0 il nostro codice di errore (VDDK 1: Errore sconosciuto). Recentemente \u00e8 stata dedicata una discussione agli errori VDDK pi\u00f9 comuni. su Habr.<\/u><\/a><\/noindex>.<\/p>\n

Ora diamo un'occhiata a Windows<\/strong>. <\/p>\n

Qui possiamo trovare tutto ci\u00f2 di cui abbiamo bisogno e che \u00e8 importante per noi nel standard Event Viewer<\/strong>. Ma c'\u00e8 un problema: per una lunga tradizione, Windows non registra il testo completo dell'errore, ma solo il suo numero. Ad esempio, l'errore 5 \u00e8 \"Accesso negato\", l'errore 1722 \u00e8 \"Il server RPC non \u00e8 disponibile\", e l'errore 10060 \u00e8 \"Connessione scaduta\". Certo, \u00e8 utile se ricordi i pi\u00f9 noti, ma come fare con quelli mai visti prima? <\/p>\n

E affinch\u00e9 la vita non sembri del tutto dolce, gli errori vengono memorizzati anche in formato esadecimale, con il prefisso 0x8007. Ad esempio, 0x8007000e \u2014 in realt\u00e0 \u00e8 14, Out of Memory. Perch\u00e9 e per chi sia stato fatto \u00e8 un mistero avvolto nelle tenebre. Tuttavia, \u00e8 possibile scaricare gratuitamente e senza SMS un elenco completo degli errori da devcenter<\/u><\/a><\/noindex>.<\/p>\n

A proposito, a volte si incontrano anche altri prefissi, non solo 0x8007. In una situazione cos\u00ec triste, per comprendere l'HRESULT (\u201chandle del risultato\u201d) \u00e8 necessario approfondire ulteriormente la documentazione<\/u><\/a><\/noindex> per gli sviluppatori. Nella vita di tutti i giorni non vi consiglierei di fare una cosa del genere, ma se dovesse realmente servirvi o semplicemente vi interessa, ora sapete cosa fare.<\/p>\n

Ma i compagni di Microsoft si sono un po' impietositi e ci hanno presentato l'utility ERR<\/u><\/a><\/noindex>. \u00c8 un piccolo pezzo di felicit\u00e0 da console, in grado di tradurre i codici di errore in un linguaggio comprensibile senza utilizzare Google. Funziona pi\u00f9 o meno cos\u00ec.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# per esadecimale 0x54f \/ decimale 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Si \u00e8 verificato un errore interno.\n# come un HRESULT: Severit\u00e0: SUCCESS (0), FACILITY_NULL (0x0), Codice 0x54f\n# per esadecimale 0x54f \/ decimale 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Si \u00e8 verificato un errore interno.\n# 2 corrispondenze trovate per \"0x54f\"<\/code><\/pre>\n
Sorge una legittima domanda: perch\u00e9 non scriviamo subito la decodifica nei log, lasciando questi codici misteriosi? La risposta \u00e8 nelle applicazioni di terze parti. Quando chiami un certo invocazione WinAPI, decifrare la sua risposta non \u00e8 difficile, perch\u00e9 esiste persino una chiamata WinAPI speciale per questo. Ma come gi\u00e0 detto, nei nostri log arriva tutto ci\u00f2 che ci arriva nelle risposte. E qui per la decodifica sarebbe necessario monitorare continuamente questo flusso di coscienza, estrarne i pezzi con gli errori di Windows, decifrarli e reinserirli. Diciamo pure, non \u00e8 l'attivit\u00e0 pi\u00f9 affascinante.<\/p>\n
Windows File Management API <\/strong>viene utilizzato in vari modi quando si lavora con file. Creazione di file, eliminazione, apertura in scrittura, gestione degli attributi e altro ancora.<\/p>\n
Il suddetto PowerShell Direct<\/strong> \u00e8 l'equivalente di VIX API nel mondo Hyper-V. Sfortunatamente, non \u00e8 cos\u00ec flessibile: molte limitazioni nella funzionalit\u00e0, non funziona con ogni versione dell'host e nemmeno con tutti gli ospiti.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Penso che non ci sia persona che abbia lavorato con Windows e non abbia mai visto errori legati a RPC. Nonostante la credenza popolare, non si tratta di un protocollo unico, ma di qualsiasi protocollo client-server che soddisfi determinati parametri. Tuttavia, se nei nostri log c'\u00e8 un errore RPC, nel 90% dei casi \u00e8 un errore di Microsoft RPC, che fa parte di DCOM (Distributed Component Object Model).  \u00c8 possibile trovare una grande quantit\u00e0 di documentazione su questo argomento, anche se gran parte di essa \u00e8 piuttosto obsoleta. Ma se c'\u00e8 un forte desiderio di approfondire l'argomento, posso raccomandare articoli Che cos'\u00e8 RPC?<\/u><\/a><\/noindex>, Come Funziona RPC<\/u> <\/a><\/noindex>e un lungo elenco di errori RPC<\/u><\/a><\/noindex>.<\/p>\n
Le principali cause di errori RPC nei nostri log sono tentativi falliti di interazione tra componenti VBR (server > proxy, ad esempio) e pi\u00f9 spesso a causa di problemi di connessione.<\/p>\n
Il top degli errori \u00e8 l'errore The RPC server is unavailable (1722). In parole semplici, il client non \u00e8 riuscito a stabilire una connessione con il server. Come e perch\u00e9 \u2014 non c'\u00e8 una risposta unica, ma di solito si tratta di problemi di autenticazione o di accesso di rete alla porta 135. Quest'ultima \u00e8 caratteristica delle infrastrutture con assegnazione dinamica delle porte. A questo proposito c'\u00e8 anche una KV separata<\/u><\/a><\/noindex>. E da Microsoft \u2014 una guida dettagliata<\/u><\/a><\/noindex> per la ricerca delle cause dei malfunzionamenti.<\/p>\n
Il secondo errore pi\u00f9 comune \u00e8: There are no more endpoints available from the endpoint mapper (1753). Il client o il server RPC non sono riusciti ad assegnare una porta. Questo di solito accade quando il server (nel nostro caso macchina guest) \u00e8 stato configurato per l'assegnazione dinamica delle porte da un intervallo ristretto, che \u00e8 esaurito. E se si guarda dal lato del client (nel nostro caso il server VBR), significa che il nostro VeeamVssAgent non si \u00e8 avviato o non \u00e8 stato registrato come interfaccia RPC. Anche su questo tema c'\u00e8 una KV separata<\/u><\/a><\/noindex>.<\/p>\n
E per concludere il Top-3 degli errori RPC, ricordiamo RPC function call failed (1726). Questo errore si verifica se la connessione \u00e8 stata stabilita, ma le richieste RPC non vengono elaborate. Ad esempio, richiediamo informazioni sullo stato del VSS (nel caso in cui stia eseguendo una copia shadow in questo momento, e noi tentiamo di accedere), e in risposta riceviamo silenzio e ignoranza.<\/p>\n
Windows Tape Backup API <\/strong>\u00e8 necessario per lavorare con librerie a nastro o dispositivi di archiviazione. Come ho gi\u00e0 accennato all'inizio: scrivere i propri driver e poi affrontare la questione del supporto per ogni dispositivo non ci d\u00e0 alcun piacere. Pertanto, Veeam non ha driver propri. Tutto passa attraverso l'API standard, il cui supporto \u00e8 fornito dai produttori hardware stessi. \u00c8 molto pi\u00f9 logico, vero?<\/p>\n
SMB\/CIFS<\/strong> Tutti per abitudine scrivono questi termini vicini, anche se non tutti ricordano che CIFS (Common Internet File System) \u00e8 semplicemente una versione privata di SMB (Server Message Block). Quindi non c'\u00e8 nulla di sbagliato nell'unificare questi concetti. Samba \u2014 \u00e8 gi\u00e0 l'implementazione LinuxUnix, e ha le sue peculiarit\u00e0, ma mi sono distratto. Ci\u00f2 che \u00e8 importante: quando Veeam chiede di scrivere qualcosa tramite percorso UNC (serverdirectory), il server utilizza la gerarchia dei driver del file system, inclusi mup e mrxsmb, per scrivere nella condivisione. Di conseguenza, gli errori saranno generati anche da questi driver.<\/p>\n
Non si pu\u00f2 fare a meno di Winsock API<\/strong>. Se c'\u00e8 qualcosa da fare in rete, VBR funziona tramite Windows Socket API, comunemente conosciuto come Winsock. Quindi, se vediamo nel log una coppia IP:Port, \u00e8 questo. Nella documentazione ufficiale c'\u00e8 un buon elenco di errori<\/u><\/a><\/noindex>.<\/p>\n
Il suddetto WMI<\/strong> (Windows Management Instrumentation) \u2014 \u00e8 un API onnipotente per la gestione di tutto e di tutti nel mondo Windows. Ad esempio, quando si lavora con Hyper-V, praticamente tutte le richieste al host avvengono proprio tramite esso. In una parola, \u00e8 uno strumento assolutamente indispensabile e molto potente nelle sue capacit\u00e0. Nei tentativi di capire dove e cosa sia andato storto, l'utilizzo della tool integrata WBEMtest.exe risulta molto utile.<\/p>\n
E l'ultimo della lista, ma non per questo meno importante \u2014 VSS<\/strong> (Volume Shadow Storage). L'argomento \u00e8 cos\u00ec ricco e misterioso, quanto \u00e8 ampia la documentazione esistente su di esso. La Shadow Copy pu\u00f2 essere compresa pi\u00f9 facilmente come un tipo speciale di snapshot, che in sostanza \u00e8. Grazie a questo, in VMware \u00e8 possibile effettuare backup coerenti con l'applicazione, e in Hyper-V praticamente tutto. Ho in programma di scrivere un articolo separato con un riassunto su VSS, ma nel frattempo puoi provare a leggere questa descrizione<\/u><\/a><\/noindex>. Solo attenzione, perch\u00e9 cercare di comprendere VSS di fretta pu\u00f2 portare a fastidi cerebrali.<\/p>\n
Su questo, direi che possiamo fermarci. Considero completata l'attivit\u00e0 di spiegare le cose pi\u00f9 basilari, quindi nel prossimo capitolo esamineremo i log. Ma se hai domande, non esitare a farle nei commenti.<\/p>\n<\/p>\n
Fonte: 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\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\udd47Da dove provengono i log? Veeam Log Diving | ProHoster","description":"Continuiamo il nostro tuffo nell'affascinante mondo della divinazione...","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}