{"id":30356,"date":"2019-10-31T21:35:06","date_gmt":"2019-10-31T18:35:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql\/"},"modified":"2019-10-31T21:35:06","modified_gmt":"2019-10-31T18:35:06","slug":"kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Come abbiamo utilizzato la replica ritardata per il ripristino di emergenza con PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\nLa replica non \u00e8 un backup. O forse s\u00ec? Ecco come abbiamo usato la replica ritardata per il ripristino dopo aver eliminato accidentalmente i collegamenti.<\/p>\n

<\/p>\n

Specialisti di infrastruttura<\/a><\/noindex> su GitLab sono responsabili del funzionamento GitLab.com<\/a><\/noindex> \u2014 del pi\u00f9 grande esempio di GitLab esistente. Qui ci sono 3 milioni di utenti e quasi 7 milioni di progetti, e questo \u00e8 uno dei pi\u00f9 grandi siti SaaS open-source con architettura dedicata. Senza il sistema di database PostgreSQL, l'infrastruttura di GitLab.com non andrebbe lontano, e qualsiasi cosa facciamo per la tolleranza ai guasti in caso di eventuali crash in cui si possono perdere dati. \u00c8 improbabile che si verifichi una tale catastrofe, ma ci siamo preparati bene e abbiamo accumulato vari meccanismi di backup e replica.<\/p>\n

<\/p>\n

La replica non \u00e8 un metodo di backup per database (vedi sotto<\/a><\/noindex>). Ma ora vedremo come ripristinare rapidamente i dati eliminati accidentalmente con la replica ritardata: nella GitLab.com<\/a><\/noindex> utente ho eliminato il collegamento<\/a><\/noindex> per il progetto gitlab-ce<\/code><\/a><\/noindex> e ho perso il collegamento con le merge request e i task.<\/p>\n

<\/p>\n

Con la replica ritardata abbiamo ripristinato i dati in sole 1,5 ore. Guarda come \u00e8 stato.<\/p>\n

<\/a><\/noindex><\/p>\n

Ripristino a un momento specifico con PostgreSQL<\/h3>\n

<\/p>\n

PostgreSQL ha una funzione integrata che ripristina lo stato del database a un momento specifico. Si chiama Point-in-Time Recovery<\/a><\/noindex> (PITR) e utilizza gli stessi meccanismi che mantengono l'attualit\u00e0 della replica: partendo da un'istantanea affidabile dell'intero cluster del database (backup di base), applichiamo una serie di modifiche fino a un momento specifico.<\/p>\n

<\/p>\n

Per utilizzare questa funzione per il backup a freddo, eseguiamo regolarmente un backup di base del database e lo conserviamo in archivio (gli archivi di GitLab risiedono in Google Cloud Storage<\/a><\/noindex>). Inoltre, monitoriamo le modifiche allo stato del database, archiviando il log delle scritture anticipate (write-ahead log<\/a><\/noindex>, WAL). E con tutto ci\u00f2 possiamo eseguire PITR per il ripristino di emergenza: iniziamo con l'istantanea creata prima dell'errore e applichiamo le modifiche dall'archivio WAL fino al guasto.<\/p>\n

<\/p>\n

Che cos'\u00e8 la replica ritardata?<\/h3>\n

<\/p>\n

La replica ritardata \u00e8 l'applicazione delle modifiche dal WAL con un ritardo. Cio\u00e8, la transazione \u00e8 avvenuta un'ora X<\/code>, ma nella replica apparir\u00e0 con un ritardo d<\/code> di un'ora X + d<\/code>.<\/p>\n

<\/p>\n

In PostgreSQL ci sono 2 modi per configurare una replica fisica del database: ripristino dall'archivio e replica in streaming. Ripristino dall'archivio<\/a><\/noindex>, in sostanza, funziona come PITR, ma in modo continuo: estraiamo costantemente le modifiche dall'archivio WAL e le applichiamo alla replica. A replica streaming<\/a><\/noindex> estrae direttamente il flusso WAL dall'host del database di livello superiore. Preferiamo il ripristino dall'archivio: \u00e8 pi\u00f9 semplice da gestire e ha prestazioni normali che non sono inferiori a quelle del cluster di lavoro.<\/p>\n

<\/p>\n

Come configurare il ripristino ritardato dall'archivio<\/h3>\n

<\/p>\n

Opzioni di ripristino<\/a><\/noindex> sono descritte nel file recovery.conf<\/code>. Esempio:<\/p>\n

<\/p>\n

standby_mode = 'on'\nrestore_command = ' \/usr\/bin\/envdir \/etc\/wal-e.d\/env \/opt\/wal-e\/bin\/wal-e wal-fetch -p 4 \"%f\" \"%p\"'\nrecovery_min_apply_delay = '8h'\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n
<\/p>\n
Con queste impostazioni abbiamo configurato una replica ritardata con ripristino dall'archivio. Qui si utilizza wal-e<\/a><\/noindex> per estrarre i segmenti WAL (restore_command<\/code>) dall'archivio, e le modifiche verranno applicate dopo otto ore (recovery_min_apply_delay<\/code>). La replica seguir\u00e0 le modifiche della timeline nell'archivio, come ad esempio a causa della gestione dei guasti nel cluster (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
C recovery_min_apply_delay<\/code> \u00e8 possibile configurare la replica streaming con ritardo, ma ci sono un paio di insidie relative agli slot di replica, al feedback del backup caldo, ecc. L'archivio WAL consente di evitarle.<\/p>\n
<\/p>\n
Parametro recovery_min_apply_delay<\/code> \u00e8 apparso solo in PostgreSQL 9.3. Nelle versioni precedenti, per la replica ritardata era necessario configurare una combinazione di funzioni di gestione del ripristino<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) o mantenere i segmenti WAL nell'archivio durante il tempo di ritardo.<\/p>\n
<\/p>\n
Come lo fa PostgreSQL?<\/h3>\n
<\/p>\n
\u00c8 interessante vedere come PostgreSQL implementa il ripristino ritardato. Guardiamo a recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Viene chiamato dal ciclo principale di ripristino<\/a><\/noindex> per ciascun record del WAL.<\/p>\n
<\/p>\n
static bool\nrecoveryApplyDelay(XLogReaderState *record)\n{\n    uint8       xact_info;\n    TimestampTz xtime;\n    long        secs;\n    int         microsecs;\n\n    \/* niente da fare se non \u00e8 configurato alcun ritardo *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* nessun ritardo viene applicato a un database non ancora consistente *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * \u00c8 un record di COMMIT?\n     *\n     * Abbiamo deliberatamente scelto di non ritardare gli aborti poich\u00e9 non hanno effetto su\n     * MVCC. Gi\u00e0 consentiamo la riproduzione di record che non hanno un timestamp,\n     * quindi c'\u00e8 gi\u00e0 opportunit\u00e0 di problemi causati da conflitti anticipati su\n     * standby.\n     * \/ \n    if (XLogRecGetRmid(record) != RM_XACT_ID)\n        return false;\n\n    xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;\n\n    if (xact_info != XLOG_XACT_COMMIT &&\n        xact_info != XLOG_XACT_COMMIT_PREPARED)\n        return false;\n\n    if (!getRecordTimestamp(record, &xtime))\n        return false;\n\n    recoveryDelayUntilTime =\n        TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);\n\n    \/*\n     * Esci senza armare il latch se \u00e8 gi\u00e0 passato il tempo per applicare questo\n     * record\n     * \/ \n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ Accorciato:\n        \/\/ Usa WaitLatch fino a raggiungere recoveryDelayUntilTime\n        \/\/ e poi\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
Il punto \u00e8 che il ritardo \u00e8 basato sul tempo fisico, registrato nel timestamp del commit della transazione (xtime<\/code>). Come si pu\u00f2 vedere, il ritardo si applica solo ai commit e non tocca altri record: tutte le modifiche vengono applicate direttamente, mentre il commit viene rinviato, quindi vedremo le modifiche solo dopo il ritardo configurato.<\/p>\n
<\/p>\n
Come utilizzare una replica ritardata per il recupero dei dati<\/h3>\n
<\/p>\n
Supponiamo di avere in produzione un cluster di database e una replica con un ritardo di otto ore. Vediamo come recuperare i dati usando come esempio la cancellazione accidentale di etichette<\/a><\/noindex>.<\/p>\n
<\/p>\n
Quando abbiamo saputo del problema, abbiamo sospeso il recupero dall'archivio<\/a><\/noindex> per la replica ritardata:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Con la pausa non c'era il rischio che la replica ripetesse la richiesta DELETE<\/code>. Utile se serve tempo per capire tutto.<\/p>\n
<\/p>\n
Il punto \u00e8 che la replica ritardata deve arrivare al momento prima della richiesta DELETE<\/code>. Sapevamo pi\u00f9 o meno il tempo fisico della cancellazione. Abbiamo rimosso recovery_min_apply_delay<\/code> e aggiunto recovery_target_time<\/code> in recovery.conf<\/code>. Cos\u00ec la replica raggiunge il momento desiderato senza ritardi:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Con i timestamp \u00e8 meglio ridurre il superfluo per non sbagliare. Tuttavia, quanto maggiore \u00e8 la riduzione, pi\u00f9 dati perdiamo. In ogni caso, se saltiamo la richiesta DELETE<\/code>, tutto verr\u00e0 di nuovo eliminato e dovremo ricominciare daccapo (o prendere un backup a freddo per il PITR).<\/p>\n
<\/p>\n
Abbiamo riavviato l'istanza Postgres in attesa e i segmenti WAL sono stati ripetuti fino all'orario indicato. \u00c8 possibile monitorare i progressi a questo stadio con la seguente query:<\/p>\n
<\/p>\n
SELECT\n  -- posizione attuale nel WAL\n  pg_last_xlog_replay_location(),\n  -- timestamp della transazione corrente (stato della replica)\n  pg_last_xact_replay_timestamp(),\n  -- tempo fisico attuale\n  now(),\n  -- quantit\u00e0 di tempo ancora da applicare fino al raggiungimento del recovery_target_time\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Se il timestamp non cambia pi\u00f9, il ripristino \u00e8 completato. Puoi configurare l'azione recovery_target_action<\/code><\/a><\/noindex>, per chiudere, promuovere o sospendere l'istanza dopo il ripristino (di default viene sospesa).<\/p>\n
<\/p>\n
Il database \u00e8 tornato a uno stato precedente a quella famigerata richiesta. Ora puoi, ad esempio, esportare i dati. Abbiamo esportato i dati rimossi sul collegamento e tutte le associazioni con il lavoro e le merge request e li abbiamo trasferiti nel database di lavoro. Se la perdita \u00e8 ampia, puoi semplicemente promuovere la replica e usarla come principale. Ma in tal caso perderai tutte le modifiche dopo il momento fino a cui siamo tornati.<\/p>\n
<\/p>\n
\u00c8 meglio usare gli ID delle transazioni invece dei timestamp. \u00c8 utile registrare questi ID, ad esempio, per gli operatori DDL (tipo , ma la situazione con<\/code>), tramite log_statements = 'ddl'<\/code>. Se avessimo l'ID della transazione, avremmo preso recovery_target_xid<\/code> e avremmo eseguito tutte fino alla transazione prima della richiesta. DELETE<\/code>.<\/p>\n
<\/p>\n
Tornare al lavoro \u00e8 molto semplice: rimuovi tutte le modifiche da recovery.conf<\/code> e riavvia Postgres. Presto nella replica apparir\u00e0 di nuovo un ritardo di otto ore e saremo pronti per future sgradevolezze.<\/p>\n
<\/p>\n
Vantaggi del ripristino<\/h3>\n
<\/p>\n
Con una replica in attesa, non \u00e8 necessario ripristinare per ore l'intero snapshot dall'archivio. Ci vogliono, ad esempio, cinque ore per estrarre l'intero backup base da 2 TB. E poi dovremo applicare tutto il WAL giornaliero per ripristinare lo stato desiderato (nel peggiore dei casi).<\/p>\n
<\/p>\n
Una replica in attesa \u00e8 migliore di un backup a freddo per due motivi:<\/p>\n
<\/p>\n
    \n
  1. Non \u00e8 necessario estrarre l'intero backup base dall'archivio.<\/li>\n
  2. C'\u00e8 una finestra fissa di otto ore di segmenti WAL da ripetere.<\/li>\n<\/ol>\n
    <\/p>\n
    Inoltre, controlliamo costantemente se \u00e8 possibile effettuare un PITR dal WAL e noteremmo rapidamente eventuali danni o altri problemi con l'archivio WAL, monitorando il ritardo della replica in attesa.<\/p>\n
    <\/p>\n
    In questo esempio, abbiamo impiegato 50 minuti per il ripristino, quindi la velocit\u00e0 era di 110 GB di dati WAL all'ora (l'archivio all'epoca era ancora su AWS S3<\/a><\/noindex>). Abbiamo risolto il problema e ripristinato i dati in 1,5 ore.<\/p>\n
    <\/p>\n
    Risultati: dove \u00e8 utile la replica differita (e dove no)<\/h3>\n
    <\/p>\n
    Utilizza la replica differita come mezzo di pronto soccorso, se hai perso accidentalmente dei dati e ti sei accorto di questo problema entro il ritardo impostato.<\/p>\n
    <\/p>\n
    Ma ricorda: la replica non \u00e8 un backup.<\/p><\/blockquote>\n
    Il backup e la replica hanno obiettivi diversi. Un backup freddo \u00e8 utile se hai fatto accidentalmente DELETE<\/code> o , ma la situazione con<\/code>. Effettuamo un backup da un archivio freddo e ripristiniamo lo stato precedente della tabella o dell'intera base di dati. Ma in questo caso la richiesta , ma la situazione con<\/code> viene quasi istantaneamente replicata in tutte le repliche nel cluster operativo, quindi la replica normale non aiuter\u00e0. La replica stessa mantiene il database accessibile quando vengono disattivati server singoli e distribuisce il carico.<\/p>\n
    <\/p>\n
    Anche con la replica differita, a volte abbiamo davvero bisogno di un backup freddo in un luogo sicuro, nel caso in cui si verifichi un guasto del data center, un danno nascosto o altri eventi che non noti immediatamente. Qui una semplice replica non \u00e8 sufficiente.<\/p>\n
    <\/p>\n
    Nota<\/strong>. Su GitLab.com<\/a><\/noindex> Attualmente proteggiamo solo a livello di sistema contro la perdita di dati e non ripristiniamo i dati a livello utente.<\/p>\n
    Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u0420\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f \u2014 \u043d\u0435 \u0431\u044d\u043a\u0430\u043f. \u0418\u043b\u0438 \u043d\u0435\u0442? \u0412\u043e\u0442 \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u043e\u0442\u043b\u043e\u0436\u0435\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f, \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u043e \u0443\u0434\u0430\u043b\u0438\u0432 \u044f\u0440\u043b\u044b\u043a\u0438. \u0421\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u043f\u043e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 \u043d\u0430 GitLab \u043e\u0442\u0432\u0435\u0447\u0430\u044e\u0442 \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 GitLab.com \u2014 \u0441\u0430\u043c\u043e\u0433\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u0430 GitLab \u0432 \u043f\u0440\u0438\u0440\u043e\u0434\u0435. \u0417\u0434\u0435\u0441\u044c 3 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u0430 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u043f\u043e\u0447\u0442\u0438 7 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0438 \u044d\u0442\u043e \u043e\u0434\u0438\u043d \u0438\u0437 \u0441\u0430\u043c\u044b\u0445 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441-\u0441\u0430\u0439\u0442\u043e\u0432 SaaS \u0441 \u0432\u044b\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043e\u0439. \u0411\u0435\u0437 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22360,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30356","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\udd47Come abbiamo utilizzato la replica differita per il recupero di emergenza con PostgreSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","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\u041a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u043e\u0442\u043b\u043e\u0436\u0435\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u0430\u0432\u0430\u0440\u0438\u0439\u043d\u043e\u0433\u043e \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f \u0441 PostgreSQL | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","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":"2019-10-31T18:35:06+00:00","article:modified_time":"2019-10-31T18:35:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30356","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":"2026-01-21 00:50:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:48:29","updated":"2026-01-21 00:50:19","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\/30356","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=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}