Vad PostgreSQL-säkerhetskopior kräver
Hur hanterade PostgreSQL-kluster arkiverar till plattformens mål för säkerhetskopiering — beroendena, objekten operatorn projicerar in i varje namnrymd, sökvägarna och lagringstiden — och vad som händer utan ett mål.
Användarnas reglage Aktivera säkerhetskopieringar fungerar bara när plattformen kan skriva till ett mål för säkerhetskopiering. Den här sidan beskriver vad det kräver; användarsidan finns i Säkerhetskopior och återställning till tidpunkt.
Beroendena
PostgreSQL-säkerhetskopior använder CloudNativePG:s Barman Cloud-plugin, som skriver till samma
bucket i objektlagringen som Velero säkerhetskopierar plattformen till. Installationsprogrammet
installerar båda som plattformsberoenden: velero, och cnpg-barman-plugin, som är beroende av
cert-manager, cnpg-operator och velero och inte är valfritt.
Själva målet är Veleros: hemligheten velero med inloggningsuppgifter (nyckeln cloud, med
aws_access_key_id och aws_secret_access_key) och BackupStorageLocation default, båda i
namnrymden velero. Från lagringsplatsen tar operatorn bucketen, regionen (us-east-1 när ingen är
angiven), slutpunktens URL och, när den finns, slutpunktens CA-certifikat. Ändra målet via
plattformens inställningar för säkerhetskopiering — se Livscykelhantering —
i stället för att redigera Veleros objekt.
Vad operatorn projicerar
Varannan minut skriver Stackship-operatorn en hemlighet med inloggningsuppgifter och en Barman
ObjectStore, båda med namnet stackship-backup-target, till:
- plattformens namnrymd,
stackship-system, alltid; - varje namnrymd som innehåller ett CloudNativePG-kluster som arkiverar till
stackship-backup-target— det vill säga varje resursgrupp med ett PostgreSQL-kluster som har säkerhetskopiering påslagen.
Den tar bort dem igen från en namnrymd när inget sådant kluster finns kvar där. ObjectStore pekar
på:
| Namnrymd | Mål |
|---|---|
| Plattformens namnrymd | s3://<bucket>/platform/postgres/ |
| En resursgrupps namnrymd | s3://<bucket>/boundaries/<boundary-id>/<namespace>/postgres/ |
WAL och baskopior komprimeras med gzip. Inom den sökvägen arkiverar varje kluster under ett eget
namn: klustrets namn och ett slumpat suffix på sex tecken, som behålls så länge säkerhetskopieringen
är på; slås säkerhetskopieringen av och på igen börjar ett nytt namn. Varje
återställning flyttar klustret till nästa generation av det namnet — -g2, -g3 och så vidare — så
att det aldrig skriver till ett arkiv som redan innehåller data.
Lagringstid
Varje projicerad ObjectStore har lagringspolicyn 30d, och pluginet tillämpar den var 30:e
minut: det behåller det som behövs för att återställa till vilket ögonblick som helst de senaste 30
dagarna och tar bort äldre baskopior och WAL. Det är den enda lagringstid som gäller för användarnas
PostgreSQL-säkerhetskopior; den Backup Retention Policy en användare anger på ett kluster, och den
livslängd som begärs när en ögonblicksbild tas, ändrar den inte.
Pluginet tillämpar den från instanserna i ett körande kluster, på det arkiv som klustret skriver till. Arkiv som inget kluster skriver till längre — tidigare generationer efter en återställning, det gamla namnet efter att säkerhetskopieringen slagits av och på, och arkiven för borttagna kluster — rensas aldrig och ligger kvar i bucketen tills någon tar bort dem.
Schemalagda ögonblicksbilder
Ett kluster med säkerhetskopiering påslagen får en BackupPolicy bredvid sig, ägd av klustret.
Operatorn gör om den till en CloudNativePG ScheduledBackup med namnet <cluster>-policy, med
policyns cron-uttryck med fem fält i UTC. Den första schemalagda säkerhetskopian tas vid nästa
schemalagda tidpunkt, inte när schemat skapas, och när policyn pausas stängs den av. De schemalagda
säkerhetskopiorna ägs av CloudNativePG-klustret (backupOwnerReference: cluster), så en
återställning, som tar bort och återskapar klustret, tar bort dem; deras data finns kvar i arkivet.
Plattformens egen säkerhetskopia
Plattformens filsystemsäkerhetskopia med Velero hoppar över PostgreSQL-volymerna: varje instanspodd
har backup.velero.io/backup-volumes-excludes: pgdata,pg-wal. Ett PostgreSQL-kluster återställs
bara någonsin från sitt arkiv, som en kopia av dess volymer inte kan ersätta.
Utan ett mål
När Veleros hemlighet eller lagringsplats saknas, eller inte anger någon bucket eller några inloggningsuppgifter, projicerar operatorn ingenting — och tar inte bort något den projicerat tidigare. En användare kan fortfarande slå på säkerhetskopiering, men klustret har ingenstans att arkivera till: ingen ögonblicksbild blir klar, en ögonblicksbild eller en återställning avvisas när klustret rapporterar att arkiveringen misslyckas, och återställning till tidpunkt har inget fönster.
Så länge arkiveringen misslyckas behåller PostgreSQL varje WAL-segment som inte har arkiverats, så klustrets volymer fylls tills målet fungerar igen. Detsamma gäller när ett fungerande mål blir fullt eller slutar gå att nå.