EC2 - Come eseguire correttamente il backup dei dati PostgreSQL?

Ecco l'installazione: 1 piccola istanza EC2 di Amazon Linux (con supporto EBS) con 3 volumi aggiuntivi. Questo è sia un server web che un server database. Un volume per il codice, uno per la directory dei dati PostgreSQL (8.4) e un volume per archiviare i file WAL da PostgreSQL.

(1) Il volume con file WAL avrà anche un backup di base della directory dei dati, che viene copiato dopo aver eseguito un pg_start_backup (). Quindi memorizzerà l'output di archivio continuo da PostgreSQL (file WAL). Per creare un'istantanea di questo volume, ha senso fare una sincronizzazione e congelare il filesystem (usando xfs_freeze se è XFS o dmsetup se è EXT4)? O posso semplicemente fare un'istantanea dal vivo? I file WAL verranno spediti al ritmo di uno al minuto. È possibile che un'istantanea possa essere avviata mentre un singolo file WAL viene copiato e genera dati corrotti?

(2) Verrà eseguito il backup del volume che contiene la directory di dati PostgreSQL live in tempo reale (giornalmente). Prima di fare un'istantanea di questo volume, lancio un pg_dump e il file SQL risultante viene conservato nella directory dei dati. È utile prendere precauzioni per garantire che i dati del database effettivo siano coerenti? Sarebbe corretto supporre che la creazione di un'istantanea live esegua correttamente il backup dei file di configurazione (postgresql.conf, pg_hba.conf, pg_ident.conf) e (b) il backup del file di dump SQL. Il backup di queste due cose, il file di dump sql e i file di configurazione, sarebbe il punto principale dello snapshot di questo volume. Il DB non è molto grande, quindi non mi importa il fatto che i file di dati gonfieranno questa istantanea. E in quel caso, posso semplicemente fare un'istantanea dal vivo - giusto?

(2a) Sarebbe solo meglio mantenere la directory dei dati sul volume principale e disporre di uno script di backup che copi il file di dump sql nonché i file di configurazione su un altro volume e lo snapshot al termine della copia?

(3) Per quanto riguarda il volume con il codice sopra, c'è ancora qualche motivo per sincronizzare e congelare il filesystem? O è possibile scattare solo un'istantanea dal vivo? Questi dati dovrebbero essere abbastanza "statici".

(4) È un solido schema di backup? Non viene eseguito regolarmente il backup del volume di root poiché manterrò un'immagine della macchina solo dopo averla impostata e configurata.

Grazie

Vedi il manuale . Se il mio consiglio è in conflitto con il suo 'in alcun modo, è giusto.

1. Una sincronizzazione non è una cattiva idea, a meno che lo strumento di copia fsync () s ogni file WAL che scrive e la directory in cui si trova prima di copiare il successivo. Un ultimo file WAL incompleto non ha molta importanza; nel peggiore dei casi, è sufficiente eliminarlo. Il PG generalmente soffoca su un WAL incompleto, anche se non è stato fatto alcun checksum, quindi è possibilesii davvero sfortunato e cerca di applicare i dati della spazzatura che, per pura follia, sembravano veri e propri record WAL. Nella tua posizione sincronizzerei il volume prima di un'istantanea per assicurarmi che eventuali buffer sporchi non scritti nella RAM colpiscano l'immagine del file system sul disco. Un congelamento contribuirebbe ad evitare WAL disordinati ma non fatali scritti parzialmente, quindi non è un'idea terribile ma non vitale. Ciò che è vitale è avere una linea temporale non danneggiata fino al punto di ripresa. Personalmente, scrivo i miei WAL con un nome di file temporaneo e li rinomino con il loro nome finale solo una volta copiato completamente; se lo fai, non devi congelare.

2. Sembra corretto Un'istantanea live è proprio come eseguire un test plug pull su un sistema live con memorizzazione nella cache di scrittura. Il database deve essere ripristinato correttamente quando viene ripristinato da un'istantanea live, come dopo il pull-pull. Ti consiglierei di automatizzare i test dei ripristini dalle istantanee. (Nota: un test di ripristino dell'istantanea non sostituisce completamente il test del plug pull perché non tiene conto della possibile memorizzazione nella cache del disco, del controller raid, ecc.). Non solo i file di configurazione e il dump, ma il database stesso dovrebbe andare bene dopo l'istantanea. Valuta di sincronizzare il volume prima dell'istantanea per assicurarti che tutti i dati di dump ecc. Abbiano effettivamente colpito il disco.
   
   2a. Potrebbe risparmiare un po 'di spazio su disco. Piccola differenza altrimenti. Otterrai le snapshot molto più a lungo senza tutto il churn del database live su di essi.

3. Perché anche eseguire l'istantanea del volume del codice? Una semplice copia a livello di file potrebbe andare bene. Certamente dovrebbe essere un'istantanea dal vivo.

4. Questo non è un solido schema di backup. Non riesce in un'area critica: non è in corso alcun test di ripristino e convalida. Dovresti sempre testare i tuoi backup su base regolare per assicurarti di poterli veramente ripristinare.

   Personalmente, ti consiglio di utilizzare la spedizione WAL o di inviare dump del database a un host diverso , preferibilmente uno non su Amazon EC2 o almeno in una regione diversa. Questo host dovrebbe eseguire test di ripristino automatizzati, inviarti rapporti sui risultati e dovrebbe anche essere controllato manualmente.

   Mentre le tue istantanee (contenenti dump) saranno su S3 e saranno al sicuro lì, ciò non significa che saranno accessibili quando ne avrai bisogno urgentemente. Le dichiarazioni di durabilità di Amazon sono rassicuranti, ma i tuoi dati possono ancora essere sicuri e completamente inaccessibili per te durante un'interruzione temporanea del servizio S3.