{"id":34954,"date":"2019-10-31T22:01:30","date_gmt":"2019-10-31T19:01:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-3-obzor-i-testirovanie-duplicity-duplicati\/"},"modified":"2019-10-31T22:01:30","modified_gmt":"2019-10-31T19:01:30","slug":"rezervnoe-kopirovanie-chast-3-obzor-i-testirovanie-duplicity-duplicati","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-3-obzor-i-testirovanie-duplicity-duplicati","title":{"rendered":"Backup, parte 3: Panoramica e test di duplicity, duplicati","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup,<\/p>\n

<\/p>\n

In questo articolo vengono discussi i strumenti di backup che eseguono il backup creando archivi su un server di riserva.<\/p>\n

<\/p>\n

Tra quelli che soddisfano i requisiti ci sono duplicity (per il quale esiste una piacevole interfaccia in forma di deja dup) e duplicati.<\/p>\n

<\/p>\n

Un altro strumento di backup molto interessante \u00e8 dar, ma poich\u00e9 ha un elenco di opzioni piuttosto ampio, la metodologia di test copre a malapena il 10% di ci\u00f2 di cui \u00e8 capace; non lo testeremo nel ciclo attuale.<\/p>\n

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

Risultati attesi<\/h3>\n

<\/p>\n

Poich\u00e9 entrambi i candidati in un modo o nell'altro creano archivi, come riferimento possiamo usare il comune tar.<\/p>\n

<\/p>\n

Valuteremo inoltre quanto bene viene ottimizzato lo storage dei dati sul server di archiviazione creando backup che contengono solo la differenza tra una copia completa e lo stato attuale dei file, o tra gli archivi passati e presenti (incrementali, decrementali, ecc.).<\/p>\n

<\/p>\n

Comportamento nella creazione dei backup:<\/strong><\/p>\n

<\/p>\n

    \n
  1. Un numero relativamente ridotto di file sul server di backup (paragonabile al numero di backup o alla dimensione dei dati in GB), ma sufficientemente grande nel loro formato (decine-centinaia di megabyte).<\/li>\n
  2. La dimensione del repository includer\u00e0 solo le modifiche: i duplicati non verranno conservati, quindi la dimensione del repository sar\u00e0 inferiore rispetto a quando si utilizza un software basato su rsync.<\/li>\n
  3. Ci si aspetta un carico di lavoro maggiore sulla CPU quando si utilizza la compressione e\/o la crittografia, e probabilmente anche un carico di rete e di sistema di archiviazione significativo, se il processo di archiviazione e\/o crittografia avviene sul server di backup.<\/li>\n<\/ol>\n

    <\/p>\n

    Come valore di riferimento eseguiamo il seguente comando:<\/p>\n

    <\/p>\n

    cd \/src\/dir; tar -cf - * | ssh backup_server \"cat > \/backup\/dir\/archive.tar\"<\/code><\/pre>\n
    <\/p>\n
    I risultati dell'esecuzione sono stati i seguenti:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Il tempo di esecuzione \u00e8 stato di 3m12s. \u00c8 evidente che la velocit\u00e0 \u00e8 stata limitata dal sistema di archiviazione del server di backup, come nell'esempio con rsync<\/a><\/noindex>. Solo un po' pi\u00f9 veloce, poich\u00e9 la scrittura avviene in un unico file.<\/p>\n
    <\/p>\n
    Per valutare ulteriormente la compressione, eseguiamo la stessa variante, ma attiviamo la compressione sul server di backup:<\/p>\n
    <\/p>\n
    cd \/src\/dir; tar -cf - * | ssh backup_server \"gzip > \/backup\/dir\/archive.tgz\"<\/code><\/pre>\n
    <\/p>\n
    I risultati sono i seguenti:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Il tempo di esecuzione \u00e8 stato di 10m11s. \u00c8 probabile che il collo di bottiglia sia il compressore a thread singolo sul lato ricevente.<\/p>\n
    <\/p>\n
    Stessa squadra, ma con compressione spostata sul server con i dati originali per verificare l'ipotesi che il collo di bottiglia sia il compressore single-thread.<\/p>\n
    <\/p>\n
    cd \/src\/dir; tar -czf - * | ssh backup_server \"cat > \/backup\/dir\/archive.tgz\"<\/code><\/pre>\n
    <\/p>\n
    Risultato:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Il tempo di esecuzione \u00e8 stato di 9m37s. \u00c8 chiaro che uno dei core \u00e8 saturato dal compressore, poich\u00e9 la velocit\u00e0 di trasferimento sulla rete e il carico sul sottosistema disco di origine sono simili.<\/p>\n
    <\/p>\n
    Per valutare la crittografia si possono utilizzare openssl o gpg, collegando una linea aggiuntiva openssl<\/code> o gpg<\/code> nel pipe. Un esempio di comando sarebbe:<\/p>\n
    <\/p>\n
    cd \/src\/dir; tar -cf - * | ssh backup_server \"gzip | openssl enc -e -aes256 -pass pass:somepassword -out \/backup\/dir\/archive.tgz.enc\"<\/code><\/pre>\n
    <\/p>\n
    I risultati sono stati i seguenti:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Il tempo di esecuzione \u00e8 stato di 10m30s, poich\u00e9 sono stati avviati 2 processi sul lato ricevente \u2014 il collo di bottiglia \u00e8 di nuovo il compressore single-thread, pi\u00f9 un piccolo sovraccarico per la crittografia.<\/p>\n
    <\/p>\n
    UPD:<\/strong> Su richiesta di bliznezz, aggiungo i test con pigz. Se si utilizza solo il compressore, si \u00e8 ottenuto un tempo di 6m30s, se si aggiunge anche la crittografia, il tempo \u00e8 di circa 7m. Il crollo nel grafico in basso \u00e8 dovuto alla cache del disco non svuotata:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Test di duplicity<\/h3>\n
    <\/p>\n
    Duplicity \u00e8 un software in python per il backup che crea archivi crittografati in formato tar.<\/p>\n
    <\/p>\n
    Per archivi incrementali viene utilizzato librsync, quindi ci si pu\u00f2 aspettare un comportamento descritto nella nota precedente del ciclo<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    I backup possono essere crittografati e firmati utilizzando gnupg, il che \u00e8 importante quando si utilizzano diversi provider per l'archiviazione dei backup (s3, backblaze, gdrive, ecc.).<\/p>\n
    <\/p>\n
    Vediamo quali saranno i risultati:<\/p>\n
    \nEcco quali risultati sono stati ottenuti senza crittografia<\/b><\/p>\n
    spoiler<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Tempo di esecuzione di ciascun avvio di test:<\/p>\n
    <\/p>\n
    Avvio 1
    \nAvvio 2
    \nAvvio 3<\/p>\n
    16m33s
    \n17m20s
    \n16m30s<\/p>\n
    8m29s
    \n9m3s
    \n8m45s<\/p>\n
    5m21s
    \n6m04s
    \n5m53s<\/p>\n
    <\/p>\n
    Ecco i risultati con la crittografia gnupg attivata, con una dimensione della chiave di 2048 bit:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Tempo di esecuzione sugli stessi dati, con crittografia:<\/p>\n
    <\/p>\n
    Avvio 1
    \nAvvio 2
    \nAvvio 3<\/p>\n
    17m22s
    \n17m32s
    \n17m28s<\/p>\n
    8m52s
    \n9m13s
    \n9m3s<\/p>\n
    5m48s
    \n5m40s
    \n5m30s<\/p>\n
    <\/p>\n
    \u00c8 stata specificata una dimensione del blocco di 512 megabyte, il che \u00e8 chiaramente visibile nei grafici; il carico della CPU si \u00e8 mantenuto attorno al 50%, il che significa che il programma utilizza al massimo un core della CPU.<\/p>\n
    <\/p>\n
    Si comprende anche abbastanza bene il principio di funzionamento del programma: abbiamo preso un pezzo di dati, lo abbiamo compresso, e l'abbiamo inviato al server di archiviazione dei backup, che pu\u00f2 essere piuttosto lento.
    \nUn'altra caratteristica \u00e8 il tempo di lavoro del programma, che dipende solo dalle dimensioni dei dati modificati.<\/p>\n
    <\/p>\n
    L'attivazione della crittografia non ha aumentato particolarmente il tempo di esecuzione del programma, ma ha incrementato il carico della CPU di circa il 10%, il che pu\u00f2 essere un piacevole bonus.<\/p>\n
    <\/p>\n
    Sfortunatamente, questo programma non \u00e8 riuscito a rilevare correttamente la situazione con il rinominamento della directory, e la dimensione risultante del repository \u00e8 stata uguale alla dimensione delle modifiche (cio\u00e8 tutti i 18 GB), ma la possibilit\u00e0 di utilizzare un server non attendibile per il backup sovrasta senza dubbio questo comportamento.<\/p>\n
    <\/p>\n
    Test di duplicati<\/h3>\n
    <\/p>\n
    Questo software \u00e8 scritto in C# e viene eseguito utilizzando un insieme di librerie di Mono. Dispone di un'interfaccia grafica e di una versione CLI.<\/p>\n
    <\/p>\n
    L'elenco approssimativo delle principali funzionalit\u00e0 \u00e8 simile a quello di duplicity, includendo diversi fornitori per lo storage dei backup, ma, a differenza di duplicity, la maggior parte delle funzionalit\u00e0 sono disponibili senza strumenti di terze parti. Se sia un vantaggio o uno svantaggio dipende dal caso specifico, ma per i neofiti \u00e8 probabilmente pi\u00f9 facile avere un elenco completo di tutte le funzionalit\u00e0 piuttosto che installare pacchetti per Python come nel caso di duplicity.<\/p>\n
    <\/p>\n
    Un altro piccolo dettaglio \u00e8 che il programma scrive attivamente un database locale sqlite a nome dell'utente che avvia il backup, quindi \u00e8 necessario prestare attenzione ad indicare correttamente il database corretto ad ogni avvio del processo usando la CLI. Quando si lavora tramite GUI o WEBGUI, i dettagli sono nascosti all'utente.<\/p>\n
    \nVediamo quali risultati pu\u00f2 fornire questa soluzione:<\/b><\/p>\n
    Se si disattiva la crittografia (anche se il WEBGUI non lo consiglia), i risultati sono i seguenti:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Tempo di esecuzione:<\/p>\n
    <\/p>\n
    Avvio 1
    \nAvvio 2
    \nAvvio 3<\/p>\n
    20m43s
    \n20m13s
    \n20m28s<\/p>\n
    5m21s
    \n5m40s
    \n5m35s<\/p>\n
    7m36s
    \n7m54s
    \n7m49s<\/p>\n
    <\/p>\n
    Con la crittografia attivata, utilizzando aes, otteniamo:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Tempo di esecuzione:<\/p>\n
    <\/p>\n
    Avvio 1
    \nAvvio 2
    \nAvvio 3<\/p>\n
    29m9s
    \n30m1s
    \n29m54s<\/p>\n
    5m29s
    \n6m2s
    \n5m54s<\/p>\n
    8m44s
    \n9m12s
    \n9m1s<\/p>\n
    <\/p>\n
    E se si utilizza un programma esterno come gnupg, i risultati sono i seguenti:<\/p>\n
    <\/p>\n
    \"Backup,<\/a><\/noindex><\/p>\n
    <\/p>\n
    Avvio 1
    \nAvvio 2
    \nAvvio 3<\/p>\n
    26m6s
    \n26m35s
    \n26m17s<\/p>\n
    5m20s
    \n5m48s
    \n5m40s<\/p>\n
    8m12s
    \n8m42s
    \n8m15s<\/p>\n
    <\/p>\n
    Come si pu\u00f2 vedere, il programma pu\u00f2 funzionare in pi\u00f9 thread, ma questo non lo rende una soluzione pi\u00f9 performante, e se confrontiamo l'esecuzione della crittografia, l'avvio di un programma esterno
    \nsi \u00e8 rivelato pi\u00f9 veloce rispetto all'uso della libreria del pacchetto Mono. Probabilmente ci\u00f2 \u00e8 dovuto al fatto che il programma esterno \u00e8 pi\u00f9 ottimizzato.<\/p>\n
    <\/p>\n
    Un aspetto piacevole \u00e8 stato anche il fatto che la dimensione del repository occupa esattamente quanto i dati che sono stati effettivamente modificati, cio\u00e8 duplicati ha rilevato il rinominamento della directory e ha gestito correttamente questa situazione. Questo pu\u00f2 essere osservato durante l'esecuzione del secondo test.<\/p>\n
    <\/p>\n
    In generale, impressioni piuttosto positive del programma, inclusa una sufficiente facilit\u00e0 d'uso per i principianti.<\/p>\n
    <\/p>\n
    Risultati<\/h3>\n
    <\/p>\n
    Entrambi i candidati hanno lavorato piuttosto lentamente, ma in generale, rispetto al normale tar, c'\u00e8 progresso, almeno per duplicati. Il costo di tale progresso \u00e8 anche comprensibile: un carico notevole
    \ndel processore. In generale, non ci sono particolari deviazioni nelle previsioni dei risultati.<\/p>\n
    <\/p>\n
    Conclusioni<\/h3>\n
    <\/p>\n
    Se non c'\u00e8 fretta e c'\u00e8 anche una riserva di elaborazione - qualsiasi delle soluzioni esaminate andr\u00e0 bene, in ogni caso \u00e8 stata svolta un lavoro piuttosto ampio, che non vale la pena ripetere scrivendo script di avvolgimento sopra tar. La presenza della crittografia \u00e8 una caratteristica molto necessaria, se il server per la memorizzazione dei backup non pu\u00f2 essere completamente fidato.<\/p>\n
    <\/p>\n
    Se comparato con soluzioni basate su rsync<\/a><\/noindex> \u2014 le prestazioni potrebbero essere inferiori di diversi fattori, nonostante il fatto che in termini di tempo puro tar abbia lavorato pi\u00f9 velocemente di rsync del 20-30%.
    \nC'\u00e8 un risparmio sulle dimensioni del repository, ma solo per duplicati.<\/p>\n
    <\/p>\n
    Annuncio<\/h3>\n
    <\/p>\n
    Backup, parte 1: Perch\u00e9 \u00e8 necessario il backup, panoramica dei metodi e delle tecnologie<\/a><\/noindex>
    \n    Backup, parte 2: Panoramica e test di strumenti di backup basati su rsync<\/a><\/noindex>
    \nBackup, parte 3: Revisione e test di duplicity, duplicati, deja dup
    \nBackup, parte 4: Panoramica e test di zbackup, restic, borgbackup
    \nBackup, parte 5: Test di Bacula e Veeam Backup for Linux
    \nBackup, parte 6: Confronto degli strumenti di backup
    \nBackup, parte 7: Conclusioni<\/p>\n
    <\/p>\n
    Autore della pubblicazione:<\/u> Pavel Demkovich<\/p>\n
    Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0437\u0430\u043c\u0435\u0442\u043a\u0435 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043d\u044b \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u044e\u0442 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0435 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u0443\u0442\u0435\u043c \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0430\u0440\u0445\u0438\u0432\u043e\u0432 \u043d\u0430 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u0435. \u0418\u0437 \u0442\u0435\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u044e\u0442 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u2014 duplicity (\u043a \u043a\u043e\u0442\u043e\u0440\u043e\u043c\u0443 \u0435\u0441\u0442\u044c \u043f\u0440\u0438\u044f\u0442\u043d\u044b\u0439 \u0438\u043d\u0442\u0435\u0440\u0444\u0435\u0439\u0441 \u0432 \u0432\u0438\u0434\u0435 deja dup) \u0438 duplicati. \u0415\u0449\u0435 \u043e\u0434\u043d\u043e \u0432\u0435\u0441\u044c\u043c\u0430 \u043f\u0440\u0438\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u2014 dar, \u043d\u043e \u043f\u043e\u0441\u043a\u043e\u043b\u044c\u043a\u0443 \u0443 \u043d\u0435\u0433\u043e \u0438\u043c\u0435\u0435\u0442\u0441\u044f \u0432\u0435\u0441\u044c\u043c\u0430 \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u0439 \u0441\u043f\u0438\u0441\u043e\u043a \u043e\u043f\u0446\u0438\u0439 \u2014 \u043c\u0435\u0442\u043e\u0434\u0438\u043a\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26307,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34954","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\udd47Backup, parte 3: Revisione e test di duplicity, duplicati | ProHoster","description":"In questo.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-3-obzor-i-testirovanie-duplicity-duplicati","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\u0420\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0435 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435, \u0447\u0430\u0441\u0442\u044c 3: \u041e\u0431\u0437\u043e\u0440 \u0438 \u0442\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 duplicity, duplicati | ProHoster","og:description":"\u0412 \u0434\u0430\u043d\u043d\u043e\u0439.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-3-obzor-i-testirovanie-duplicity-duplicati","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-31T19:01:30+00:00","article:modified_time":"2019-10-31T19:01:30+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34954","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 21:15:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:03:10","updated":"2026-01-21 21:15: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\/34954","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=34954"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34954\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26307"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34954"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34954"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34954"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}