🥇Guida al backup dei database

– Oh, nessun rifugio può resistere all'impatto di un meteorite. Ma come tutti, anche voi avete un backup, quindi non dovete preoccuparvi.
Stanisław Lem, «Diari stellari di Ijon Tichy»

Per backup si intende la conservazione di una copia dei dati in un luogo diverso da quello principale in cui sono memorizzati.

L'obiettivo principale del backup è il ripristino dei dati dopo una loro perdita. A tale proposito, si sente spesso dire che, grazie alla replica del database, è sempre possibile recuperare i dati e che il backup non è necessario. In realtà, il backup consente di affrontare almeno tre problemi che non possono essere risolti con la replica, e non è possibile 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 insieme di registrazioni o un amministratore di database ha distrutto uno spazio tabellare. Entrambe le operazioni sono assolutamente legittime dal punto di vista del database, e il processo di replica riprodurrà queste operazioni nel database replica.

In secondo luogo, i moderni sistemi di gestione dei database sono molto affidabili, tuttavia a volte si verificano danni alle strutture interne del database, facendo sì che l'accesso ai dati venga perso. Ciò che è particolarmente deludente è che queste violazioni avvengono solitamente sotto alta carico o durante l'installazione di un aggiornamento. Ma sia l'alta carico che gli aggiornamenti regolari indicano che il database non è affatto un ambiente di test e i dati in esso contenuti sono preziosi.

Infine, il terzo compito, la cui risoluzione richiede una copia di backup, è la clonazione del database, ad esempio per scopi di test.

Il backup dei database si basa in qualche modo su uno dei due principi:

Estrazione dei dati seguita dal salvataggio in un formato arbitrario;
Cattura dello stato dei file del database e salvataggio dei registri.

Esaminiamo questi principi e gli strumenti che li attuano più in dettaglio.

Esportazione dei dati

Nel pacchetto di strumenti accompagnatori per qualsiasi DBMS, ci sono certamente 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 singolo DBMS. Nella tabella qui sotto è riportato un elenco di tali strumenti:

Formato binario
Formato testuale

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

PostgreSQL
pg_dump, pg_dumpall/pg_restore
pg_dump, pg_dumpall/psql

Microsoft SQL Server
bcp
bcp

DB2
unload/load
unload/load

MySQL

mysqldump, mysqlpump/mysql, mysqlimport

MongoDB
mongodump/mongorestore
mongoexport/mongoimport

Cassandra
nodetool snapshot/sstableloader
cqlsh

Il formato testuale è vantaggioso perché può essere modificato o persino creato da programmi esterni, mentre il formato binario è utile poiché consente di esportare e importare dati più velocemente grazie al risparmio di risorse nella conversione dei formati.

Nonostante la semplicità e l'ovvietà dell'idea di esportazione dei dati, questo metodo è raramente utilizzato per il backup di database industriali ad alto carico. Ecco i motivi per cui l'esportazione non è adatta per un'adeguata copia di sicurezza:

il processo di esportazione crea un carico significativo sul sistema sorgente;
l'esportazione richiede tempo – al momento del completamento, i dati saranno già obsoleti;
è praticamente impossibile eseguire un'estrazione coerente dell'intero database in caso di carico elevato, poiché il DBMS è costretto a mantenere un'istantanea del suo stato al momento dell'inizio dell'estrazione. Più transazioni sono state effettuate dall'inizio dell'estrazione, maggiore è il volume dell'istantanea (copia di dati non aggiornati in PostgreSQL, spazio undo in Oracle, tempdb in Microsoft SQL Server, ecc.);
l'estrazione conserva la struttura logica dei dati, ma non ne mantiene la struttura fisica: parametri di archiviazione fisica delle tabelle, indici e altro.

Tuttavia, l'estrazione ha anche i suoi vantaggi:

alta selettività: è possibile estrarre singole tabelle, singoli campi e persino singole righe;
i dati estratti possono essere caricati in un database di versione diversa, e se l'estrazione è stata effettuata in formato testo, anche in un altro database.

Pertanto, l'estrazione è principalmente utilizzata per compiti come il backup di piccole tabelle (ad esempio, dizionari) o la distribuzione di set di dati con una nuova versione dell'applicazione.

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

Backup "a freddo" dei file del DB

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

da un backup "a freddo" è possibile ripristinare solo lo stato del database che esisteva al momento della fermata; le transazioni effettuate dopo il riavvio del database non verranno incluse nel backup "a freddo";
non tutti i database dispongono di una finestra tecnologica in cui è possibile fermare il database.

Se il backup "a freddo" è soddisfacente, è necessario ricordare che

il backup "a freddo" deve talvolta includere anche i log. I metodi per determinare quali log debbano essere inclusi nel backup "a freddo" sono individuali per ciascun SGBD. Ad esempio, in Oracle è necessario copiare i cosiddetti online redo, ossia una quantità fissa di file di log in una cartella speciale, anche quando il database è stato arrestato correttamente. In PostgreSQL è necessario salvare tutti i log a partire da quello contenente l'ultima checkpoint, le cui informazioni sono contenute nel file di controllo.
Il catalogo del database può contenere file piuttosto grandi degli spazi temporanei, che non è necessario includere nel backup. A proposito, questa osservazione è valida anche per il backup 'hot'.

Salvataggio 'hot' dei file

La maggior parte dei backup dei moderni database 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 corrispondere al contenuto dei file, poiché alcune informazioni sono nella cache e non sono ancora state scritte su disco.
Durante la copia, il contenuto del database può cambiare. Se vengono utilizzate strutture dati modificabili, il contenuto dei file cambia, mentre con strutture immutabili cambia l'insieme dei file: nuovi file appaiono e file vecchi vengono eliminati.
Poiché la scrittura di 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à della nuova.

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

in Oracle, si tratta del comando separato ALTER DATABASE/TABLESPACE BEGIN BACKUP;
in PostgreSQL – la funzione pg_start_backup();
in Microsoft SQL Server e DB2, la preparazione per il backup avviene implicitamente durante l'esecuzione del comando BACKUP DATABASE;
in MySQL Enterprise, Cassandra e MongoDB, la preparazione avviene implicitamente tramite utilità esterne – mysqlbackup, OpsCenter e Ops Manager rispettivamente.

Nonostante le differenze sintattiche, il processo di preparazione per il backup appare lo stesso.

Ecco come si presenta la preparazione per il backup in DBMS con strutture di disco modificabili, cioè in tutti i tradizionali sistemi relazionali su disco:

Viene registrato il momento dell'inizio del backup; il backup deve contenere i registri del database a partire da questo momento.
Viene eseguito un checkpoint, il che significa che tutte le modifiche avvenute nelle pagine dei dati fino al momento salvato vengono scritte su disco. Ciò garantisce che i log fino all'inizio del backup non siano necessari durante il ripristino.
Viene attivata una modalità di registrazione speciale: se la pagina dei 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 preparatoria, tutte le pagine vengono scritte su disco, quindi alla prima modifica il blocco sarà sempre registrato nel log per intero. Ma se durante il processo di backup la pagina viene nuovamente scritta su disco, la sua successiva modifica porterà anche alla registrazione nel log di una copia completa della pagina. Questo garantisce che, se durante la copia del file dati la pagina risulta errata, l'applicazione del log la ripristinerà correttamente.
È bloccata la modifica delle intestazioni dei file di dati, ovvero quella parte di essa che non viene riflessa nei registri. Questo garantisce che l'intestazione venga copiata correttamente e che successivamente i registri vengano applicati correttamente al file di dati.

Una volta completate tutte le procedure sopra elencate, è possibile copiare i file di dati utilizzando gli strumenti di sistema operativo come cp, rsync e altri. Abilitare la modalità di backup riduce le prestazioni del database: da un lato, aumenta il volume dei log e, dall'altro, se si verifica un errore durante la modalità di backup, il ripristino sarà più lungo poiché le intestazioni dei file di dati non vengono aggiornate. Più rapidamente viene completato il backup, meglio è per il database; pertanto, è opportuno utilizzare strumenti come snapshot del filesystem o break mirror (BCV) nell'array di dischi. Alcuni DBMS (Oracle, PostgreSQL) consentono all'amministratore di scegliere autonomamente il metodo di copia, mentre altri (Microsoft SQL Server) forniscono un'interfaccia per integrare le proprie utilità di backup con i meccanismi dei filesystem o delle SAN.

Al termine del backup, è necessario riportare il database allo stato normale. In Oracle, questo avviene con il comando ALTER DATABASE/TABLESPACE END BACKUP, in PostgreSQL – chiamando la funzione pg_stop_backup(), e in altri database – tramite sottoprogrammi interni delle relative istruzioni o servizi esterni.

Ecco come appare il diagramma temporale del processo di backup:

La preparazione per il backup (begin backup) richiede tempo, a volte considerevole. Anche se si utilizzano volumi mirror o file system con funzionalità di snapshot, il processo di backup non sarà istantaneo.
Insieme ai file dei dati, è necessario conservare i log a partire dall'inizio della preparazione del backup fino al momento in cui il database viene riportato allo stato normale.
È possibile ripristinare da questo backup nel momento in cui il database viene riportato allo stato normale. Il ripristino a un momento precedente non è possibile.

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

I dati dalla memoria vengono salvati su disco.
Viene registrato un elenco di file che verranno inclusi nel backup. Fino al termine del processo di backup, non è consentito eliminare questi file, anche se diventano non 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 richiesta di uscita dalla modalità di backup. Tuttavia, un'interruzione che richiede il ripristino può verificarsi in qualsiasi momento. Il compito di ripristinare lo stato del database a un momento arbitrario è noto come 'ripristino a un punto' (point-in-time recovery).

Per garantire questa possibilità, è necessario conservare i registri del DB a partire dal momento in cui termina il backup e, durante il processo di ripristino, continuare ad applicare i registri alla copia ripristinata. Dopo che il DB è stato ripristinato dalla copia di backup al momento di fine copia, lo stato del database (file e pagine memorizzate nella cache) è garantito come corretto, quindi non è necessario alcun speciale regime di registrazione. Applicando i registri fino al momento desiderato, è possibile ottenere lo stato del database in un 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 è di solito limitata dalle prestazioni del processore. Se nella base dati principale si verificano modifiche in parallelo, durante il ripristino tutte le modifiche vengono eseguite in sequenza, nell'ordine in cui sono lette dal log. Di conseguenza, il tempo di recupero dipende linearmente da quanto la posizione di ripristino è distante dalla fine del backup. Per questo motivo, è necessario eseguire backup completi piuttosto frequentemente: almeno una volta a settimana per database con un carico di transazioni ridotto e fino a backup giornalieri per database ad alto carico.

Backup incrementale

Per velocizzare il ripristino al punto desiderato, sarebbe utile eseguire il backup il più frequentemente possibile, ma senza occupare spazio inutile sui dischi e senza sovraccaricare il database con operazioni di backup.

La soluzione al problema è il backup incrementale, ovvero il backup solo delle parti di dati che sono cambiate dall'ultimo backup.
Il backup incrementale ha senso solo per i DBMS che utilizzano strutture dati modificabili.

L'incremento può essere conteggiato sia dall'ultima copia di backup completa (copia cumulativa) che da qualsiasi copia precedente (copia differenziale).

Sfortunatamente, non esiste una terminologia univoca e diversi fornitori usano termini diversi:

Differenziale
Cumulativa

Oracle
Differential
Cumulative

PostgresPro
Incremental
—

Microsoft SQL Server
—
Differential

IBM DB2
Delta
Incremental

Nel caso di copie incrementali, il processo di ripristino a un punto appare come segue:

viene ripristinato l'ultimo backup completo effettuato prima del momento di ripristino;
sopra la copia completa vengono ripristinate le copie incrementali;
vengono applicati i registri dal momento di inizio del backup fino al punto di ripristino.

La presenza di una copia cumulativa accelera il processo di ripristino. Ad esempio, per ripristinare lo stato del database a un punto tra T3 e T4, è necessario ripristinare due copie incremental i, mentre per il ripristino a un punto dopo T4, è sufficiente una sola copia.
È ovvio che il volume di una copia cumulativa è inferiore al volume di più copie differenziali, poiché alcune pagine sono cambiate più volte e ogni copia incrementale contiene la sua versione della pagina.

Ci sono tre modi per creare una copia incrementale:

creare una copia completa e calcolare la differenza con la copia completa precedente;
analizzare i log, creare un elenco delle pagine modificate e eseguire il backup delle 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, trasformarlo in incrementale è inutile, poiché il ripristino di una copia completa è più veloce rispetto al ripristino della copia completa precedente e dell'incremento. È meglio delegare il compito di risparmiare spazio su disco a componenti specializzati con meccanismi integrati di deduplicazione. Questi possono essere sia sistemi di archiviazione specializzati (EMC DataDomain, HPE StorageWorks VLS, tutta la gamma NetApp), sia prodotti software (ZFS, Veritas NetBackup PureFile, Windows Server Data Deduplication).

Il secondo e il terzo metodo si differenziano per il meccanismo di determinazione dell'elenco delle pagine modificate. L’analisi dei log è più dispendiosa in termini di risorse, inoltre per implementarla è necessario conoscere la struttura dei file di log. Chiedere direttamente al database quali pagine sono state modificate è la soluzione più semplice, ma per questo il core del DBMS deve avere la funzionalità di monitoraggio dei blocchi modificati (block change tracking).

La funzionalità di backup incrementale è stata introdotta per la prima volta nel software Oracle Recovery Manager (RMAN), presente nella versione Oracle 8i. Oracle implementò subito il monitoraggio dei blocchi modificati, quindi non è necessario analizzare i log.

PostgreSQL non tiene traccia dei blocchi modificati, quindi l'utilità pg_probackup, sviluppata dalla compagnia russa Postgres Professional, identifica le pagine modificate analizzando il log. Tuttavia, la società offre anche il DBMS PostgresPro, che include l'estensione ptrack, che monitora le modifiche alle pagine. Utilizzando pg_probackup con il DBMS PostgresPro, l'utilità richiede le pagine modificate direttamente dal database, proprio come fa RMAN.

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

In DB2 è disponibile la possibilità di monitorare le pagine modificate, ma di default è disattivata. Una volta attivata, DB2 permette di eseguire backup completi, differenziali e cumulativi.

Una differenza importante degli strumenti descritti in questa sezione (eccetto pg_probackup) rispetto agli strumenti di backup a livello di file è che richiedono le immagini delle pagine dal database, invece di leggere i dati direttamente dal disco. Uno 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 una modalità di registrazione speciale durante il backup.

Attenzione, la presenza di copie incrementali non elimina i requisiti per avere registri per il ripristino a un momento specifico. Pertanto, nei database industriali, i registri vengono costantemente riscritti su supporti esterni, mentre i backup, completi e/o incrementali, vengono creati secondo un programma.

La miglior attuazione attuale dell'idea di backup incrementale è l'hardware e software combinato (nella terminologia Oracle – engineered system) Zero Data Loss Recovery Appliance – una soluzione specializzata di Oracle per il backup del proprio database. Il sistema consiste in un cluster server con grandi volumi di dischi sui quali è installata una versione modificata del software Recovery Manager, e può funzionare sia con altri complessi hardware e software Oracle (Database Appliance, Exadata, SPARC Supercluster), sia con database Oracle su infrastrutture tradizionali. A differenza del 'normale' RMAN, in ZDLRA è stata implementata la concezione di 'incremento permanente' (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 unire le copie, creando nuove copie complete dalle incrementali.

A merito dei programmatori russi, va notato che anche pg_probackup è in grado di unire copie incrementali.

A differenza di molte domande simili, la domanda 'quale metodo di backup è migliore' ha una risposta inequivocabile: il migliore è lo strumento nativo per il DBMS utilizzato, che consente la copia incrementale.

Per l'amministratore di database, questioni come la scelta della strategia di backup e l'integrazione degli strumenti di backup dei database nell'infrastruttura aziendale sono molto più importanti. Ma queste questioni esulano dallo scopo di questo articolo.

Fonte: habr.com