Ik heb nagedacht over wat je schreef en hier zijn enkele ideeën voor jou:
- Als je een back-up nodig hebt die op een bepaald moment echt consistent zal zijn, dan moet je pg_basebackup of pg_barman gebruiken (gebruikt intern pg_basebackup) - uitleg staat in 1. link hieronder. Nieuwste pg_basebackup 10 streamt WAL-logs zodat u ook een back-up kunt maken van alle wijzigingen die tijdens de back-up zijn gedaan. Natuurlijk neemt deze back-up alleen de hele PG-instantie in beslag. Aan de andere kant vergrendelt het geen enkele tafel. En als u het vanaf een externe instantie doet, veroorzaakt dit slechts een kleine CPU-belasting op de PG-instantie en is de schijf-IO niet zo groot als sommige teksten suggereren. Zie links 4 over mijn ervaringen. Restauratie is vrij eenvoudig - zie link 5.
- Als je pg_dump gebruikt, moet je begrijpen dat je geen garantie hebt dat je back-up echt consistent is tot op het moment - zie nogmaals link 1. Er is een mogelijkheid om snapshot van de database te gebruiken (zie links 2 en 3) maar zelfs daarmee kun je niet rekenen op 100% consistentie. We gebruikten pg_dump alleen in onze analytische database die slechts 1x per dag nieuwe laadt (gisteren partities uit de productiedatabase). U kunt het versnellen met de parallelle optie (werkt alleen voor directory-back-upformaat). Maar nadeel is een veel hogere belasting van de PG-instantie - hoger CPU-gebruik, veel hogere schijf-IO. Zelfs als u pg_dump op afstand uitvoert - in dat geval slaat u alleen schijf IO op voor het opslaan van back-upbestanden. Bovendien moet pg_dump leesvergrendeling op tabellen plaatsen, zodat het kan samenvallen met nieuwe invoegingen of met replicatie (wanneer genomen op replica). Maar wanneer uw database honderden GB's bereikt, kan zelfs parallelle dump uren duren en op dat moment zou u toch naar pg_basebackup moeten overschakelen.
- pg_barman is een "comfortabele versie" van pg_basebackup + hiermee kunt u gegevensverlies voorkomen, zelfs wanneer uw PG-instantie erg crasht. Om het te laten werken, zijn er meer veranderingen nodig, maar het is zeker de moeite waard. U moet WAL-logarchivering instellen (zie link 6) en als uw PG <10 is, moet u "max_wal_senders" en "max_replication_slots" instellen (die u toch nodig hebt voor replicatie) - alles staat in de pg-barman-handleiding, hoewel de beschrijving is niet bepaald geweldig. pg_barman zal WAL-records streamen en opslaan, zelfs tussen back-ups, zodat u er zeker van kunt zijn dat gegevensverlies in het geval van een zeer ernstige crash bijna geen zal zijn. Maar om het te laten werken kan vele uren duren, omdat de beschrijvingen niet bepaald goed zijn. pg-barman doet zowel back-up als herstel met zijn commando's.
Uw database is 5 GB groot, dus elke back-upmethode zal snel zijn. Maar u moet beslissen of u herstel op een bepaald tijdstip en bijna geen gegevensverlies nodig hebt - dus of u tijd wilt investeren om pg-barman in te stellen of niet.
Links:
- PostgreSQL, back-ups en alles je moet het weten
- Review voor papier:14-Serializable Isolatie van momentopnamen in PostgreSQL - over snapshots
- Parallel dumpen van databases - voorbeeld hoe snapshot te gebruiken
- pg_basebackup ervaringen
- pg_basebackup - tar-back-up terugzetten
- WAL-logboeken archiveren met script