{"id":39250,"date":"2019-10-31T22:28:41","date_gmt":"2019-10-31T19:28:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rezervnoe-kopirovanie-chast-7-vyvody\/"},"modified":"2019-10-31T22:28:41","modified_gmt":"2019-10-31T19:28:41","slug":"rezervnoe-kopirovanie-chast-7-vyvody","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-7-vyvody","title":{"rendered":"Backup, parte 7: Conclusioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Backup, parte 7: Conclusioni\" src=\"\/wp-content\/uploads\/2019\/10\/475781030b157d85aa9e9a1dc7ea7c6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Questa nota conclude il ciclo di backup. Si discuter\u00e0 dell'organizzazione logica di un server dedicato (o VPS), adatta per il backup, e sar\u00e0 proposta una soluzione per il ripristino rapido del server da un backup senza significativi tempi di inattivit\u00e0 in caso di guasti.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"ishodnye-dannye\">Dati di origine<\/h2>\n<p><\/p>\n<p>Un server dedicato ha di solito almeno due dischi rigidi, utilizzati per costituire un array RAID di primo livello (mirror). Questo \u00e8 necessario per garantire la continuit\u00e0 operativa del server nel caso in cui un disco fallisca. Se si tratta di un server dedicato standard, pu\u00f2 esserci un controller RAID hardware dedicato, con tecnologia di caching attiva su SSD, in modo che, oltre ai dischi rigidi normali, possa essere collegato uno o pi\u00f9 SSD. A volte vengono offerti server dedicati che hanno come dischi locali solo SATADOM (piccoli dischi, strutturalmente \u2014 chiavette, collegate a una porta SATA), o addirittura una piccola chiavetta (8-16 GB), collegata a una porta interna speciale, mentre i dati vengono prelevati da uno storage SAN, connesso tramite una rete dedicata (Ethernet 10G, FC, ecc.), o ci sono server dedicati che si avviano direttamente dallo storage SAN. Non tratter\u00f2 queste opzioni, poich\u00e9 in tali casi la responsabilit\u00e0 del backup del server passa agli specialisti che gestiscono lo storage SAN, che di solito hanno diverse tecnologie proprietarie per creare snapshot, deduplicazione integrata e altri vantaggi per il system administrator, discussi nelle parti precedenti di questo ciclo. La capacit\u00e0 dell'array disco di un server dedicato pu\u00f2 raggiungere diverse decine di terabyte, a seconda del numero e della capacit\u00e0 dei dischi connessi al server. Nel caso dei VPS, le dimensioni sono pi\u00f9 modeste: di solito non oltre i 100 GB (anche se ci sono eccezioni), e le tariffe per tali VPS possono facilmente essere pi\u00f9 elevate rispetto ai server dedicati pi\u00f9 economici offerti dallo stesso host. Nel caso dei VPS, di solito c'\u00e8 un solo disco, poich\u00e9 sotto di esso ci sar\u00e0 uno storage SAN (o qualcosa di iperconvergente). A volte i VPS hanno pi\u00f9 dischi con diverse caratteristiche, per scopi diversi:<\/p>\n<p><\/p>\n<ul>\n<li>piccolo sistema \u2014 per l'installazione del sistema operativo;<\/li>\n<li>grande \u2014 per lo storage di dati utente.<\/li>\n<\/ul>\n<p><\/p>\n<p>Durante la reinstallazione del sistema tramite il pannello di controllo, il disco contenente i dati utente non viene sovrascritto, mentre il sistema viene completamente ripristinato. Inoltre, nel caso di un VPS, l'host pu\u00f2 offrire un pulsante per creare uno snapshot dello stato del VPS (o del disco), ma se viene installato un sistema operativo personalizzato o si dimentica di attivare il servizio necessario all'interno del VPS, alcuni dati potrebbero comunque andare persi. Oltre al pulsante, di solito viene offerta una soluzione di storage, spesso molto limitata. Di solito, si tratta di un account con accesso tramite protocollo FTP o SFTP, a volte insieme a SSH, con shell limitata (ad esempio rbash), o con limitazioni nell'esecuzione di comandi tramite authorized_keys (tramite ForcedCommand). <\/p>\n<p><\/p>\n<p>Il server dedicato \u00e8 connesso alla rete tramite due porte con velocit\u00e0 di 1 Gbit\/s, a volte possono essere schede con velocit\u00e0 di 10 Gbit\/s. Nel caso dei VPS, l'interfaccia di rete \u00e8 di solito una sola. Di solito, i data center non limitano la velocit\u00e0 della rete all'interno del data center, ma limitano la velocit\u00e0 di accesso a Internet.<\/p>\n<p><\/p>\n<p>Il carico tipico di un server dedicato o di un VPS consiste in un server web, un database e un server applicazioni. Possono essere installati anche vari servizi ausiliari, inclusi per il server web o il database: motori di ricerca, sistemi di posta, ecc.<\/p>\n<p><\/p>\n<p>Come spazio di archiviazione per i backup viene utilizzato un server appositamente preparato, di cui si parler\u00e0 in dettaglio pi\u00f9 avanti.<\/p>\n<p><\/p>\n<h2 id=\"logicheskaya-organizaciya-diskovoy-sistemy\">Organizzazione logica del sistema disco<\/h2>\n<p><\/p>\n<p>Se c'\u00e8 un controller RAID, o si tratta di un VPS con un disco solo, e non ci sono preferenze specifiche per il funzionamento del sottosistema disco (ad esempio, un disco veloce separato per il database), tutto lo spazio libero viene suddiviso in questo modo: viene creato un unico volume, su di esso viene creato un gruppo di volumi LVM, in cui vengono creati diversi volumi: 2 piccoli di dimensioni uguali, utilizzati come file system root (che vengono alternati durante gli aggiornamenti per consentire un rapido rollback, idea ispirata dalla distribuzione Calculate Linux), un altro \u2014 per la partizione di swap, il resto dello spazio libero viene suddiviso in volumi pi\u00f9 piccoli, utilizzati come file system root per container completi, dischi per macchine virtuali, file system per account in \/home (ogni account ha il proprio file system), file system per container-applicazioni.<\/p>\n<p><\/p>\n<p>Nota importante: i volumi devono essere completamente autonomi, cio\u00e8 non devono dipendere l'uno dall'altro n\u00e9 dal filesystem radice. Nel caso di macchine virtuali o container, questo aspetto viene rispettato automaticamente. Tuttavia, se si tratta di container per applicazioni o directory home, \u00e8 opportuno considerare di separare i file di configurazione del server web e altri servizi in modo da ridurre al minimo le dipendenze tra i volumi. Ad esempio, ogni sito funziona con il proprio utente, i file di configurazione del sito sono nella home dell'utente, nelle impostazioni del server web i file di configurazione dei siti non sono inclusi tramite \/etc\/nginx\/conf.d\/<em>.conf, ma, ad esempio, \/home\/<\/em>\/configs\/nginx\/*.conf<\/p>\n<p><\/p>\n<p>Se ci sono pi\u00f9 dischi, \u00e8 possibile creare un array RAID software (e configurarne la cache su SSD, se necessario e possibile), sopra il quale costruire LVM secondo le regole suggerite in precedenza. Anche in questo caso \u00e8 possibile utilizzare ZFS o BtrFS, ma vale la pena riflettere: entrambi richiedono un approccio molto pi\u00f9 serio alle risorse, inoltre ZFS non \u00e8 incluso nel kernel Linux.<\/p>\n<p><\/p>\n<p>Indipendentemente dallo schema utilizzato, \u00e8 sempre utile stimare in anticipo la velocit\u00e0 di scrittura delle modifiche sui dischi e calcolare lo spazio libero che sar\u00e0 riservato per la creazione di snapshot. Ad esempio, se il nostro server scrive dati a una velocit\u00e0 di 10 megabyte al secondo e la dimensione dell'intero array di dati \u00e8 di 10 terabyte, il tempo di sincronizzazione potrebbe raggiungere un giorno (22 ore - tanto tempo impiegherebbe a trasferire tale volume su una rete 1 Gbit\/s) - sarebbe opportuno riservare circa 800 GB. In realt\u00e0, il numero sar\u00e0 inferiore, si pu\u00f2 tranquillamente dividerlo per il numero di volumi logici.<\/p>\n<p><\/p>\n<h2 id=\"ustroystvo-servera-hraneniya-rezervnyh-kopiy\">Dispositivo server per il backup<\/h2>\n<p><\/p>\n<p>La principale differenza di un server per il backup \u00e8 costituita da dischi grandi, economici e relativamente lenti. Poich\u00e9 i moderni HDD hanno gi\u00e0 superato il limite di 10 TB in un singolo disco, \u00e8 imprescindibile l'uso di filesystem o RAID con checksum, poich\u00e9 durante la ristrutturazione dell'array o il ripristino del filesystem (che pu\u00f2 durare diversi giorni!) potrebbe guastarsi il secondo disco a causa dell'aumento del carico. Con dischi da 1 TB non si avvertiva cos\u00ec tanto. Per semplificare la descrizione, presumo che lo spazio su disco sia diviso in due parti di dimensioni simili (ancora, ad esempio, utilizzando LVM):<\/p>\n<p><\/p>\n<ul>\n<li>volumi corrispondenti sui server, utilizzati per memorizzare i dati degli utenti (su di essi sar\u00e0 distribuita l'ultima copia di backup effettuata per il controllo);<\/li>\n<li>volumi utilizzati come repository BorgBackup (qui verranno memorizzati direttamente i dati per i backup).<\/li>\n<\/ul>\n<p><\/p>\n<p>Il principio di funzionamento consiste nel creare volumi separati per ciascun server destinati ai repository BorgBackup, dove giungeranno i dati dai server in produzione. I repository funzionano in modalit\u00e0 append-only, escludendo la possibilit\u00e0 di eliminare intenzionalmente i dati, e grazie alla deduplicazione e alla pulizia periodica dei repository dai vecchi backup (rimangono le copie annuali, quelle mensili per l'ultimo anno, settimanali per l'ultimo mese, giornaliere per l'ultima settimana, possibilmente - in casi speciali - orarie per l'ultimo giorno: in totale 24 + 7 + 4 + 12 + annuali - circa 50 copie per ogni server).<br \/>\nNei repository BorgBackup non \u00e8 attivata la modalit\u00e0 append-only, ma viene utilizzato ForcedCommand in .ssh\/authorized_keys in un formato del tipo:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">from=\"indirizzo server\",command=\"\/usr\/local\/bin\/borg serve --append-only --restrict-to-path \/home\/servername\/borgbackup\/\",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......<\/code><\/pre>\n<p><\/p>\n<p>Nel percorso specificato \u00e8 presente uno script wrapper sopra Borg, che oltre a eseguire il binario con i parametri, avvia anche il processo di ripristino del backup dopo il completamento del recupero dei dati. A tal fine, lo script wrapper crea un file di segnalazione accanto al relativo repository. L'ultima copia di backup effettuata viene automaticamente ripristinata sul corrispondente volume logico al termine del processo di upload dei dati.<\/p>\n<p><\/p>\n<p>Questa struttura consente di pulire periodicamente i backup non necessari e non permette ai server di produzione di eliminare nulla sul server di storage per i backup.<\/p>\n<p><\/p>\n<h2 id=\"process-rezervnogo-kopirovaniya\">Il processo di backup<\/h2>\n<p><\/p>\n<p>Il server dedicato o VPS funge da iniziatore del backup, poich\u00e9 questo schema offre un maggiore controllo sul processo di backup da parte di questo server. Si inizia creando uno snapshot dello stato attivo del file system radice, che viene montato e caricato sul server di archiviazione dei backup utilizzando BorgBackup. Una volta conclusa l'acquisizione dei dati, lo snapshot viene smontato e rimosso.<\/p>\n<p><\/p>\n<p>Nel caso di avere un piccolo database (fino a 1 GB per ogni sito), viene creato un dump del database, che viene salvato nell'apposito volume logico, insieme ai restanti dati di quel sito, ma in modo tale che il dump non sia accessibile tramite il server web. Se i database sono grandi, \u00e8 necessario configurare il salvataggio \"automatico\" dei dati, ad esempio utilizzando xtrabackup per MySQL, o configurando il WAL con archive_command in PostgreSQL. In questo caso, il database verr\u00e0 ripristinato separatamente dai dati dei siti.<\/p>\n<p><\/p>\n<p>Se vengono utilizzati contenitori o macchine virtuali, \u00e8 necessario configurare qemu-guest-agent, CRIU o altre tecnologie necessarie. Negli altri casi, generalmente non \u00e8 necessaria una configurazione aggiuntiva: si creano semplicemente snapshot dei volumi logici, che vengono poi elaborati analogamente allo snapshot dello stato del file system radice. Dopo l'acquisizione dei dati, gli snapshot vengono rimossi.<\/p>\n<p><\/p>\n<p>Il lavoro successivo avviene sul server di archiviazione dei backup:<\/p>\n<p><\/p>\n<ul>\n<li>si verifica l'ultimo backup eseguito in ciascun repository,<\/li>\n<li>si controlla l'esistenza di un file di etichetta che indica che il processo di acquisizione dei dati \u00e8 completato,<\/li>\n<li>si esegue il ripristino dei dati sul volume locale corrispondente,<\/li>\n<li>si rimuove il file di etichetta<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"process-vosstanovleniya-rabotosposobnosti-servera\">Il processo di ripristino della funzionalit\u00e0 del server<\/h2>\n<p><\/p>\n<p>Se il server principale fallisce, viene avviato un server dedicato analogo, che si avvia da una certa immagine standard. Probabilmente il caricamento avverr\u00e0 attraverso la rete, ma il tecnico del Data Center, responsabile della configurazione del server, pu\u00f2 subito copiare quest'immagine standard su uno dei dischi. Il caricamento avviene nella memoria RAM, dopo di che inizia il processo di ripristino:<\/p>\n<p><\/p>\n<ul>\n<li>viene inviata una richiesta per collegare un dispositivo di blocco tramite iscsinbd o un altro protocollo simile per il volume logico che contiene il file system radice del server guasto; poich\u00e9 il file system radice deve essere di dimensioni contenute, questa fase dovrebbe completarsi entro pochi minuti. Viene inoltre eseguito il ripristino del bootloader;<\/li>\n<li>viene ricreata la struttura dei volumi logici locali e si collegano i volumi logici dal server di backup tramite il modulo del kernel dm_clone: inizia il ripristino dei dati, e le modifiche vengono registrate immediatamente sui dischi locali<\/li>\n<li>si avvia un contenitore con tutti i dischi fisici disponibili: si ripristina completamente la funzionalit\u00e0 del server, ma con prestazioni ridotte;<\/li>\n<li>al termine della sincronizzazione dei dati, i volumi logici dal server di backup vengono scollegati, il contenitore viene spento e il server viene riavviato;<\/li>\n<\/ul>\n<p><\/p>\n<p>Dopo il riavvio, il server avr\u00e0 tutti i dati che erano presenti al momento della creazione del backup e includer\u00e0 tutte le modifiche effettuate durante il processo di ripristino.<\/p>\n<p>\n<b class=\"spoiler_title\">Altri articoli del ciclo<\/b><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/449282\/\">Backup, parte 1: Perch\u00e9 \u00e8 importante fare backup, panoramica dei metodi e tecnologie<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/452630\/\">Backup, parte 2: Panoramica e test degli strumenti di backup basati su rsync<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/454420\/\">Backup, parte 3: Panoramica e test di duplicity, duplicati<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/454734\/#first_unread\">Backup, parte 4: Panoramica e test di zbackup, restic, borgbackup<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/459550\/\">Backup, parte 5: Test di Bacula e Veeam Backup per Linux<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/468963\/\">Backup: parte su richiesta dei lettori: panoramica di AMANDA, UrBackup, BackupPC<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/470802\/\">Backup, parte 6: Confronto degli strumenti di backup<\/a><\/noindex><br \/>\nBackup, parte 7: Conclusioni<\/p>\n<p><\/p>\n<p>Vi invitiamo a discutere la proposta nei commenti, grazie per l'attenzione!<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/472776\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u0430\u043d\u043d\u0430\u044f \u0437\u0430\u043c\u0435\u0442\u043a\u0430 \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u0435\u0442 \u0446\u0438\u043a\u043b \u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0438. \u0412 \u043d\u0435\u0439 \u043f\u043e\u0439\u0434\u0435\u0442 \u0440\u0435\u0447\u044c \u043e \u043b\u043e\u0433\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0432\u044b\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430 (\u0438\u043b\u0438 VPS), \u0443\u0434\u043e\u0431\u043d\u043e\u0439 \u0434\u043b\u044f \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0431\u0443\u0434\u0435\u0442 \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d \u0432\u0430\u0440\u0438\u0430\u043d\u0442 \u0431\u044b\u0441\u0442\u0440\u043e\u0433\u043e \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0438\u0437 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0439 \u043a\u043e\u043f\u0438\u0438 \u0431\u0435\u0437 \u043e\u0441\u043e\u0431\u044b\u0445 \u043f\u0440\u043e\u0441\u0442\u043e\u0435\u0432 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0430\u0432\u0430\u0440\u0438\u0438. \u0418\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0412\u044b\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u0441\u0435\u0440\u0432\u0435\u0440 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0438\u043c\u0435\u0435\u0442 \u043c\u0438\u043d\u0438\u043c\u0443\u043c \u0434\u0432\u0430 \u0436\u0435\u0441\u0442\u043a\u0438\u0445 \u0434\u0438\u0441\u043a\u0430, \u0441\u043b\u0443\u0436\u0430\u0449\u0438\u0445 \u0434\u043b\u044f \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 RAID \u043c\u0430\u0441\u0441\u0438\u0432\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29456,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39250","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0414\u0430\u043d\u043d\u0430\u044f \u0437\u0430\u043c\u0435\u0442\u043a\u0430 \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u0435\u0442 \u0446\u0438\u043a\u043b \u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-7-vyvody\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\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 7: \u0412\u044b\u0432\u043e\u0434\u044b | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0414\u0430\u043d\u043d\u0430\u044f \u0437\u0430\u043c\u0435\u0442\u043a\u0430 \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u0435\u0442 \u0446\u0438\u043a\u043b \u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-7-vyvody\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:28:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:28:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Backup, parte 7: Considerazioni finali | ProHoster","description":"Questa nota conclude il ciclo su backup.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-7-vyvody","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 7: \u0412\u044b\u0432\u043e\u0434\u044b | ProHoster","og:description":"\u0414\u0430\u043d\u043d\u0430\u044f \u0437\u0430\u043c\u0435\u0442\u043a\u0430 \u0437\u0430\u0432\u0435\u0440\u0448\u0430\u0435\u0442 \u0446\u0438\u043a\u043b \u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/rezervnoe-kopirovanie-chast-7-vyvody","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:28:41+00:00","article:modified_time":"2019-10-31T19:28:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39250","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-24 01:28:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:53:37","updated":"2026-01-24 01:28: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\/39250","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=39250"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39250\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29456"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39250"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39250"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39250"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}