Hur man använder pgBackRest för att säkerhetskopiera PostgreSQL och TimescaleDB

Din data är förmodligen den mest värdefulla tillgången i företaget, så du bör ha en Disaster Recovery Plan (DRP) för att förhindra dataförlust i händelse av en olycka eller hårdvarufel. En backup är den enklaste formen av DR. Det kanske inte alltid räcker för att garantera ett acceptabelt Recovery Point Objective (RPO) men är ett bra första tillvägagångssätt. Du bör också definiera ett mål för återhämtningstid (RTO) enligt ditt företags krav. Det finns många sätt att nå RTO-värdet, det beror på företagets mål.

I den här bloggen kommer vi att se hur man använder pgBackRest för att säkerhetskopiera PostgreSQL och TimescaleDB och hur man använder en av de viktigaste funktionerna i detta säkerhetskopieringsverktyg, kombinationen av fullständiga, inkrementella och differentiella säkerhetskopior, för att minimera driftstopp.

Vad är pgBackRest?

Det finns olika typer av säkerhetskopior för databaser:

Logiskt:Säkerhetskopieringen lagras i ett läsbart format som SQL.
Fysisk:Säkerhetskopieringen innehåller binära data.
Fullständig/Inkrementell/Differentiell:Definitionen av dessa tre typer av säkerhetskopior är implicit i namnet. Den fullständiga säkerhetskopian är en fullständig kopia av alla dina data. Inkrementell säkerhetskopiering säkerhetskopierar endast de data som har ändrats sedan föregående säkerhetskopiering och den differentiella säkerhetskopieringen innehåller endast de data som har ändrats sedan den senaste fullständiga säkerhetskopieringen utfördes. De inkrementella och differentiella säkerhetskopieringarna introducerades som ett sätt att minska mängden tid och diskutrymmesanvändning som det tar att utföra en fullständig säkerhetskopiering.

pgBackRest är ett säkerhetskopieringsverktyg med öppen källkod som skapar fysiska säkerhetskopior med vissa förbättringar jämfört med det klassiska verktyget pg_basebackup. Vi kan använda pgBackRest för att utföra en första databaskopia för Streaming Replication genom att använda en befintlig säkerhetskopia, eller så kan vi använda deltaalternativet för att bygga om en gammal standby-server.

Några av de viktigaste pgBackRest-funktionerna är:

Parallell säkerhetskopiering och återställning
Lokal eller fjärrstyrd drift
Fullständiga, inkrementella och differentiella säkerhetskopior
Säkerhetskopieringsrotation och arkiveringstid
Kontroll av säkerhetskopieringsintegritet
CV för säkerhetskopiering
Deltaåterställning
Kryptering

Nu ska vi se hur vi kan använda pgBackRest för att säkerhetskopiera våra PostgreSQL- och TimescaleDB-databaser.

Hur man använder pgBackRest

För detta test kommer vi att använda CentOS 7 som OS och PostgreSQL 11 som databasserver. Vi antar att du har databasen installerad, om inte kan du följa dessa länkar för att distribuera både PostgreSQL eller TimescaleDB på ett enkelt sätt genom att använda ClusterControl.

Först måste vi installera pgbackrest-paketet.

$ yum install pgbackrest

pgBackRest kan användas från kommandoraden eller från en konfigurationsfil som finns som standard i /etc/pgbackrest.conf på CentOS7. Den här filen innehåller följande rader:

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

Du kan kontrollera den här länken för att se vilken parameter vi kan lägga till i den här konfigurationsfilen.

Vi lägger till följande rader:

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

Se till att du har lagt till följande konfiguration i postgresql.conf-filen (dessa ändringar kräver omstart av tjänsten).

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

Låt oss nu ta en grundläggande säkerhetskopia. Först måste vi skapa en "strofe", som definierar säkerhetskopieringskonfigurationen för ett specifikt PostgreSQL- eller TimescaleDB-databaskluster. Strofsektionen måste definiera databasklustrets sökväg och värd/användare om databasklustret är avlägset.

$ 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)

Och sedan kan vi köra kontrollkommandot för att validera konfigurationen.

$ 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)

För att ta säkerhetskopian, kör följande kommando:

$ 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 har vi säkerhetskopieringen klar med utgången "slutförd framgångsrikt", så låt oss återställa den. Vi kommer att stoppa postgresql-11-tjänsten.

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

Och lämna datakatalogen tom.

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

Kör nu följande kommando:

$ 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)

Starta sedan tjänsten postgresql-11.

$ service postgresql-11 stop

Och nu har vi vår databas igång.

$ 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)

Nu ska vi se hur vi kan ta en differentiell säkerhetskopiering.

$ 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)

För mer komplexa säkerhetskopior kan du följa pgBackRest användarguide.

Som vi nämnde tidigare kan du använda kommandoraden eller konfigurationsfilerna för att hantera dina säkerhetskopior.

Hur man använder pgBackRest i ClusterControl

Sedan version 1.7.2 har ClusterControl lagt till stöd för pgBackRest för säkerhetskopiering av PostgreSQL- och TimescaleDB-databaser, så låt oss se hur vi kan använda det från ClusterControl.

Skapa en säkerhetskopia

För denna uppgift, gå till ClusterControl -> Välj Cluster -> Backup -> Create Backup.

Vi kan skapa en ny säkerhetskopia eller konfigurera en schemalagd. För vårt exempel kommer vi att skapa en enda säkerhetskopia direkt.

Vi måste välja en metod, servern som backupen ska tas från och var vi vill lagra backupen. Vi kan också ladda upp vår säkerhetskopia till molnet (AWS, Google eller Azure) genom att aktivera motsvarande knapp.

I det här fallet väljer vi pgbackrestfull-metoden för att ta en första fullständig säkerhetskopiering. När du väljer det här alternativet ser vi följande röda anteckning:

"Under första försöket att göra pgBackRest-säkerhetskopiering kommer ClusterControl att konfigurera om noden (distribuerar och konfigurerar pgBackRest) och efter det måste db-noden startas om först."

Så snälla, ta hänsyn till det vid första säkerhetskopieringsförsöket.

Sedan anger vi användningen av komprimering och komprimeringsnivån för vår backup.

I avsnittet för säkerhetskopiering kan vi se hur säkerhetskopieringen fortskrider och information som metod, storlek, plats och mer.

Stegen är desamma för att skapa en differential av inkrementell säkerhetskopiering. Vi behöver bara välja önskad metod under säkerhetskopieringen.

Återställa en säkerhetskopia

När säkerhetskopieringen är klar kan vi återställa den genom att använda ClusterControl. För detta, i vår säkerhetskopieringssektion (ClusterControl -> Välj Cluster -> Backup), kan vi välja "Återställ säkerhetskopia", eller direkt "Återställ" på säkerhetskopian som vi vill återställa.

Vi har tre alternativ för att återställa säkerhetskopian. Vi kan återställa säkerhetskopian i en befintlig databasnod, återställa och verifiera säkerhetskopian på en fristående värd eller skapa ett nytt kluster från säkerhetskopian.

Om vi väljer alternativet Återställ på nod måste vi ange huvudnoden, eftersom det är den enda skrivbara i klustret.

Vi kan övervaka utvecklingen av vår återställning från aktivitetssektionen i vår ClusterControl.

Automatisk säkerhetskopiering

En säkerhetskopia är inte en säkerhetskopia om den inte går att återställa. Att verifiera säkerhetskopior är något som vanligtvis försummas av många. Låt oss se hur ClusterControl kan automatisera verifieringen av PostgreSQL- och TimescaleDB-säkerhetskopior och hjälpa till att undvika överraskningar.

I ClusterControl, välj ditt kluster och gå till avsnittet "Säkerhetskopiering", välj sedan "Skapa säkerhetskopia".

Funktionen för automatisk verifiering av säkerhetskopiering är tillgänglig för de schemalagda säkerhetskopieringarna. Så låt oss välja alternativet "Schemalägg säkerhetskopiering".

När vi schemalägger en säkerhetskopiering måste vi, förutom att välja de vanliga alternativen som metod eller lagring, även ange schema/frekvens.

I nästa steg kan vi komprimera vår säkerhetskopia och aktivera funktionen "Verifiera säkerhetskopiering".

För att använda den här funktionen behöver vi en dedikerad värd (eller virtuell dator) som inte är en del av klustret.

ClusterControl kommer att installera programvaran och den kommer att återställa säkerhetskopian i denna värd. Efter återställning kan vi se verifieringsikonen i avsnittet ClusterControl Backup.

Rekommendationer

Det finns också några tips som vi kan ta hänsyn till när vi skapar våra säkerhetskopior:

Lagra säkerhetskopian på en avlägsen plats:Vi bör inte lagra säkerhetskopian på databasservern. I händelse av serverfel kan vi förlora databasen och säkerhetskopian samtidigt.
Behåll en kopia av den senaste säkerhetskopian på databasservern:Detta kan vara användbart för snabbare återställning.
Använd inkrementella/differentiella säkerhetskopior:För att minska återställningstiden för säkerhetskopiering och användning av diskutrymme.
Säkerhetskopiera WAL:erna:Om vi behöver återställa en databas från den senaste säkerhetskopian, om du bara återställer den, kommer du att förlora ändringarna sedan säkerhetskopian togs fram till återställningstiden, men om vi har WALs kan vi tillämpa ändringarna och vi kan använda PITR.
Använd både logiska och fysiska säkerhetskopior:Båda är nödvändiga av olika anledningar, till exempel om vi bara vill återställa en databas/tabell behöver vi inte den fysiska säkerhetskopian, vi behöver bara den logiska säkerhetskopian och det kommer att vara ännu snabbare än att återställa hela servern.
Ta säkerhetskopior från standby-noder (om det är möjligt):För att undvika extra belastning på den primära noden är det en bra praxis att ta säkerhetskopian från standby-servern.
Testa dina säkerhetskopior:Bekräftelsen på att säkerhetskopieringen är klar räcker inte för att säkerställa att säkerhetskopieringen fungerar. Vi bör återställa den på en fristående server och testa den för att undvika en överraskning i händelse av fel.

Slutsats

Som vi kunde se är pgBackRest ett bra alternativ för att förbättra vår säkerhetskopieringsstrategi. Det hjälper dig att skydda dina data och det kan vara användbart att nå RTO:n genom att minska stilleståndstiden vid fel. Inkrementella säkerhetskopieringar kan hjälpa till att minska mängden tid och lagringsutrymme som används för säkerhetskopieringsprocessen. ClusterControl kan hjälpa till att automatisera säkerhetskopieringsprocessen för dina PostgreSQL- och TimescaleDB-databaser och, i händelse av fel, återställa den med några få klick.