Det aktuella tillståndet för Open Source Backup Management för PostgreSQL

Det finns många sätt att ta itu med säkerhetskopiering av ett PostgreSQL-kluster. Det finns flera artiklar och bloggar som presenterar de olika teknikerna med vilka vi kan spara vår värdefulla data i PostgreSQL. Det finns logiska säkerhetskopieringslösningar, fysisk säkerhetskopiering på OS-nivå, på filsystemsnivå och så vidare. Här i den här bloggen kommer vi inte att täcka den teoretiska delen som täcks tillräckligt av olika bloggar och artiklar samt den officiella dokumentationen.

Den här bloggen fokuserar på tillståndet för de olika tillgängliga verktygen och lösningarna och ett försök att presentera en grundlig jämförelse baserad på verkliga upplevelser. Den här artikeln försöker inte på något sätt marknadsföra någon specifik produkt, jag gillar verkligen alla verktyg, lösningar och tekniker som beskrivs i den här bloggen. Syftet här är att notera deras styrkor, deras svagheter och att vägleda slutanvändaren till vilket verktyg som bäst passar hans/hennes miljö, infrastruktur och specifika krav. Här är en trevlig artikel som beskriver säkerhetskopieringsverktyg för PostgreSQL på olika nivåer.

Jag kommer inte att beskriva hur man använder de olika verktygen i denna blogg, eftersom denna information finns dokumenterad i ovanstående blogg och även i de officiella dokumenten samt andra resurser över nätet. Men jag kommer att beskriva för- och nackdelarna så som jag upplevde dem i praktiken. I den här bloggen sysslar vi uteslutande med klassiska PITR-baserade fysiska PostgreSQL-säkerhetskopior beroende på:

• pg_basebackup eller pg_start_backup()/pg_stop_backup
• fysisk kopia
• arkivering av WALs eller strömmande replikering

Det finns flera fina produkter och lösningar, vissa är öppen källkod och gratis att använda medan andra är kommersiella. Såvitt jag vet är dessa:

• pgbarman av 2ndquadrant (gratis)
• pgbackrest (gratis)
• pg_probackup av Postgres Professional (gratis)
• BART av EDB (kommersiell)

Jag hade inte chansen att prova BART eftersom det körs på varianter av Linux som jag inte använder. I den här bloggen kommer jag att inkludera mina egna tankar och intryck samtidigt som jag interagerar med respektive författare/gemenskap/underhållare av varje lösning eftersom detta är en mycket viktig aspekt som vanligtvis underskattas i början. Lite terminologi för att bättre förstå de olika termerna i vart och ett av verktygen:

pgbarman

Pgbarman eller bara barman är det äldsta av dessa verktyg. Den senaste versionen är 2.6 (släpptes medan jag hade den här bloggen på gång! vilket är fantastiska nyheter).

Pgbarman stöder bassäkerhetskopiering via två metoder:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

och WAL-överföring via:

• WAL-arkivering
  • via rsync
  • via barman-wal-archive / put-wal
• WAL via strömmande replikering med replikeringsplats
  • Asynkron
  • Synkron

Detta ger oss 8 out of the box-kombinationer som vi kan använda barman med. Var och en har sina för- och nackdelar.

Bas backup via pg_basebackup (backup_method =postgres)

Fördelar:

• det senaste/moderna sättet
• förlitar sig på beprövad kärnteknik inom PostgreSQL
• rekommenderas av de officiella dokumenten

Nackdelar:

• ingen inkrementell säkerhetskopiering
• ingen parallell säkerhetskopiering
• ingen nätverkskomprimering
• ingen datadeduplicering
• ingen bandbreddsgräns för nätverket

Bas backup via rsync (backup_method =rsync)

Fördelar:

• gammal och beprövad
• Inkrementell säkerhetskopiering
• datadeduplicering
• nätverkskomprimering
• parallell säkerhetskopiering
• nätets bandbreddsgräns

Nackdelar:

• inte det (av författarna) rekommenderade sättet

WAL-överföring via WAL-arkivering (via rsync)

Fördelar:

• enklare att ställa in

Nackdelar:

• Ingen RPO=0 (noll dataförlust)
• inget sätt att återställa efter långa och ihållande nätverksfel

WAL-överföring via WAL-arkivering (via barman-wal-archive / put-wal)

Fördelar:

• det senaste och rekommenderade sättet (introducerat i 2.6)
• mer pålitlig/säker än rsync

Nackdelar:

• Ingen RPO=0 (noll dataförlust)
• fortfarande inget sätt att återställa från långa och ihållande nätverksfel

WAL-överföring via WAL-streaming med replikeringsplats (via pg_receivewal)

Fördelar:

• modernare (och rekommenderas)
• RPO=0 (noll dataförlust) i synkront läge

Nackdelar:

• alltid associerad med replikeringsplats. Kan växa vid nätverksfel

Så medan pg_basebackup (postgres-metoden) verkar vara framtiden för pgbarman, kommer i verkligheten alla tjusiga funktioner med rsync-metoden. Så låt oss lista alla funktioner i Barman mer detaljerat:

• Fjärrdrift (säkerhetskopiering/återställning)
• Inkrementella säkerhetskopior. En av de fantastiska egenskaperna hos barman, inkrementella säkerhetskopior är baserade på filnivåjämförelse av databasfilerna mot dem från den senaste säkerhetskopian i katalogen. I barman hänvisar termen "differentiell" till ett annat koncept:Med barmans terminologi är en differentiell backup den sista backupen + de individuella ändringarna från den senaste backupen. Barman-dokument säger att de tillhandahåller differentiella säkerhetskopior via WAL. Barman inkrementella säkerhetskopior fungerar på filnivå, vilket innebär att om en fil ändras överförs hela filen. Detta är som pgbackrest och till skillnad från vissa andra erbjudanden som pg_probackup eller BART som stöder differentiella/inkrementella säkerhetskopieringar på blocknivå. Inkrementella säkerhetskopior av barman specificeras via:reuse_backup =länk eller kopia. Genom att definiera "kopiera" uppnår vi minskad tid för säkerhetskopieringen eftersom endast de ändrade filerna överförs och säkerhetskopieras men fortfarande ingen minskning av utrymmet eftersom de oförändrade filerna kopieras från den tidigare säkerhetskopian. Genom att definiera "länk" är de oförändrade filerna hårdlänkade (ej kopierade) från den senaste säkerhetskopian. På så sätt uppnår vi både tidsminskning och utrymmesminskning. Jag vill inte på något sätt skapa mer förvirring i detta, men i verkligheten är barman inkrementella säkerhetskopior direkt jämförbara med pgbackrest inkrementella säkerhetskopior, eftersom barman behandlar (via länk eller kopia) en inkrementell säkerhetskopia effektivt som en fullständig säkerhetskopia. Så i båda systemen hanterar en inkrementell säkerhetskopia filerna som ändrades sedan den senaste säkerhetskopieringen. Men när det gäller differentiella säkerhetskopieringar betyder det en annan sak i vart och ett av de ovannämnda systemen, som vi kommer att se nedan.
• Säkerhetskopiera från vänteläge. Barman ger alternativet att utföra huvuddelen av basbackup-operationerna från ett standby-läge och på så sätt frigör den primära från den extra IO-belastningen. Observera dock att WAL fortfarande måste komma från den primära. Det spelar ingen roll om du använder archive_command eller WAL-strömning via replikeringsplatser, du kan ännu inte (när detta skrivs med barman på version 2.6) ladda ner den här uppgiften till vänteläge.
• parallella jobb för säkerhetskopiering och återställning
• En rik och omfattande uppsättning lagringsinställningar baserat på antingen:
  • Redundans (antal säkerhetskopior att behålla)
  • Återställningsfönster (hur tillbaka i det förflutna ska säkerhetskopiorna behållas)
  Enligt min mening ur ett användarperspektiv är ovanstående bra. Användaren kan definiera reuse_backup =länk och ett återställningsfönster och låta barman (dess cron-jobb) ta hand om resten. Inga diff/incr/full etc backups att oroa sig för eller schemalägga eller hantera. Systemet (barman) gör helt enkelt rätt sak på ett transparent sätt.
• Programmera dina egna pre/post event hook-skript.
• Ommappning av tabellutrymme

Det är barmans bästa styrkor. Och detta är verkligen nästan mer än vad den genomsnittliga DBA skulle begära av ett verktyg för säkerhetskopiering och återställning. Det finns dock några punkter som kan vara bättre:

• E-postlistan är inte så aktiv och underhållarna skriver eller svarar sällan på frågor
• Ingen funktion för att återuppta en misslyckad/avbruten säkerhetskopiering
• Replikeringsplatser eller användningen av rsync/barman-wal-archive för arkivering är inte förlåtande i händelse av fel i nätverket eller andra fel på säkerhetskopieringsplatsen. I båda fallen, om nätverksavbrottet är tillräckligt länge och ändringarna i DB är värda många WAL-filer, kommer den primära att drabbas av "inget utrymme kvar på enheten" och så småningom krascha. (inte bra). Det som är lovande här är att barman nu tillhandahåller ett alternativt (till rsync) sätt att överföra WAL så att ytterligare skydd mot t.ex. pg_wal utrymmesutmattning kan komma att implementeras i framtiden, vilket tillsammans med säkerhetskopiering skulle verkligen göra barman perfekt, åtminstone för mig.

pg ryggstöd

Pgbackrest är den nuvarande trenden bland säkerhetskopieringsverktygen med öppen källkod, främst på grund av dess effektivitet för att klara av mycket stora datamängder och den extrema omsorg som dess skapare lägger på validering av säkerhetskopior via kontrollsummor. När detta skrivs finns den på version v2.09, och dokumenten finns här. Användarhandboken kan vara något föråldrad men resten av dokumenten är mycket uppdaterade och korrekta. Pgbackrest förlitar sig på WAL-arkivering med sitt eget archive_command och sin egen filöverföringsmekanism som är bättre och säkrare än rsync. Så pgbackrest är ganska framåt eftersom det inte ger den större uppsättningen valmöjligheter som barman erbjuder. Eftersom det inte finns något synkront läge inblandat, garanterar naturligtvis inte pgbackrest RPO=0 (noll dataförlust). Låt oss beskriva pgbackrests koncept:

• En säkerhetskopia kan vara:
  • Full. En fullständig säkerhetskopia kopierar hela databasklustret.
  • Differential (diff). En differentiell säkerhetskopia kopierar endast de filer som har ändrats sedan den senaste fullständiga säkerhetskopieringen. För en lyckad återställning måste både den differentiella säkerhetskopian och den tidigare fullständiga säkerhetskopian vara giltiga.
  • Inkrementell (inkr). En inkrementell säkerhetskopia kopierar endast de filer som har ändrats sedan den senaste säkerhetskopieringen (vilket kan vara en fullständig säkerhetskopia, en differentiell eller till och med en inkrementell). På samma sätt som den differentiella säkerhetskopian måste alla tidigare nödvändiga säkerhetskopior (inklusive denna säkerhetskopia, den senaste skillnaden och den föregående fullständiga) vara giltiga för att kunna göra en framgångsrik återställning.
• En strof är definitionen av alla nödvändiga parametrar i ett PostgreSQL-kluster. En PostgreSQL-server har normalt sin egen strof, medan backupservrar kommer att ha en strof för varje PostgreSQL-kluster som de säkerhetskopierar.
• En konfiguration är där information om strofer förvaras (vanligtvis /etc/pgbackrest.conf)
• Ett arkiv är där pgbackrest förvarar WALs och säkerhetskopior

Användaren uppmuntras att följa dokumentationen som dokumentationen själv föreslår, uppifrån och ned. De viktigaste egenskaperna hos pgbackrest är:

• Parallell säkerhetskopiering och återställning
• Ingen direkt SQL-åtkomst till PostgreSQL-servern behövs
• Lokal/fjärrdrift
• Retention baserat på:
  • fullständig säkerhetskopiering (antal fullständiga säkerhetskopior att behålla)
  • diff backup retention (antal diff backups att behålla)
  Inkrementella säkerhetskopior har inte sin egen lagring och förfaller så snart en tidigare säkerhetskopia går ut. Så användaren kan definiera ett schema för att ta fullständiga säkerhetskopior och en rullande uppsättning olika säkerhetskopior mellan dem.
• Säkerhetskopiera från vänteläge. Vissa filer måste fortfarande komma från den primära men bulkkopieringen sker i vänteläge. Fortfarande måste WAL härröra från den primära.
• Säkerhetskopieringsintegritet. Personerna bakom pgbackrest är extremt försiktiga när det kommer till säkerhetskopiornas integritet. Varje fil checksummas vid säkerhetskopiering och kontrolleras även efter återställningen för att säkerställa att inga problematiska hårdvaru- eller mjukvarufel kan resultera i en felaktig återställning. Om sidnivåkontrollsummor är aktiverade på PostgreSQL-klustret så beräknas de också för varje fil. Dessutom beräknas kontrollsummor för varje WAL-fil.
• Om komprimering är inaktiverad och hårda länkar är aktiverade är det möjligt att ta fram klustret direkt från katalogen. Detta är extremt viktigt för stora databaser med flera TB.
• Återuppta en misslyckad/avbruten back. Mycket praktiskt vid opålitliga nätverk.
• Delta återställning:Ultrasnabb återställning för stora databaser, utan att rensa hela klustret.
• Asynkron &Parallell WAL-push till backupservern. Detta är en av de starkaste punkterna med pgbackrest. PostgreSQL-arkiveraren kopierar bara till spoolen via archive-push och det tunga jobbet med överföringen och bearbetningen sker i en separat pgbackrest-process. Detta möjliggör massiva WAL-överföringar samtidigt som man säkerställer låga PostgreSQL-svarstider.
• Ommappning av tabellutrymme
• Stöd för Amazon S3
• Stöd för maximal WAL-köstorlek. När säkerhetskopieringsplatsen är nere eller nätverket misslyckas, kommer användningen av det här alternativet att håna som om arkiveringen lyckades, vilket gör att PostgreSQL kan ta bort WAL och förhindra att pg_wal fylls på och på så sätt rädda pgsql-servern från en potentiell PANIK.

Så funktionsmässigt lägger pgbackrest stor vikt när det kommer till datavalidering och prestanda, ingen överraskning att det används av de största och mest trafikerade PostgreSQL-installationerna. Det finns dock en sak som kan förbättras:

• Det skulle verkligen vara praktiskt att ha ett mer "liberalt" alternativ när det gäller lagring, d.v.s. tillhandahålla ett sätt att deklarativt specificera en lagringsperiod och sedan låta pgbackrest hantera full/diff/incr säkerhetskopior efter behov.

pg_probackup

Pg_proback är ett annat lovande verktyg för säkerhetskopiering. Den är ursprungligen baserad på pg_arman. Dess tonvikt ligger på säkerhetskopieringens prestanda. Det är baserat på kataloger och instanser, mycket likt resten av verktygen, så vi har. Dess huvudsakliga funktioner inkluderar:

• Riktigt stöd på säkerhetskopieringsnivå som sträcker sig från:
  • Fullständiga säkerhetskopior
  • Inkrementell av tre typer:
    • SIDA backup. Nivåändringar hittade via WAL-skanning. Kräver full åtkomst till den oavbrutna WAL-sekvensen sedan föregående säkerhetskopiering.
    • DELTA backup. Endast ändrade sidor kopieras till säkerhetskopian. Oberoende av WAL-arkivering, lägger viss belastning på servern.
    • PTRACK backup. Kräver speciell pgsql core patching. Fungerar genom att bibehålla en bitmapp i farten så snart sidorna ändras. Riktigt snabb säkerhetskopiering med minimal belastning på servern.
• Säkerhetskopieringar kan också delas in i:
  • Autonoma säkerhetskopieringar. De har inga krav på WAL utanför backupen. Ingen PITR.
  • Arkivera säkerhetskopior. De förlitar sig på kontinuerlig arkivering och stöder PITR.
• flertrådad modell (i motsats till barman, pgbackrest och självklart PostgreSQL som följer en multiprocessmodell)
• Datakonsistens och validering på begäran utan återställning
• Säkerhetskopiera från ett standby-läge utan åtkomst till den primära.
• En uttrycksfull lagringspolicyspecifikation där redundans kan användas på ett OCH-sätt tillsammans med ett fönster. Sammanfogning av säkerhetskopior (via sammanfogning) stöds genom att konvertera tidigare inkrementella säkerhetskopior till fulla som ett sätt att frigöra utrymme och för att tillhandahålla en metod för smidig säkerhetskopiering.

Så, pg_probackup tillhandahåller en uppsättning fantastiska funktioner med betoning på prestanda, något som skulle gynna stora installationer. Det är dock fortfarande några saker som saknas, nämligen:

• Ingen officiell version stöder fjärrsäkerhetskopiering. Det betyder att pg_probackup måste köras på samma värd som pgsql-klustret. (Det finns en dev-gren som hanterar säkerhetskopiering från en fjärrplats samt arkivering till en fjärrserver för säkerhetskopiering)
• Inget stöd för en misslyckad säkerhetskopiering.

Vi kan sammanfatta styckena ovan med en funktionsmatris som nedan.

ClusterControl

ClusterControl tillhandahåller funktionen att antingen generera en omedelbar säkerhetskopiering eller att schemalägga en och automatisera uppgiften på ett enkelt och snabbt sätt.

Vi kan välja mellan två backupmetoder, pgdump (logisk) och pg_basebackup (binär). Vi kan också specificera var säkerhetskopiorna ska lagras (på databasservern, på ClusterControl-servern eller i molnet), komprimeringsnivån och kryptering.

Med ClusterControl kan vi också använda funktionen Point-in-Time Recovery och backupverifiering för att validera den genererade säkerhetskopian.