{"id":92367,"date":"2020-08-26T07:42:09","date_gmt":"2020-08-26T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh"},"modified":"2020-08-26T07:42:09","modified_gmt":"2020-08-26T05:42:09","slug":"putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","title":{"rendered":"Guida al backup dei database","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<blockquote><p>\u2013 Oh, nessun rifugio resister\u00e0 all'impatto di un meteorite. Ma come per tutti, avete un backup, quindi potete stare tranquilli.<\/p>\n<p><i>Stanislaw Lem, \u00abDiari stellari di Ijon Tichy\u00bb<\/i><\/p><\/blockquote>\n<p>\nIl backup \u00e8 la procedura che consente di salvare una copia dei dati in una posizione diversa da quella principale in cui sono archiviati.<\/p>\n<p><img decoding=\"async\" alt=\"Guida al backup dei database\" src=\"\/wp-content\/uploads\/2020\/08\/c1dba0d8999cab69315560dfc57546e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'obiettivo principale del backup \u00e8 il ripristino dei dati dopo la loro perdita. Pertanto, spesso si sente dire che se si dispone di una replica del database, \u00e8 sempre possibile recuperare i dati da essa, e il backup non \u00e8 necessario. In realt\u00e0, il backup consente di affrontare almeno tre compiti che non possono essere risolti con una replica, e non si pu\u00f2 nemmeno inizializzare una replica senza un backup.<\/p>\n<p>In primo luogo, un backup consente di ripristinare i dati dopo un errore logico. Ad esempio, un contabile ha eliminato un gruppo di registrazioni o l'amministratore del database ha distrutto uno spazio tabellare. Entrambe le operazioni sono assolutamente legittime dal punto di vista del database, e il processo di replica le riprodurr\u00e0 nel database replica.<\/p>\n<p>In secondo luogo, i moderni sistemi di gestione di database (SGBD) sono complessi software assai affidabili, ma occasionalmente si verificano danni alle strutture interne del database, dopo i quali l'accesso ai dati viene perso. Ci\u00f2 che \u00e8 particolarmente frustrante \u00e8 che tali violazioni avvengono solitamente in condizioni di elevato carico o durante l'installazione di qualche aggiornamento. Ma sia un alto carico che aggiornamenti regolari significano che il database non \u00e8 affatto in fase di test, e i dati in esso contenuti sono preziosi.<\/p>\n<p>Infine, il terzo compito che richiede un backup \u00e8 il cloning del database, ad esempio, per scopi di testing.<\/p>\n<p>Il backup dei database si basa, in un modo o nell'altro, su uno dei due principi:<\/p>\n<ul>\n<li>Estrazione dei dati seguita da salvataggio in un formato arbitrario;<\/li>\n<li>Snapshot dello stato dei file del database e salvataggio dei log.<\/li>\n<\/ul>\n<p>\nEsaminiamo pi\u00f9 da vicino questi principi e gli strumenti che li implementano.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Esportazione dei dati<\/h3>\n<p>\nTra gli strumenti forniti con qualsiasi SGBD, ci sono sicuramente strumenti per l'esportazione e l'importazione dei dati. I dati possono essere salvati in un formato testuale o in un formato binario specifico per il particolare SGBD. Nella tabella sottostante \u00e8 riportato un elenco di questi strumenti:<\/p>\n<p>Formato binario<br \/>\nFormato testuale<\/p>\n<p>Oracle<br \/>\nDataPump Export\/DataPump Import<br \/>\nEsportazione\/Importazione<br \/>\nSQL*Plus\/SQL*Loader<\/p>\n<p>PostgreSQL<br \/>\npg_dump, pg_dumpall\/pg_restore<br \/>\npg_dump, pg_dumpall\/psql<\/p>\n<p>Microsoft SQL Server<br \/>\nbcp<br \/>\nbcp<\/p>\n<p>DB2<br \/>\nscarico\/caricamento<br \/>\nscarico\/caricamento<\/p>\n<p>MySQL<\/p>\n<p>mysqldump, mysqlpump\/mysql, mysqlimport<\/p>\n<p>MongoDB<br \/>\nmongodump\/mongorestore<br \/>\nmongoexport\/mongoimport<\/p>\n<p>Cassandra<br \/>\nnodetool snapshot\/sstableloader<br \/>\ncqlsh<\/p>\n<p>\nIl formato di testo \u00e8 buono perch\u00e9 pu\u00f2 essere modificato o persino creato da programmi esterni, mentre quello binario \u00e8 vantaggioso poich\u00e9 consente di scaricare e caricare i dati pi\u00f9 rapidamente grazie al risparmio di risorse nella conversione dei formati.<\/p>\n<p>Nonostante la semplicit\u00e0 e l'evidenza dell'idea di scaricare i dati, questo metodo \u00e8 raramente utilizzato per il backup di basi di dati industriali cariche. Ecco i motivi per cui il caricamento non \u00e8 adatto a un vero backup:<\/p>\n<ul>\n<li>il processo di scarico genera un carico significativo sul sistema sorgente;<\/li>\n<li>il caricamento richiede molto tempo: al momento della fine del caricamento, potrebbe essere gi\u00e0 obsoleto;<\/li>\n<li>effettuare uno scarico coerente dell'intero database sotto carico elevato \u00e8 praticamente impossibile, poich\u00e9 il DBMS \u00e8 costretto a memorizzare un'istantanea del suo stato al momento dell'inizio dello scarico. Maggiore \u00e8 il numero di transazioni eseguite dall'inizio dello scarico, maggiore sar\u00e0 la dimensione dell'istantanea (copie di dati obsolete in PostgreSQL, spazio undo in Oracle, tempdb in Microsoft SQL Server, ecc.);<\/li>\n<li>lo scarico mantiene la struttura logica dei dati, ma non conserva la loro struttura fisica: parametri di archiviazione fisica delle tabelle, indici, ecc.<\/li>\n<\/ul>\n<p>\nTuttavia, lo scarico ha anche i suoi vantaggi:<\/p>\n<ul>\n<li>alta selettivit\u00e0: \u00e8 possibile scaricare tabelle singole, singoli campi e persino singole righe;<\/li>\n<li>i dati scaricati possono essere caricati in un database di un'altra versione, e se lo scarico \u00e8 stato effettuato in formato di testo, anche in un altro database.<\/li>\n<\/ul>\n<p>\nPertanto, lo scarico viene utilizzato principalmente per compiti come il backup di piccole tabelle (ad esempio, elenchi) o per la distribuzione di set di dati con il successivo rilascio dell'applicazione. <\/p>\n<p>Il metodo di backup pi\u00f9 comune per i database \u00e8 la copia dei file del database.<\/p>\n<h3>Salvataggio \"freddo\" dei file del DB<\/h3>\n<p>\nL'idea evidente \u00e8 fermare il database e copiare tutti i suoi file. Questo tipo di backup \u00e8 chiamato \"freddo\". \u00c8 un metodo estremamente affidabile e semplice, ma ha due evidenti svantaggi:<\/p>\n<ul>\n<li>da un backup \u00aba freddo\u00bb \u00e8 possibile ripristinare solo lo stato del database che esisteva al momento dello stop; le transazioni effettuate dopo il riavvio del database non saranno incluse nel backup \u00aba freddo\u00bb;<\/li>\n<li>non tutte le banche dati hanno una finestra tecnologica in cui il database pu\u00f2 essere fermato.<\/li>\n<\/ul>\n<p>\nSe il backup \u00aba freddo\u00bb \u00e8 accettabile, \u00e8 importante ricordare che<\/p>\n<ul>\n<li>la copia \u00aba freddo\u00bb a volte deve includere anche i log. I metodi per determinare quali log devono essere inclusi nel backup \u00aba freddo\u00bb sono specifici per ogni SGBD. Ad esempio, in Oracle \u00e8 necessario copiare i cosiddetti online redo, cio\u00e8 un numero fisso di file di log in una cartella speciale, anche quando il database \u00e8 stato arrestato correttamente. In PostgreSQL \u00e8 necessario conservare tutti i log a partire da quello che contiene l'ultimo punto di controllo, le cui informazioni sono contenute nel file di gestione.<\/li>\n<li>la cartella del database pu\u00f2 contenere file di spazi temporanei di dimensioni piuttosto elevate, che non \u00e8 necessario includere nel backup. A proposito, questa osservazione vale anche per il backup \u00aba caldo\u00bb.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Salvataggio \u00aba caldo\u00bb dei file<\/h3>\n<p>\nLa maggior parte dei backup delle banche dati moderne viene eseguita copiando i file del database senza fermare il database. Qui ci sono diversi problemi:<\/p>\n<ul>\n<li>Al momento dell'inizio della copia, il contenuto del database potrebbe non coincidere con il contenuto dei file, poich\u00e9 parte delle informazioni si trova nella cache e non \u00e8 ancora stata scritta su disco.<\/li>\n<li>Durante la copia, il contenuto del database pu\u00f2 cambiare. Se si utilizzano strutture dati modificabili, il contenuto dei file cambier\u00e0, mentre se si utilizzano strutture immutabili, il set di file cambier\u00e0: nuovi file appariranno e file vecchi verranno eliminati.<\/li>\n<li>Poich\u00e9 la scrittura dei dati nel database e la lettura dei file del DB non sono sincronizzate, il programma di backup potrebbe leggere una pagina errata, in cui met\u00e0 sar\u00e0 della vecchia versione della pagina e l'altra met\u00e0 sar\u00e0 della nuova.<\/li>\n<\/ul>\n<p>\nPer garantire che il backup sia coerente, ogni SGBD ha un comando che indica che \u00e8 iniziato il processo di backup. Sintatticamente, questo comando pu\u00f2 apparire in modi diversi: <\/p>\n<ul>\n<li>in Oracle si tratta di un comando separato ALTER DATABASE\/TABLESPACE BEGIN BACKUP;<\/li>\n<li>in PostgreSQL \u2013 funzione pg_start_backup();<\/li>\n<li>In Microsoft SQL Server e DB2, la preparazione per il backup viene eseguita implicitamente durante l'esecuzione del comando BACKUP DATABASE;<\/li>\n<li>In MySQL Enterprise, Cassandra e MongoDB, la preparazione viene eseguita implicitamente da un'utility esterna: mysqlbackup, OpsCenter e Ops Manager rispettivamente.<\/li>\n<\/ul>\n<p>\nNonostante le differenze di sintassi, il processo di preparazione del backup appare simile.<\/p>\n<p>Ecco come si presenta la preparazione del backup nei DBMS con strutture disco modificabili, cio\u00e8 in tutti i tradizionali sistemi relazionali a disco:<\/p>\n<ol>\n<li>Viene memorizzato il momento iniziale del backup; la copia di sicurezza dovr\u00e0 contenere i log del database a partire da quel momento.<\/li>\n<li>Viene eseguito un checkpoint, ovvero tutte le modifiche avvenute nelle pagine dati prima del momento registrato vengono scritte su disco. Questo garantisce che i log fino al momento dell'inizio del backup non saranno necessari al momento del ripristino.<\/li>\n<li>Viene attivata una modalit\u00e0 di registrazione speciale: se una pagina dati viene modificata per la prima volta dopo il caricamento dal disco, invece di registrare le modifiche della pagina nel log, il database registrer\u00e0 l'intera pagina. Durante la procedura di preparazione, tutte le pagine vengono scaricate su disco, quindi alla prima modifica il blocco sar\u00e0 sempre registrato completamente nel log. Ma se durante il backup la pagina viene nuovamente scritta su disco, la sua successiva modifica porter\u00e0 anch'essa alla registrazione di una copia completa della pagina nel log. Questo garantisce che, se per caso si verifichi un errore nel file dati durante la copia, l'applicazione del log lo render\u00e0 nuovamente corretto.<\/li>\n<li>Viene bloccata la modifica delle intestazioni dei file dati, ovvero quella parte il cui cambiamento non si riflette nei log. Questo garantisce che l'intestazione venga copiata correttamente e che successivamente i log vengano applicati correttamente al file dati.<\/li>\n<\/ol>\n<p>\nDopo aver eseguito tutte le procedure sopra elencate, \u00e8 possibile copiare i file di dati utilizzando gli strumenti del sistema operativo \u2013 cp, rsync e altri. Attivare la modalit\u00e0 di backup riduce le prestazioni del database: da un lato, aumenta il volume dei log e, dall'altro, se si verifica un guasto durante il backup, il ripristino richieder\u00e0 pi\u00f9 tempo, poich\u00e9 le intestazioni dei file di dati non vengono aggiornate. Pi\u00f9 velocemente si completa il backup, meglio \u00e8 per il database; pertanto, qui si possono utilizzare strumenti come il snapshot del file system o il mirroring (BCV) nel array di dischi. Alcuni DBMS (Oracle, PostgreSQL) consentono all'amministratore di scegliere il metodo di copia, mentre altri (Microsoft SQL Server) forniscono un'interfaccia per integrare le proprie utility di backup con i meccanismi dei file system o degli storage.<\/p>\n<p>Al termine del backup, \u00e8 necessario riportare il database in uno stato normale. In Oracle, questo avviene con il comando ALTER DATABASE\/TABLESPACE END BACKUP, in PostgreSQL con la funzione pg_stop_backup(), mentre in altri database si utilizzano sotto-programmi interni delle relative comandi o servizi esterni.<\/p>\n<p>Ecco come appare il diagramma temporale del processo di backup:<\/p>\n<p><img decoding=\"async\" alt=\"Guida al backup dei database\" src=\"\/wp-content\/uploads\/2020\/08\/4e74f865e9f35acec083b747da4449cf.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>La preparazione per il backup (begin backup) richiede tempo, talvolta anche considerevole. Anche quando si utilizzano volumi speculari o file system che supportano snapshot, il processo di backup non sar\u00e0 istantaneo.<\/li>\n<li>Insieme ai file di dati, \u00e8 necessario conservare i log a partire dall'inizio della preparazione per il backup fino al momento in cui il database torna a uno stato normale.<\/li>\n<li>\u00c8 possibile ripristinare da questo backup <b>al momento del ritorno del database a uno stato normale<\/b>. Il ripristino a un momento precedente non \u00e8 possibile.<\/li>\n<\/ul>\n<p>\nCon i database che utilizzano strutture dati immutabili (snapshot di memoria, alberi LSM), la situazione \u00e8 pi\u00f9 semplice. La preparazione per il backup \u00e8 composta dai seguenti passaggi:<\/p>\n<ol>\n<li>I dati dalla memoria vengono scritti su disco.<\/li>\n<li>Viene registrata la lista dei file inclusi nel backup. Finch\u00e9 il processo di backup non \u00e8 completato, al database \u00e8 proibito eliminare questi file, anche se non sono pi\u00f9 necessari.<\/li>\n<\/ol>\n<p>\nAl segnale di fine del backup, il database con strutture immutabili pu\u00f2 nuovamente eliminare i file non necessari.<\/p>\n<h3>Ripristino a un punto<\/h3>\n<p>\nIl backup consente di ripristinare lo stato del database al momento in cui \u00e8 stata completata la comanda di ritorno dalla modalit\u00e0 di backup. Tuttavia, un'interruzione, dopo la quale sar\u00e0 necessario il ripristino, pu\u00f2 verificarsi in qualsiasi momento. L'operazione di ripristino dello stato del DB a un momento arbitrario \u00e8 chiamata \"ripristino a un punto\" (point-in-time recovery).<\/p>\n<p>Per garantire tale possibilit\u00e0, \u00e8 necessario conservare i log del DB a partire dal momento della fine del backup e, durante il processo di ripristino, continuare ad applicare i log alla copia ripristinata. Dopo che il DB \u00e8 stato ripristinato dal backup al momento della fine della copia, lo stato del database (file e pagine memorizzate nella cache) \u00e8 garantito corretto, quindi non \u00e8 necessaria una modalit\u00e0 speciale di registrazione. Applicando i log fino al momento desiderato, \u00e8 possibile ottenere lo stato del database in qualsiasi punto nel tempo.<\/p>\n<p>Se la velocit\u00e0 di ripristino del backup \u00e8 limitata solo dalla larghezza di banda del disco, la velocit\u00e0 di applicazione dei log \u00e8 generalmente limitata dalle prestazioni della CPU. Se le modifiche nel database principale avvengono in parallelo, durante il ripristino tutte le modifiche vengono eseguite in modo sequenziale \u2013 nell'ordine di lettura dal log. Pertanto, il tempo di ripristino dipende linearmente da quanto la posizione di ripristino si discosta dalla fine del backup. Di conseguenza, \u00e8 necessario eseguire abbastanza frequentemente backup completi \u2013 almeno una volta a settimana per database con un carico di transazione leggero e fino a backup giornalieri per database ad alta intensit\u00e0 di carico.<\/p>\n<h3>Backup incrementale<\/h3>\n<p>\nPer accelerare il ripristino a un punto, sarebbe utile poter eseguire il backup il pi\u00f9 spesso possibile, ma senza occupare spazio extra sui dischi e senza sovraccaricare il database con attivit\u00e0 di backup.<\/p>\n<p>La soluzione al problema \u00e8 il backup incrementale, cio\u00e8 la copia solo delle pagine di dati che sono state modificate dal precedente backup.<br \/>\nIl backup incrementale ha senso solo per i DBMS che utilizzano strutture dati modificabili.<\/p>\n<p>L'incremento pu\u00f2 essere basato su un backup completo (backup cumulativo) oppure su un qualsiasi backup precedente (backup differenziale). <\/p>\n<p><img decoding=\"async\" alt=\"Guida al backup dei database\" src=\"\/wp-content\/uploads\/2020\/08\/10e3bb87445cb36693c7b5469d62eeaf.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSfortunatamente, non esiste una terminologia unificata e diversi produttori utilizzano termini diversi:<\/p>\n<p>Differenziale<br \/>\nCumulativa<\/p>\n<p>Oracle<br \/>\nDifferential<br \/>\nCumulative<\/p>\n<p>PostgresPro<br \/>\nIncrementale<br \/>\n\u2014<\/p>\n<p>Microsoft SQL Server<br \/>\n\u2014<br \/>\nDifferential<\/p>\n<p>IBM DB2<br \/>\nDelta<br \/>\nIncrementale<\/p>\n<p>\nQuando sono disponibili backup incrementali, il processo di ripristino a un punto appare come segue:<\/p>\n<ul>\n<li>si ripristina l'ultimo backup completo effettuato prima del momento di ripristino;<\/li>\n<li>sui backup completi vengono ripristinati i backup incrementali;<\/li>\n<li>vengono ripristinati i log dal punto di inizio del backup fino al punto di ripristino.<\/li>\n<\/ul>\n<p>\nLa disponibilit\u00e0 di un backup cumulativo accelera il processo di ripristino. Ad esempio, per ripristinare lo stato del database a un punto tra T3 e T4 \u00e8 necessario ripristinare due backup incrementali, mentre per ripristinare a un punto dopo T4 basta uno solo.<br \/>\n\u00c8 evidente che il volume di un backup cumulativo \u00e8 inferiore al volume di diversi backup differenziali, poich\u00e9 alcune pagine sono cambiate pi\u00f9 volte e ciascun backup incrementale contiene la propria versione della pagina.<\/p>\n<p>Ci sono tre modalit\u00e0 per creare un backup incrementale:<\/p>\n<ol>\n<li>creare un backup completo e calcolare la differenza con il backup completo precedente;<\/li>\n<li>analizzare i log, creare un elenco delle pagine modificate e riservare le pagine incluse nell'elenco;<\/li>\n<li>richiedere le pagine modificate nel database.<\/li>\n<\/ol>\n<p>\nIl primo metodo risparmia spazio su disco, ma non risolve il problema di ridurre il carico sul database. Inoltre, se abbiamo un backup completo, \u00e8 inutile trasformarlo in incrementale, perch\u00e9 il ripristino di un backup completo \u00e8 pi\u00f9 veloce rispetto al ripristino di un precedente backup completo e dell'incremento. La questione del risparmio dello spazio su disco con questo approccio \u00e8 meglio attribuirla a componenti speciali con meccanismi integrati di deduplicazione. Questi possono essere sia sistemi di archiviazione speciali (EMC DataDomain, HPE StorageWorks VLS, tutta la gamma NetApp) che prodotti software (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).<\/p>\n<p>Il secondo e il terzo metodo si differenziano per il meccanismo di identificazione dell'elenco delle pagine modificate. L'analisi dei registri \u00e8 pi\u00f9 dispendiosa in termini di risorse, inoltre per la sua attuazione \u00e8 necessario conoscere la struttura dei file di registro. Chiedere direttamente al database quali pagine siano cambiate \u00e8 la soluzione pi\u00f9 semplice, ma per questo il nucleo del DBMS deve disporre della funzionalit\u00e0 per il tracciamento delle modifiche ai blocchi (block change tracking).<\/p>\n<p>La funzionalit\u00e0 di backup incrementale \u00e8 stata creata per la prima volta nel software Oracle Recovery Manager (RMAN), presentato con il rilascio di Oracle 8i. Oracle ha implementato immediatamente il tracciamento dei blocchi modificati, dunque non \u00e8 necessario analizzare i registri.<\/p>\n<p>PostgreSQL non traccia i blocchi modificati, quindi l'utility pg_probackup, sviluppata dalla societ\u00e0 russa Postgres Professional, determina le pagine modificate analizzando il registro. Tuttavia, la societ\u00e0 fornisce anche il DBMS PostgresPro, che include l'estensione ptrack, che tiene traccia delle modifiche alle pagine. Quando si utilizza pg_probackup con PostgresPro, l'utility richiede le pagine modificate direttamente al database, esattamente come fa RMAN.<\/p>\n<p>Anche Microsoft SQL Server, come Oracle, tiene traccia delle pagine modificate, ma il comando BACKUP consente solo di effettuare backup completi e cumulativi.<\/p>\n<p>In DB2 \u00e8 possibile attivare il tracciamento delle pagine modificate, ma \u00e8 disattivato per impostazione predefinita. Dopo l'attivazione, DB2 consentir\u00e0 di eseguire backup completi, differenziali e cumulativi.<\/p>\n<p>Una importante differenza tra gli strumenti descritti in questo capitolo (eccetto pg_probackup) e gli strumenti di backup basati su file \u00e8 che richiedono le immagini delle pagine dal database, piuttosto che leggere i dati direttamente dal disco. Lo svantaggio di questo approccio \u00e8 un leggero carico aggiuntivo sul database. Tuttavia, questo svantaggio \u00e8 ampiamente compensato dal fatto che la pagina letta \u00e8 sempre corretta, quindi non \u00e8 necessario attivare modalit\u00e0 di registrazione speciali durante il backup.<\/p>\n<p>Ricordate ancora una volta che la presenza di copie incrementali non annulla i requisiti di avere registri per recuperare a un punto specifico nel tempo. Pertanto, nei database di produzione, i registri vengono continuamente riscritti su un supporto esterno, e le copie di backup, complete e\/o incrementali, vengono create secondo un programma.<\/p>\n<p>La migliore attuazione dell'idea di backup incrementale al giorno d'oggi \u00e8 il sistema software e hardware (nella terminologia Oracle - engineered system) Zero Data Loss Recovery Appliance - una soluzione specializzata di Oracle per il backup del proprio database. Il sistema \u00e8 un cluster <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1521\">server<\/a> con un grande volume di dischi, sui quali \u00e8 installata una versione modificata del software Recovery Manager e pu\u00f2 lavorare sia con altri sistemi software e hardware di Oracle (Database Appliance, Exadata, SPARC Supercluster), sia con database Oracle su infrastrutture tradizionali. A differenza di un RMAN \"normale\", in ZDLRA \u00e8 stata implementata la concezione di \"incremento eterno\" (incremental forever). Il sistema crea una copia completa del database una sola volta, e poi effettua solo copie incrementali. Moduli aggiuntivi di RMAN consentono di combinare le copie, creando nuove copie complete a partire da quelle incrementali. <\/p>\n<p>A onor del vero, bisogna notare che anche pg_probackup sa unire le copie incrementali.<\/p>\n<p><img decoding=\"async\" alt=\"Guida al backup dei database\" src=\"\/wp-content\/uploads\/2020\/08\/275b649ce74614c04410618a062dddbd.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA differenza di molte domande simili, la questione \"qual \u00e8 il miglior metodo di backup\" ha una risposta inequivocabile: il migliore \u00e8 l'utility nativa del DBMS utilizzato, che offre la possibilit\u00e0 di effettuare backup incrementali.<\/p>\n<p>Per l'amministratore di database, domande come la scelta della strategia di backup e l'integrazione dei mezzi di backup dei database nell'infrastruttura aziendale sono molto pi\u00f9 importanti. Ma queste questioni vanno oltre l'ambito di questo articolo.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/516428\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430. \u041d\u043e \u0432\u0435\u0434\u044c \u0443 \u0432\u0430\u0441, \u043a\u0430\u043a \u0438 \u0443 \u043a\u0430\u0436\u0434\u043e\u0433\u043e, \u0435\u0441\u0442\u044c \u0440\u0435\u0437\u0435\u0440\u0432, \u0442\u0430\u043a \u0447\u0442\u043e \u043c\u043e\u0436\u0435\u0442\u0435 \u043d\u0435 \u0431\u0435\u0441\u043f\u043e\u043a\u043e\u0438\u0442\u044c\u0441\u044f. \u0421\u0442\u0430\u043d\u0438\u0441\u043b\u0430\u0432 \u041b\u0435\u043c, \u00ab\u0417\u0432\u0451\u0437\u0434\u043d\u044b\u0435 \u0434\u043d\u0435\u0432\u043d\u0438\u043a\u0438 \u0418\u0439\u043e\u043d\u0430 \u0422\u0438\u0445\u043e\u0433\u043e\u00bb \u0420\u0435\u0437\u0435\u0440\u0432\u043d\u044b\u043c \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435\u043c \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u043a\u043e\u043f\u0438\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0433\u0434\u0435-\u0442\u043e \u0432\u043d\u0435 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0433\u043e \u043c\u0435\u0441\u0442\u0430 \u0438\u0445 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f. \u0413\u043b\u0430\u0432\u043d\u043e\u0435 \u043d\u0430\u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435 \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0433\u043e \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u2013 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u043f\u043e\u0441\u043b\u0435 \u0438\u0445 \u043f\u043e\u0442\u0435\u0440\u0438. \u0412 \u0441\u0432\u044f\u0437\u0438 \u0441 \u044d\u0442\u0438\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92368,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92367","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.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.\" \/>\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\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.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\u041f\u0443\u0442\u0435\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u043f\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c\u0443 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh\" \/>\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=\"2020-08-26T05:42:09+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-26T05:42:09+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\udd47Guida al backup dei database | ProHoster","description":"\u2013 Oh, nessun rifugio resister\u00e0 all'impatto di un meteorite.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","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\u041f\u0443\u0442\u0435\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c \u043f\u043e \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u043c\u0443 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 | ProHoster","og:description":"\u2013 \u041e, \u043d\u0438\u043a\u0430\u043a\u043e\u0435 \u0443\u0431\u0435\u0436\u0438\u0449\u0435 \u043d\u0435 \u0432\u044b\u0434\u0435\u0440\u0436\u0438\u0442 \u043f\u043e\u043f\u0430\u0434\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u0435\u043e\u0440\u0438\u0442\u0430.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/putevoditel-po-rezervnomu-kopirovaniyu-baz-dannyh","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-08-26T05:42:09+00:00","article:modified_time":"2020-08-26T05:42:09+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92367","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 12:09:36","updated":"2026-02-09 16:50:36","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\/92367","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=92367"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/92367\/revisions"}],"predecessor-version":[{"id":158765,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/92367\/revisions\/158765"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/92368"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=92367"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=92367"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=92367"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}