Sådan bruger du pgBackRest til at sikkerhedskopiere PostgreSQL og TimescaleDB

Dine data er sandsynligvis de mest værdifulde aktiver i virksomheden, så du bør have en Disaster Recovery Plan (DRP) for at forhindre tab af data i tilfælde af en ulykke eller hardwarefejl. En backup er den enkleste form for DR. Det er måske ikke altid nok til at garantere et acceptabelt Recovery Point Objective (RPO), men det er en god første tilgang. Du bør også definere et Recovery Time Objective (RTO) i overensstemmelse med din virksomheds krav. Der er mange måder at nå RTO-værdien på, det afhænger af virksomhedens mål.

I denne blog vil vi se, hvordan du bruger pgBackRest til at sikkerhedskopiere PostgreSQL og TimescaleDB, og hvordan du bruger en af de vigtigste funktioner i dette sikkerhedskopieringsværktøj, kombinationen af fuld, inkrementel og differentiel sikkerhedskopiering, for at minimere nedetid.

Hvad er pgBackRest?

Der er forskellige typer sikkerhedskopier til databaser:

Logisk:Sikkerhedskopien er gemt i et menneskeligt læsbart format som SQL.
Fysisk:Sikkerhedskopien indeholder binære data.
Fuld/Inkrementel/Differentiel:Definitionen af disse tre typer sikkerhedskopier er implicit i navnet. Den fulde backup er en fuld kopi af alle dine data. Inkrementel sikkerhedskopiering sikkerhedskopierer kun de data, der er ændret siden den forrige sikkerhedskopiering, og den differentielle sikkerhedskopiering indeholder kun de data, der er ændret siden den sidste fulde sikkerhedskopiering. De inkrementelle og differentielle sikkerhedskopier blev introduceret som en måde at reducere mængden af tid og diskpladsforbrug, som det tager at udføre en fuld sikkerhedskopiering.

pgBackRest er et open source-sikkerhedskopieringsværktøj, der laver fysiske sikkerhedskopier med nogle forbedringer sammenlignet med det klassiske pg_basebackup-værktøj. Vi kan bruge pgBackRest til at udføre en indledende databasekopi til streaming-replikering ved at bruge en eksisterende backup, eller vi kan bruge delta-indstillingen til at genopbygge en gammel standby-server.

Nogle af de vigtigste pgBackRest-funktioner er:

Parallel sikkerhedskopiering og gendannelse
Lokal eller fjernbetjening
Fuld, trinvis og differentiel sikkerhedskopiering
Sikkerhedskopieringsrotation og arkivudløb
Tjek af sikkerhedskopieringsintegritet
Backup-CV
Delta-gendannelse
Kryptering

Lad os nu se, hvordan vi kan bruge pgBackRest til at sikkerhedskopiere vores PostgreSQL- og TimescaleDB-databaser.

Sådan bruges pgBackRest

Til denne test bruger vi CentOS 7 som OS og PostgreSQL 11 som databaseserver. Vi antager, at du har databasen installeret, hvis ikke, kan du følge disse links for at implementere både PostgreSQL eller TimescaleDB på en nem måde ved at bruge ClusterControl.

Først skal vi installere pgbackrest-pakken.

$ yum install pgbackrest

pgBackRest kan bruges fra kommandolinjen eller fra en konfigurationsfil, der som standard findes i /etc/pgbackrest.conf på CentOS7. Denne fil indeholder følgende linjer:

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

Du kan tjekke dette link for at se, hvilken parameter vi kan tilføje i denne konfigurationsfil.

Vi tilføjer følgende linjer:

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

Sørg for, at du har tilføjet følgende konfiguration i postgresql.conf-filen (disse ændringer kræver en genstart af tjenesten).

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

Lad os nu tage en grundlæggende backup. Først skal vi oprette en "strofe", der definerer backup-konfigurationen for en specifik PostgreSQL- eller TimescaleDB-databaseklynge. Strofeafsnittet skal definere databaseklyngens sti og vært/bruger, hvis databaseklyngen er ekstern.

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

Og så kan vi køre check-kommandoen for at validere 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)

For at tage sikkerhedskopien skal du køre følgende 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 sikkerhedskopieringen færdig med outputtet "fuldført med succes", så lad os gå for at gendanne den. Vi stopper postgresql-11-tjenesten.

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

Og lad datakataloget være tomt.

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

Kør nu følgende 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)

Start derefter postgresql-11-tjenesten.

$ service postgresql-11 stop

Og nu har vi vores database oppe at køre.

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

Lad os nu se, hvordan vi kan tage en differentiel backup.

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

For mere komplekse sikkerhedskopier kan du følge pgBackRest brugervejledningen.

Som vi nævnte tidligere, kan du bruge kommandolinjen eller konfigurationsfilerne til at administrere dine sikkerhedskopier.

Sådan bruges pgBackRest i ClusterControl

Siden version 1.7.2 har ClusterControl tilføjet understøttelse af pgBackRest til sikkerhedskopiering af PostgreSQL- og TimescaleDB-databaser, så lad os se, hvordan vi kan bruge det fra ClusterControl.

Oprettelse af en sikkerhedskopi

For denne opgave skal du gå til ClusterControl -> Vælg Cluster -> Backup -> Create Backup.

Vi kan oprette en ny backup eller konfigurere en planlagt en. For vores eksempel vil vi oprette en enkelt sikkerhedskopi med det samme.

Vi skal vælge én metode, den server, som sikkerhedskopien skal tages fra, og hvor vi vil gemme sikkerhedskopien. Vi kan også uploade vores backup til skyen (AWS, Google eller Azure) ved at aktivere den tilsvarende knap.

I dette tilfælde vælger vi pgbackrestfull-metoden for at tage en indledende fuld backup. Når du vælger denne mulighed, vil vi se følgende røde note:

"Under første forsøg på at lave pgBackRest backup, vil ClusterControl genkonfigurere noden (udruller og konfigurerer pgBackRest), og derefter skal db noden genstartes først."

Så tag venligst det i betragtning ved det første sikkerhedskopieringsforsøg.

Derefter angiver vi brugen af komprimering og komprimeringsniveauet for vores backup.

På sikkerhedskopieringssektionen kan vi se sikkerhedskopieringens fremskridt og information som metode, størrelse, placering og mere.

Trinnene er de samme for at skabe en differential af inkrementel backup. Vi behøver kun at vælge den ønskede metode under oprettelsen af backup.

Gendannelse af en sikkerhedskopi

Når sikkerhedskopieringen er færdig, kan vi gendanne den ved at bruge ClusterControl. Til dette kan vi i vores backup-sektion (ClusterControl -> Vælg Cluster -> Backup) vælge "Gendan sikkerhedskopiering", eller direkte "Gendan" på den sikkerhedskopi, som vi ønsker at gendanne.

Vi har tre muligheder for at gendanne sikkerhedskopien. Vi kan gendanne sikkerhedskopien i en eksisterende databaseknude, gendanne og verificere sikkerhedskopien på en selvstændig vært eller oprette en ny klynge fra sikkerhedskopien.

Hvis vi vælger muligheden Gendan på node, skal vi angive masterknuden, fordi den er den eneste, der kan skrives i klyngen.

Vi kan overvåge forløbet af vores gendannelse fra aktivitetssektionen i vores ClusterControl.

Automatisk sikkerhedskopiering

En sikkerhedskopi er ikke en sikkerhedskopi, hvis den ikke kan gendannes. Bekræftelse af sikkerhedskopier er noget, der normalt forsømmes af mange. Lad os se, hvordan ClusterControl kan automatisere verificeringen af PostgreSQL- og TimescaleDB-sikkerhedskopier og hjælpe med at undgå overraskelser.

I ClusterControl skal du vælge din klynge og gå til sektionen "Backup", og derefter vælge "Opret sikkerhedskopi".

Funktionen til automatisk bekræftelse af sikkerhedskopiering er tilgængelig for de planlagte sikkerhedskopier. Så lad os vælge muligheden "Schedule Backup".

Når vi planlægger en sikkerhedskopiering, skal vi ud over at vælge de almindelige muligheder som metode eller lagring også specificere tidsplan/hyppighed.

I det næste trin kan vi komprimere vores sikkerhedskopi og aktivere funktionen "Bekræft sikkerhedskopiering".

For at bruge denne funktion har vi brug for en dedikeret vært (eller VM), der ikke er en del af klyngen.

ClusterControl installerer softwaren, og den gendanner sikkerhedskopien i denne vært. Efter gendannelse kan vi se bekræftelsesikonet i afsnittet ClusterControl Backup.

Anbefalinger

Der er også nogle tips, som vi kan tage i betragtning, når vi laver vores sikkerhedskopier:

Gem sikkerhedskopien på en fjernplacering:Vi bør ikke gemme sikkerhedskopien på databaseserveren. I tilfælde af serverfejl kan vi miste databasen og sikkerhedskopien på samme tid.
Behold en kopi af den seneste sikkerhedskopi på databaseserveren:Dette kan være nyttigt for hurtigere gendannelse.
Brug trinvise/differentielle sikkerhedskopier:For at reducere gendannelsestiden for backup og forbruget af diskplads.
Sikkerhedskopier WAL'erne:Hvis vi skal gendanne en database fra den sidste sikkerhedskopi, hvis du kun gendanner den, mister du ændringerne, siden sikkerhedskopien blev taget, indtil gendannelsestidspunktet, men hvis vi har WAL'erne, kan vi anvende ændringerne, og vi kan bruge PITR.
Brug både logiske og fysiske sikkerhedskopier:Begge er nødvendige af forskellige årsager, for eksempel, hvis vi kun ønsker at gendanne én database/tabel, har vi ikke brug for den fysiske backup, vi har kun brug for den logiske backup, og det vil være endnu hurtigere end at gendanne hele serveren.
Tag sikkerhedskopier fra standby-knudepunkter (hvis det er muligt):For at undgå ekstra belastning på den primære knude, er det en god praksis at tage backup fra standby-serveren.
Test dine sikkerhedskopier:Bekræftelsen af, at sikkerhedskopieringen er udført, er ikke nok til at sikre, at sikkerhedskopieringen fungerer. Vi bør gendanne den på en selvstændig server og teste den for at undgå en overraskelse i tilfælde af fejl.

Konklusion

Som vi kunne se, er pgBackRest en god mulighed for at forbedre vores backup-strategi. Det hjælper dig med at beskytte dine data, og det kan være nyttigt at nå RTO'en ved at reducere nedetiden i tilfælde af fejl. Inkrementelle sikkerhedskopier kan hjælpe med at reducere mængden af tid og lagerplads, der bruges til sikkerhedskopieringsprocessen. ClusterControl kan hjælpe med at automatisere backup-processen for dine PostgreSQL- og TimescaleDB-databaser og, i tilfælde af fejl, genskabe den med et par klik.