🥇Guida al backup dei database

– Oh, nessun rifugio resisterà all'impatto di un meteorite. Ma come per tutti, avete un backup, quindi potete stare tranquilli.
Stanislaw Lem, «Diari stellari di Ijon Tichy»

Il backup è la procedura che consente di salvare una copia dei dati in una posizione diversa da quella principale in cui sono archiviati.

L'obiettivo principale del backup è il ripristino dei dati dopo la loro perdita. Pertanto, spesso si sente dire che se si dispone di una replica del database, è sempre possibile recuperare i dati da essa, e il backup non è necessario. In realtà, il backup consente di affrontare almeno tre compiti che non possono essere risolti con una replica, e non si può nemmeno inizializzare una replica senza un backup.

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à nel database replica.

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ò che è particolarmente frustrante è 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 è affatto in fase di test, e i dati in esso contenuti sono preziosi.

Infine, il terzo compito che richiede un backup è il cloning del database, ad esempio, per scopi di testing.

Il backup dei database si basa, in un modo o nell'altro, su uno dei due principi:

Estrazione dei dati seguita da salvataggio in un formato arbitrario;
Snapshot dello stato dei file del database e salvataggio dei log.

Esaminiamo più da vicino questi principi e gli strumenti che li implementano.

Esportazione dei dati

Tra 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 è riportato un elenco di questi strumenti:

Formato binario
Formato testuale

Oracle
DataPump Export/DataPump Import
Esportazione/Importazione
SQL*Plus/SQL*Loader

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
scarico/caricamento
scarico/caricamento

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Il formato di testo è buono perché può essere modificato o persino creato da programmi esterni, mentre quello binario è vantaggioso poiché consente di scaricare e caricare i dati più rapidamente grazie al risparmio di risorse nella conversione dei formati.

Nonostante la semplicità e l'evidenza dell'idea di scaricare i dati, questo metodo è raramente utilizzato per il backup di basi di dati industriali cariche. Ecco i motivi per cui il caricamento non è adatto a un vero backup:

il processo di scarico genera un carico significativo sul sistema sorgente;
il caricamento richiede molto tempo: al momento della fine del caricamento, potrebbe essere già obsoleto;
effettuare uno scarico coerente dell'intero database sotto carico elevato è praticamente impossibile, poiché il DBMS è costretto a memorizzare un'istantanea del suo stato al momento dell'inizio dello scarico. Maggiore è il numero di transazioni eseguite dall'inizio dello scarico, maggiore sarà la dimensione dell'istantanea (copie di dati obsolete in PostgreSQL, spazio undo in Oracle, tempdb in Microsoft SQL Server, ecc.);
lo scarico mantiene la struttura logica dei dati, ma non conserva la loro struttura fisica: parametri di archiviazione fisica delle tabelle, indici, ecc.

Tuttavia, lo scarico ha anche i suoi vantaggi:

alta selettività: è possibile scaricare tabelle singole, singoli campi e persino singole righe;
i dati scaricati possono essere caricati in un database di un'altra versione, e se lo scarico è stato effettuato in formato di testo, anche in un altro database.

Pertanto, 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.

Il metodo di backup più comune per i database è la copia dei file del database.

Salvataggio "freddo" dei file del DB

L'idea evidente è fermare il database e copiare tutti i suoi file. Questo tipo di backup è chiamato "freddo". È un metodo estremamente affidabile e semplice, ma ha due evidenti svantaggi:

da un backup «a freddo» è 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 «a freddo»;
non tutte le banche dati hanno una finestra tecnologica in cui il database può essere fermato.

Se il backup «a freddo» è accettabile, è importante ricordare che

la copia «a freddo» a volte deve includere anche i log. I metodi per determinare quali log devono essere inclusi nel backup «a freddo» sono specifici per ogni SGBD. Ad esempio, in Oracle è necessario copiare i cosiddetti online redo, cioè un numero fisso di file di log in una cartella speciale, anche quando il database è stato arrestato correttamente. In PostgreSQL è 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.
la cartella del database può contenere file di spazi temporanei di dimensioni piuttosto elevate, che non è necessario includere nel backup. A proposito, questa osservazione vale anche per il backup «a caldo».

Salvataggio «a caldo» dei file

La maggior parte dei backup delle banche dati moderne viene eseguita copiando i file del database senza fermare il database. Qui ci sono diversi problemi:

Al momento dell'inizio della copia, il contenuto del database potrebbe non coincidere con il contenuto dei file, poiché parte delle informazioni si trova nella cache e non è ancora stata scritta su disco.
Durante la copia, il contenuto del database può cambiare. Se si utilizzano strutture dati modificabili, il contenuto dei file cambierà, mentre se si utilizzano strutture immutabili, il set di file cambierà: nuovi file appariranno e file vecchi verranno eliminati.
Poiché 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à sarà della vecchia versione della pagina e l'altra metà sarà della nuova.

Per garantire che il backup sia coerente, ogni SGBD ha un comando che indica che è iniziato il processo di backup. Sintatticamente, questo comando può apparire in modi diversi:

in Oracle si tratta di un comando separato ALTER DATABASE/TABLESPACE BEGIN BACKUP;
in PostgreSQL – funzione pg_start_backup();
In Microsoft SQL Server e DB2, la preparazione per il backup viene eseguita implicitamente durante l'esecuzione del comando BACKUP DATABASE;
In MySQL Enterprise, Cassandra e MongoDB, la preparazione viene eseguita implicitamente da un'utility esterna: mysqlbackup, OpsCenter e Ops Manager rispettivamente.

Nonostante le differenze di sintassi, il processo di preparazione del backup appare simile.

Ecco come si presenta la preparazione del backup nei DBMS con strutture disco modificabili, cioè in tutti i tradizionali sistemi relazionali a disco:

Viene memorizzato il momento iniziale del backup; la copia di sicurezza dovrà contenere i log del database a partire da quel momento.
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.
Viene attivata una modalità 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à l'intera pagina. Durante la procedura di preparazione, tutte le pagine vengono scaricate su disco, quindi alla prima modifica il blocco sarà sempre registrato completamente nel log. Ma se durante il backup la pagina viene nuovamente scritta su disco, la sua successiva modifica porterà 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à nuovamente corretto.
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.

Dopo aver eseguito tutte le procedure sopra elencate, è possibile copiare i file di dati utilizzando gli strumenti del sistema operativo – cp, rsync e altri. Attivare la modalità 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à più tempo, poiché le intestazioni dei file di dati non vengono aggiornate. Più velocemente si completa il backup, meglio è 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.

Al termine del backup, è 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.

Ecco come appare il diagramma temporale del processo di backup:

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à istantaneo.
Insieme ai file di dati, è 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.
È possibile ripristinare da questo backup al momento del ritorno del database a uno stato normale. Il ripristino a un momento precedente non è possibile.

Con i database che utilizzano strutture dati immutabili (snapshot di memoria, alberi LSM), la situazione è più semplice. La preparazione per il backup è composta dai seguenti passaggi:

I dati dalla memoria vengono scritti su disco.
Viene registrata la lista dei file inclusi nel backup. Finché il processo di backup non è completato, al database è proibito eliminare questi file, anche se non sono più necessari.

Al segnale di fine del backup, il database con strutture immutabili può nuovamente eliminare i file non necessari.

Ripristino a un punto

Il backup consente di ripristinare lo stato del database al momento in cui è stata completata la comanda di ritorno dalla modalità di backup. Tuttavia, un'interruzione, dopo la quale sarà necessario il ripristino, può verificarsi in qualsiasi momento. L'operazione di ripristino dello stato del DB a un momento arbitrario è chiamata "ripristino a un punto" (point-in-time recovery).

Per garantire tale possibilità, è 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 è stato ripristinato dal backup al momento della fine della copia, lo stato del database (file e pagine memorizzate nella cache) è garantito corretto, quindi non è necessaria una modalità speciale di registrazione. Applicando i log fino al momento desiderato, è possibile ottenere lo stato del database in qualsiasi punto nel tempo.

Se la velocità di ripristino del backup è limitata solo dalla larghezza di banda del disco, la velocità di applicazione dei log è 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 – 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, è necessario eseguire abbastanza frequentemente backup completi – almeno una volta a settimana per database con un carico di transazione leggero e fino a backup giornalieri per database ad alta intensità di carico.

Backup incrementale

Per accelerare il ripristino a un punto, sarebbe utile poter eseguire il backup il più spesso possibile, ma senza occupare spazio extra sui dischi e senza sovraccaricare il database con attività di backup.

La soluzione al problema è il backup incrementale, cioè la copia solo delle pagine di dati che sono state modificate dal precedente backup.
Il backup incrementale ha senso solo per i DBMS che utilizzano strutture dati modificabili.

L'incremento può essere basato su un backup completo (backup cumulativo) oppure su un qualsiasi backup precedente (backup differenziale).

Sfortunatamente, non esiste una terminologia unificata e diversi produttori utilizzano termini diversi:

Differenziale
Cumulativa

Oracle
Differential
Cumulative

PostgresPro
Incrementale
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Incrementale

Quando sono disponibili backup incrementali, il processo di ripristino a un punto appare come segue:

si ripristina l'ultimo backup completo effettuato prima del momento di ripristino;
sui backup completi vengono ripristinati i backup incrementali;
vengono ripristinati i log dal punto di inizio del backup fino al punto di ripristino.

La disponibilità di un backup cumulativo accelera il processo di ripristino. Ad esempio, per ripristinare lo stato del database a un punto tra T3 e T4 è necessario ripristinare due backup incrementali, mentre per ripristinare a un punto dopo T4 basta uno solo.
È evidente che il volume di un backup cumulativo è inferiore al volume di diversi backup differenziali, poiché alcune pagine sono cambiate più volte e ciascun backup incrementale contiene la propria versione della pagina.

Ci sono tre modalità per creare un backup incrementale:

creare un backup completo e calcolare la differenza con il backup completo precedente;
analizzare i log, creare un elenco delle pagine modificate e riservare le pagine incluse nell'elenco;
richiedere le pagine modificate nel database.

Il primo metodo risparmia spazio su disco, ma non risolve il problema di ridurre il carico sul database. Inoltre, se abbiamo un backup completo, è inutile trasformarlo in incrementale, perché il ripristino di un backup completo è più veloce rispetto al ripristino di un precedente backup completo e dell'incremento. La questione del risparmio dello spazio su disco con questo approccio è 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).

Il secondo e il terzo metodo si differenziano per il meccanismo di identificazione dell'elenco delle pagine modificate. L'analisi dei registri è più dispendiosa in termini di risorse, inoltre per la sua attuazione è necessario conoscere la struttura dei file di registro. Chiedere direttamente al database quali pagine siano cambiate è la soluzione più semplice, ma per questo il nucleo del DBMS deve disporre della funzionalità per il tracciamento delle modifiche ai blocchi (block change tracking).

La funzionalità di backup incrementale è 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 è necessario analizzare i registri.

PostgreSQL non traccia i blocchi modificati, quindi l'utility pg_probackup, sviluppata dalla società russa Postgres Professional, determina le pagine modificate analizzando il registro. Tuttavia, la società 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.

Anche Microsoft SQL Server, come Oracle, tiene traccia delle pagine modificate, ma il comando BACKUP consente solo di effettuare backup completi e cumulativi.

In DB2 è possibile attivare il tracciamento delle pagine modificate, ma è disattivato per impostazione predefinita. Dopo l'attivazione, DB2 consentirà di eseguire backup completi, differenziali e cumulativi.

Una importante differenza tra gli strumenti descritti in questo capitolo (eccetto pg_probackup) e gli strumenti di backup basati su file è che richiedono le immagini delle pagine dal database, piuttosto che leggere i dati direttamente dal disco. Lo svantaggio di questo approccio è un leggero carico aggiuntivo sul database. Tuttavia, questo svantaggio è ampiamente compensato dal fatto che la pagina letta è sempre corretta, quindi non è necessario attivare modalità di registrazione speciali durante il backup.

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.

La migliore attuazione dell'idea di backup incrementale al giorno d'oggi è 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 è un cluster server con un grande volume di dischi, sui quali è installata una versione modificata del software Recovery Manager e può 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 è 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.

A onor del vero, bisogna notare che anche pg_probackup sa unire le copie incrementali.

A differenza di molte domande simili, la questione "qual è il miglior metodo di backup" ha una risposta inequivocabile: il migliore è l'utility nativa del DBMS utilizzato, che offre la possibilità di effettuare backup incrementali.

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ù importanti. Ma queste questioni vanno oltre l'ambito di questo articolo.

Fonte: habr.com