Hoe pgBackRest te gebruiken om een back-up te maken van PostgreSQL en TimescaleDB

Uw gegevens zijn waarschijnlijk de meest waardevolle activa in het bedrijf, dus u moet een Disaster Recovery Plan (DRP) hebben om gegevensverlies te voorkomen in het geval van een ongeval of hardwarestoring. Een back-up is de eenvoudigste vorm van DR. Het is misschien niet altijd voldoende om een acceptabele Recovery Point Objective (RPO) te garanderen, maar het is een goede eerste benadering. U moet ook een Recovery Time Objective (RTO) definiëren op basis van uw bedrijfsvereisten. Er zijn veel manieren om de RTO-waarde te bereiken, dit hangt af van de bedrijfsdoelen.

In deze blog zullen we zien hoe u pgBackRest kunt gebruiken voor het maken van back-ups van PostgreSQL en TimescaleDB en hoe u een van de belangrijkste functies van deze back-uptool, de combinatie van volledige, incrementele en differentiële back-ups, kunt gebruiken om downtime te minimaliseren.

Wat is pgBackRest?

Er zijn verschillende soorten back-ups voor databases:

Logisch:de back-up wordt opgeslagen in een voor mensen leesbare indeling zoals SQL.
Fysiek:de back-up bevat binaire gegevens.
Volledig/Incrementeel/Differentieel:De definitie van deze drie soorten back-ups zit impliciet in de naam. De volledige back-up is een volledige kopie van al uw gegevens. Incrementele back-up maakt alleen een back-up van de gegevens die zijn gewijzigd sinds de vorige back-up en de differentiële back-up bevat alleen de gegevens die zijn gewijzigd sinds de laatste volledige back-up is uitgevoerd. De incrementele en differentiële back-ups zijn geïntroduceerd als een manier om de hoeveelheid tijd en schijfruimte die nodig is om een volledige back-up uit te voeren te verminderen.

pgBackRest is een open source back-uptool die fysieke back-ups maakt met enkele verbeteringen in vergelijking met de klassieke pg_basebackup-tool. We kunnen pgBackRest gebruiken om een eerste databasekopie voor Streaming Replication uit te voeren door een bestaande back-up te gebruiken, of we kunnen de delta-optie gebruiken om een oude standby-server opnieuw op te bouwen.

Enkele van de belangrijkste pgBackRest-functies zijn:

Parallelle back-up en herstel
Lokale of externe bediening
Volledige, incrementele en differentiële back-ups
Back-uprotatie en vervaldatum van archief
Back-up integriteitscontrole
Back-up hervatten
Delta herstellen
Encryptie

Laten we nu eens kijken hoe we pgBackRest kunnen gebruiken om een back-up te maken van onze PostgreSQL- en TimescaleDB-databases.

Hoe pgBackRest te gebruiken

Voor deze test gebruiken we CentOS 7 als besturingssysteem en PostgreSQL 11 als databaseserver. We gaan ervan uit dat u de database hebt geïnstalleerd, zo niet, dan kunt u deze links volgen om zowel PostgreSQL als TimescaleDB op een gemakkelijke manier te implementeren met ClusterControl.

Eerst moeten we het pgbackrest-pakket installeren.

$ yum install pgbackrest

pgBackRest kan worden gebruikt vanaf de opdrachtregel of vanuit een configuratiebestand dat zich standaard in /etc/pgbackrest.conf op CentOS7 bevindt. Dit bestand bevat de volgende regels:

[global]
repo1-path=/var/lib/pgbackrest
#[main]
#pg1-path=/var/lib/pgsql/10/data

U kunt deze link bekijken om te zien welke parameter we in dit configuratiebestand kunnen toevoegen.

We voegen de volgende regels toe:

[testing]
pg1-path=/var/lib/pgsql/11/data

Zorg ervoor dat u de volgende configuratie hebt toegevoegd aan het bestand postgresql.conf (voor deze wijzigingen moet de service opnieuw worden opgestart).

archive_mode = on
archive_command = 'pgbackrest --stanza=testing archive-push %p'
max_wal_senders = 3
wal_level = logical

Laten we nu een basisback-up maken. Eerst moeten we een "stanza" maken die de back-upconfiguratie voor een specifiek PostgreSQL- of TimescaleDB-databasecluster definieert. De strofesectie moet het databaseclusterpad en de host/gebruiker definiëren als de databasecluster op afstand is.

$ pgbackrest --stanza=testing --log-level-console=info stanza-create
2019-04-29 21:46:36.922 P00   INFO: stanza-create command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:46:37.475 P00   INFO: stanza-create command end: completed successfully (554ms)

En dan kunnen we het check commando uitvoeren om de configuratie te valideren.

$ pgbackrest --stanza=testing --log-level-console=info check
2019-04-29 21:51:09.893 P00   INFO: check command begin 2.13: --log-level-console=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
2019-04-29 21:51:12.090 P00   INFO: WAL segment 000000010000000000000001 successfully stored in the archive at '/var/lib/pgbackrest/archive/testing/11-1/0000000100000000/000000010000000000000001-f29875cffe780f9e9d9debeb0b44d945a5165409.gz'
2019-04-29 21:51:12.090 P00   INFO: check command end: completed successfully (2197ms)

Voer de volgende opdracht uit om de back-up te maken:

$ pgbackrest --stanza=testing --type=full --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=full
WARN: option repo1-retention-full is not set, the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 15:43:21": backup begins after the next regular checkpoint completes
INFO: backup start archive = 000000010000000000000006, lsn = 0/6000028
WARN: aborted backup 20190429-215508F of same type exists, will be cleaned to remove invalid files and resumed
INFO: backup file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: full backup size = 31.8MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 000000010000000000000006, lsn = 0/6000130
INFO: new backup label = 20190429-215508F
INFO: backup command end: completed successfully (12810ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (10ms)

Nu hebben we de back-up voltooid met de uitvoer "met succes voltooid", dus laten we deze gaan herstellen. We stoppen de postgresql-11-service.

$ service postgresql-11 stop
Redirecting to /bin/systemctl stop postgresql-11.service

En laat de datadir leeg.

$ rm -rf /var/lib/pgsql/11/data/*

Voer nu de volgende opdracht uit:

$ pgbackrest --stanza=testing --log-level-stderr=info restore
INFO: restore command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing
INFO: restore backup set 20190429-215508F
INFO: restore file /var/lib/pgsql/11/data/base/16384/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13878/1255 (608KB, 3%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: restore file /var/lib/pgsql/11/data/base/13877/1255 (608KB, 5%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
. . .
INFO: write /var/lib/pgsql/11/data/recovery.conf
INFO: restore global/pg_control (performed last to ensure aborted restores cannot be started)
INFO: restore command end: completed successfully (10819ms)

Start vervolgens de postgresql-11-service.

$ service postgresql-11 stop

En nu hebben we onze database in de lucht.

$ psql -U app_user world
world=> select * from city limit 5;
 id |      name      | countrycode |   district    | population
----+----------------+-------------+---------------+------------
  1 | Kabul          | AFG         | Kabol         |    1780000
  2 | Qandahar       | AFG         | Qandahar      |     237500
  3 | Herat          | AFG         | Herat         |     186800
  4 | Mazar-e-Sharif | AFG         | Balkh         |     127800
  5 | Amsterdam      | NLD         | Noord-Holland |     731200
(5 rows)

Laten we nu eens kijken hoe we een differentiële back-up kunnen maken.

$ pgbackrest --stanza=testing --type=diff --log-level-stderr=info backup
INFO: backup command begin 2.13: --log-level-stderr=info --pg1-path=/var/lib/pgsql/11/data --repo1-path=/var/lib/pgbackrest --stanza=testing --type=diff
WARN: option repo1-retention-full is not set, the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
INFO: last backup label = 20190429-215508F, version = 2.13
INFO: execute non-exclusive pg_start_backup() with label "pgBackRest backup started at 2019-04-30 21:22:58": backup begins after the next regular checkpoint completes
INFO: backup start archive = 00000002000000000000000B, lsn = 0/B000028
WARN: a timeline switch has occurred since the last backup, enabling delta checksum
INFO: backup file /var/lib/pgsql/11/data/base/16429/1255 (608KB, 1%) checksum e560330eb5300f7e2bcf8260f37f36660ce3a2c1
INFO: backup file /var/lib/pgsql/11/data/base/16429/2608 (448KB, 8%) checksum 53bd7995dc4d29226b1ad645995405e0a96a4a7b
. . .
INFO: diff backup size = 40.1MB
INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
INFO: backup stop archive = 00000002000000000000000B, lsn = 0/B000130
INFO: new backup label = 20190429-215508F_20190430-212258D
INFO: backup command end: completed successfully (23982ms)
INFO: expire command begin
INFO: option 'repo1-retention-archive' is not set - archive logs will not be expired
INFO: expire command end: completed successfully (14ms)

Voor complexere back-ups kunt u de pgBackRest-gebruikershandleiding volgen.

Zoals we eerder vermeldden, kunt u de opdrachtregel of de configuratiebestanden gebruiken om uw back-ups te beheren.

Hoe pgBackRest te gebruiken in ClusterControl

Sinds versie 1.7.2 heeft ClusterControl ondersteuning toegevoegd voor pgBackRest voor het maken van back-ups van PostgreSQL- en TimescaleDB-databases, dus laten we eens kijken hoe we het kunnen gebruiken vanuit ClusterControl.

Een back-up maken

Ga voor deze taak naar ClusterControl -> Cluster selecteren -> Back-up -> Back-up maken.

We kunnen een nieuwe back-up maken of een geplande back-up configureren. Voor ons voorbeeld zullen we direct een enkele back-up maken.

We moeten één methode kiezen, de server waarvan de back-up wordt genomen en waar we de back-up willen opslaan. We kunnen onze back-up ook uploaden naar de cloud (AWS, Google of Azure) door de bijbehorende knop in te schakelen.

In dit geval kiezen we de pgbackrestfull-methode om een eerste volledige back-up te maken. Als we deze optie selecteren, zien we de volgende rode noot:

"Tijdens de eerste poging om pgBackRest-back-up te maken, zal ClusterControl het knooppunt opnieuw configureren (pgBackRest implementeren en configureren) en daarna moet het db-knooppunt eerst opnieuw worden opgestart."

Houd er dus rekening mee bij de eerste back-uppoging.

Vervolgens specificeren we het gebruik van compressie en het compressieniveau voor onze back-up.

In het back-upgedeelte kunnen we de voortgang van de back-up zien en informatie zoals de methode, grootte, locatie en meer.

De stappen zijn hetzelfde om een differentiële of incrementele back-up te maken. We hoeven alleen de gewenste methode te kiezen tijdens het maken van de back-up.

Een back-up herstellen

Zodra de back-up is voltooid, kunnen we deze herstellen met behulp van ClusterControl. Hiervoor kunnen we in onze back-upsectie (ClusterControl -> Cluster selecteren -> Back-up) "Back-up herstellen" selecteren of direct "Herstellen" op de back-up die we willen herstellen.

We hebben drie opties om de back-up te herstellen. We kunnen de back-up terugzetten in een bestaand databaseknooppunt, de back-up herstellen en verifiëren op een zelfstandige host of een nieuw cluster maken van de back-up.

Als we de optie Herstellen op knooppunt kiezen, moeten we het hoofdknooppunt specificeren, omdat dit het enige is dat in het cluster kan worden geschreven.

We kunnen de voortgang van ons herstel volgen vanuit het gedeelte Activiteit in onze ClusterControl.

Automatische back-upverificatie

Een back-up is geen back-up als deze niet herstelbaar is. Het verifiëren van back-ups is iets dat meestal door velen wordt verwaarloosd. Laten we eens kijken hoe ClusterControl de verificatie van PostgreSQL- en TimescaleDB-back-ups kan automatiseren en verrassingen kan voorkomen.

Selecteer in ClusterControl uw cluster en ga naar het gedeelte "Back-up" en selecteer vervolgens "Back-up maken".

De functie voor automatische verificatie van back-ups is beschikbaar voor de geplande back-ups. Laten we dus de optie "Back-up plannen" kiezen.

Bij het plannen van een back-up moeten we naast het selecteren van de algemene opties zoals methode of opslag ook de planning/frequentie specificeren.

In de volgende stap kunnen we onze back-up comprimeren en de functie "Back-up verifiëren" inschakelen.

Om deze functie te gebruiken, hebben we een speciale host (of VM) nodig die geen deel uitmaakt van het cluster.

ClusterControl installeert de software en herstelt de back-up in deze host. Na het herstellen kunnen we het verificatiepictogram zien in het gedeelte ClusterControl Backup.

Aanbevelingen

Er zijn ook enkele tips waarmee we rekening kunnen houden bij het maken van onze back-ups:

Bewaar de back-up op een externe locatie:we moeten de back-up niet opslaan op de databaseserver. In het geval van een serverstoring, kunnen we de database en de back-up tegelijkertijd kwijtraken.
Bewaar een kopie van de laatste back-up op de databaseserver:dit kan handig zijn voor sneller herstel.
Gebruik incrementele/differentiële back-ups:om de back-uphersteltijd en het schijfruimtegebruik te verminderen.
Maak een back-up van de WAL's:als we een database van de laatste back-up moeten herstellen, en u deze alleen herstelt, verliest u de wijzigingen sinds de back-up is gemaakt tot de hersteltijd, maar als we de WAL's hebben, kunnen we deze toepassen de wijzigingen en we kunnen PITR gebruiken.
Gebruik zowel logische als fysieke back-ups:beide zijn om verschillende redenen nodig, bijvoorbeeld als we slechts één database/tabel willen herstellen, hebben we de fysieke back-up niet nodig, we hebben alleen de logische back-up nodig en het zal nog sneller zijn dan het herstellen van de hele server.
Maak back-ups van standby-knooppunten (indien mogelijk):om extra belasting van het primaire knooppunt te voorkomen, is het een goede gewoonte om de back-up van de standby-server te nemen.
Test uw back-ups:de bevestiging dat de back-up is gemaakt, is niet voldoende om te controleren of de back-up werkt. We moeten het op een zelfstandige server herstellen en testen om verrassingen in geval van storing te voorkomen.

Conclusie

Zoals we konden zien, is pgBackRest een goede optie om onze back-upstrategie te verbeteren. Het helpt u uw gegevens te beschermen en het kan handig zijn om de RTO te bereiken door de downtime in geval van storing te verminderen. Incrementele back-ups kunnen helpen de hoeveelheid tijd en opslagruimte die voor het back-upproces wordt gebruikt, te verminderen. ClusterControl kan helpen bij het automatiseren van het back-upproces voor uw PostgreSQL- en TimescaleDB-databases en, in geval van storing, met een paar klikken herstellen.

Hoe pgBackRest te gebruiken om een ​​back-up te maken van PostgreSQL en TimescaleDB