Ho pensato a quello che hai scritto e qui ci sono alcune idee per te:
- Se hai bisogno di un backup che sia davvero coerente fino a un certo punto nel tempo, devi usare pg_basebackup o pg_barman (usa internamente pg_basebackup) - la spiegazione è nel 1. link sotto. L'ultimo pg_basebackup 10 flussi di log WAL in modo da eseguire il backup anche di tutte le modifiche apportate durante il backup. Ovviamente questo backup richiede solo l'intera istanza PG. D'altra parte non blocca nessun tavolo. E se lo fai da un'istanza remota, provoca solo un piccolo carico della CPU sull'istanza PG e l'IO del disco non è grande come suggeriscono alcuni testi. Vedi i link 4 sulle mie esperienze. Il restauro è abbastanza semplice - vedi link 5.
- Se usi pg_dump devi capire che non hai alcuna garanzia che il tuo backup sia davvero coerente fino al momento - vedi ancora il link 1. C'è la possibilità di usare lo snapshot del database (vedi link 2 e 3) ma anche con esso non puoi contare sulla coerenza del 100%. Abbiamo usato pg_dump solo sul nostro database analitico che carica il nuovo solo 1 volta al giorno (partizioni di ieri dal database di produzione). Puoi velocizzarlo con l'opzione parallela (funziona solo per il formato di backup della directory). Ma lo svantaggio è un carico molto più elevato sull'istanza PG:maggiore utilizzo della CPU, I/O del disco molto più elevato. Anche se esegui pg_dump in remoto, in tal caso salvi solo l'IO del disco per il salvataggio dei file di backup. Inoltre pg_dump deve posizionare il blocco di lettura sulle tabelle in modo che possa entrare in collisione con nuovi inserti o con la replica (se acquisita su replica). Ma quando il tuo database raggiunge centinaia di GB, anche il dump parallelo può richiedere ore e in quel momento dovresti comunque passare a pg_basebackup.
- pg_barman è la "versione confortevole" di pg_basebackup + ti consente di prevenire la perdita di dati anche quando la tua istanza PG va in crash molto gravemente. Impostarlo per funzionare richiede più modifiche ma ne vale sicuramente la pena. Dovrai impostare l'archiviazione del registro WAL (vedi link 6) e se PG è <10 dovrai impostare "max_wal_senders" e "max_replication_slots" (che comunque ti serve per la replica) - tutto è nel manuale di pg-barman sebbene la descrizione non è proprio eccezionale. pg_barman eseguirà lo streaming e memorizzerà i record WAL anche tra i backup, quindi in questo modo puoi essere sicuro che la perdita di dati in caso di arresto anomalo grave sarà quasi nulla. Ma farlo funzionare può richiedere molte ore perché le descrizioni non sono esattamente buone. pg-barman esegue sia il backup che il ripristino con i suoi comandi.
Il tuo database è grande 5 GB, quindi qualsiasi metodo di backup sarà rapido. Ma devi decidere se hai bisogno di un ripristino puntuale e di una perdita di dati quasi pari a zero o meno, quindi se investirai tempo per impostare pg-barman o meno.
Collegamenti:
- PostgreSQL, backup e tutto il resto devi sapere
- Recensione per carta:14-Serializable Isolamento snapshot in PostgreSQL - sulle istantanee
- Dumping parallelo di database - esempio come utilizzare snapshot
- pg_basebackup esperienze
- pg_basebackup - ripristina backup tar
- Archiviazione dei registri WAL tramite script
