Documentazione di PostgreSQL 9.0 > Amministrazione del server > Backup e ripristino
PrecedenteLog File MaintenanceBackup a livello di file systemSuccessivo

24. Backup e ripristino

Come ogni cosa che contiene dati preziosi, si dovrebbero fare regolarmente dei backup dei database PostgreSQL™. Mentre la procedura è essenzialmente semplice, è importante avere una comprensione chiara delle tecniche di fondo e delle assunzioni.

Fondamentalmente ci sono tre differenti approcci per fare il back up di dati PostgreSQL™:

  • SQL dump

  • Backup a livello di file sustem

  • Archiviazione continua

Ognuno ha i propri punti di forza e le proprie debolezze; ognuno è discusso a turno nelle sezioni seguenti.

24.1. SQL Dump

L'idea che sta dietro a questo metodo di dump è di generare un file di testo con comandi SQL che, quando ritrasmesso al server, ricreerà il database nello stesso stato in cui si trovava al momento del dump. PostgreSQL™ fornisce il programma d'utilità pg_dump(1) per questo scopo. L'utilizzo di base di questo comando:

pg_dump dbname > outfile

Come si può notare, pg_dump scrive il risultato nello standard output. Si vedrà sotto in che modo questo può essere utile.

pg_dump è una normale applicazione client per PostgreSQL™ (sebbene sia particolarmente intelligente). Questo significa che è possibile eseguire questa procedura di backup da ogni host remoto che ha accesso al database. Ricordare comunque che pg_dump non funziona con permessi speciali. In particolare, deve avere accesso in lettura a tutte le tabelle di cui si vuole fare il back up, in pratica si dovrà lanciarlo quasi sempre come superutente del database.

To specify which database server pg_dump should Per specificare quale server database dovrebbere essere contattato da pg_dump, usare l'opzione a linea di comando contact, use the command line options -h -h host e host and -p port. The -p port. L'host predefinito è l'host locale o quello specificato dalla variabile di sistema PGHOST. Similarmente, la porta predefinita è indicata dalla variabile di sistema PGPORT o, fallendo quella, la predefinita alla compilazione. (Convenientemente, il server normalmente avrà lo stesso valora predefinito alla compilazione).

Come ogni altra applicazione client PostgreSQL™, pg_dump si connetterà in maniera predefinita al database con lo stesso nome dell'utente corrente del sistema operativo. Per cambiare questo comportamento, specificare l'opzione -U o impostare la variabile d'ambiente PGUSER. Ricordare che le connessioni pg_dump sono sottoposte ai normali meccanismi di autenticazione dei client (che sono descritti nel Capitolo 19, Client Authentication).

Un vantaggio importante di pg_dump rispetto agli altri metodi di backup descritti successivamente è che l'output di pg_dump può essere generalmente importato in versioni successive di PostgreSQL™, mentre backup a livello di file system e l'archiviazione continua sono entrambi estremamente scpecifici alla versione del server. pg_dump è anche l'unico metodo che funzionerà quando si dovrà trasferire un database su una macchina con architettura differente, come il passaggio da un server a 32 bit ad uno a 64 bit.

I dump creati da pg_dump sono internamente consistenti, cioè, il dump rappresenta un'istantanea del database al momento che pg_dump è stato lanciato. pg_dump non blocca altre operazioni sul database mentre sta lavorando. (Ad eccezione di operazioni che hanno bisogno di operare con un lock esclusivo, come la maggior parte delle forme di ALTER TABLE).

[Importante]

Importante

Se lo schema del database si basa sgli OID (per esempio, come chiavi esterne) si deve istruire pg_dump ad eseguire il dump anche degli OID Per farlo, usare l'opzione a linea di comando -o.

24.1.1. Ripristinare il dump

I file di testo creati da pg_dump sono fatti per essere letti dal programma psql. Il comando generale per ripristinare un dump è

psql dbname < infile

dove infile è il file creato dal comando pg_dump. Il database dbname non sarà creato da questo comando, per questo si dovrà crearlo da template0 prima di eseguire psql (per es., con createdb -T template0 dbname). psql supporta opzioni simili a pg_dump per specificare il server database al quale connettersi e il nome utente da usare. Se veda la pagina di referenza psql(1) per maggiori informazioni.

Prima di ripristinare un dump SQL, tutti gli utenti che possiedono oggetti o a cui sono stati concessi permessi su oggetti nel database sottoposto a dump devono già esistere. Altrimenti, il ripristino fallirà nel ricreare gli oggetti con l'originale proprietà e/o permessi. (A volte questo è quello che si vuole, ma di solito no).

In maniera predefinita, lo script psql continuerà a viaggiare dopo che viene riscontrato un errore SQL. Si potrebbe voler lanciare psql con la variabile ON_ERROR_STOP impostata per modificare quel comportamento e far si che psql esca con uno stato d'uscita 3 se si presenta un errore SQL:

psql --set ON_ERROR_STOP=on dbname < infile

D'altro canto, si avrà un database ripristinato solo parzialmente. Alternativamente, è possibile specificare che l'intero dump dovrebbe essere ripristinato come una singola transazione, così il ripristino sarà o completamente compeltato o completamente revertito. Questo modo può essere specificato passando l'opzione a riga di comando -1 o --single-transaction a psql. Quando si usa questo modo, fare attenzione che anche un piccolo errore può portare al rollback di un ripristino che stava girando da molte ore. Comunque, sarebbe preferibile pulire a mano un database complesso dopo un dump parzialmente rispristinato.

L'abilità di pg_dump e psql di di scrivere e leggere dalle pipe rende possibile fare il dump di un database direttamente da un server ad un altro, per esempio:

pg_dump -h host1 dbname | psql -h host2 dbname

[Importante]

Importante

I dump prodotti da pg_dump sono relativi a template0. Questo significa nel dump finirà anche ogni linguaggio, procedura, ecc. aggiunta attraverso template1. Come risultato, quando si esegue un ripristino, se si sta utilizzando un template1 modificato, si deve creare un database vuoto da template0, come nell'esempio sopra.

Dopo il ripristino di un backup, è saggio lanciare ANALYZE(7) su ogni database, così l'ottimizzatore di query avrà statistiche utili; si veda Sezione 23.1.3, «Updating Planner Statistics» e Sezione 23.1.5, «The Autovacuum Daemon» per maggiori informazioni. Per ulteriori consigli su come caricare grandi quantità di dati in PostgreSQL™ efficentemente, si rimanda al Sezione 14.4, «Popolare un database».

24.1.2. Usare pg_dumpall

pg_dump esegue il dump di un solo database alla volta, e non esegue il dump delle informazioni sui ruoli o sui tablespace (dato che queste sono a livello di cluster piuttosto che a livello di database). Per avere un dump comodo dell'intero contenuto di un cluster database, è disponibile il programma pg_dumpall(1). pg_dumpall esegue il backup di ogni database in un dato cluster, e conserva anche i dati a livello di cluster che sono ruoli e definizioni tablespace. L'utilizzo di base di questo comando è:

pg_dumpall > outfile

Il dump risultante può essere ripristinato con psql:

psql -f infile postgres

(Attualmente, è possibile specificare ogni nome di database esistente da cui partire, ma se si sta caricando in un cluster vuoto allora di solito dovrebbe essere usato postgres). È sempre necessario avere accesso al database come superutente quando si ripristina un dump fatto con pg_dumpall, dato che è richiesto di ripristino di informazioni sui ruoli e sui tablespace, assicurarsi che i percorsi dei tablespace nel dump siano appropriati per la nuova installazione.

pg_dumpall funziona emettendo comandi per ricreare ruoli, tablespace, e database vuoti, quindi invocando pg_dump per ogni database. Questo significa che mentre ogni database sarà internamente consistente, l'istantanea dei diversi database potrebbe non essere esattamente identica.

24.1.3. Gestire grandi database

Qualche sistema operativo ha limiti per la dimensione massima dei file che causa problemi quando si creano file pg_dump grandi. Fortunatamente, pg_dump può scrivere sullo standard output, così è possibile usare gli strumenti Unix standard per superare questo potenziale problema. Ci sono diversi metodi possibili:

Usare dump compressi.  È possibile usare il programma di compressione preferito, per esempio gzip:

pg_dump dbname | gzip > filename.gz

Ricaricare con:

gunzip -c filename.gz | psql dbname

o:

cat filename.gz | gunzip | psql dbname

Usare split Il comando split permette di dividere l'output il file più piccoli che sono accettabili in dimensione per il file system. Per esempio, per fare pezzi da 1 megabyte:

pg_dump dbname | split -b 1m - filename

Ricaricare con:

cat filename* | psql dbname

Usare il formato di dump personalizzato di pg_dump Se PostgreSQL™ è stato compilato su un sistema con la libreria di compressione zlib installata, il formato di compressione personalizzato comprimerà i dati mentre li scrive nel file di output. Questo produrrà dimensioni dei file di dump simili all'utilizzo di gzip, ma avrà il vantaggio aggiuntivo che le tabelle possono essere ripristinate selettivamente. Il seguente comando fa il dump di un database usando il formato di dump personalizzato:

pg_dump -Fc dbname > filename

Un file di dump generato in questo modo non è uno script per psql, ma deve essere ripristinato con pg_restore, per esempio:

pg_restore -d dbname filename

Si veda le pagine di referenza pg_dump(1) e pg_restore(1) per dettagli.

Per database molto grandi, si potrebbe aver necessità di combinare split con uno degli altri due approcci.

Documentazione di PostgreSQL 9.0 > Amministrazione del server > Backup e ripristino
PrecedenteLog File MaintenanceBackup a livello di file systemSuccessivo