Strategier for katastrofegjenoppretting

Selv med oppsett for høy tilgjengelighet (HA), for eksempel replikering, kan uventede katastrofer oppstå. Det kan være strømbrudd i datasentre, omfattende korrupsjon eller menneskelige feil.

Katastrofegjenoppretting (DR) er plan B-en din. Det handler om å gjenopprette databasesystemet etter en katastrofal hendelse for å begrense datatap og nedetid.

Det er lett å forveksle høy tilgjengelighet (HA) med katastrofegjenoppretting (DR), men de har ulike formål:

• HA: Har som mål å holde systemene i drift med minimale avbrudd ved mindre feil (for eksempel et enkelt serverkrasj eller et kortvarig nettverksproblem). Det innebærer ofte automatisk failover til en standby.
• DR: Fokuserer på gjenoppretting etter omfattende og alvorlige feil som setter en hel region eller flere komponenter ut av drift, og der HA alene kanskje ikke er tilstrekkelig.

Replikering er en grunnpilar for begge, men DR krever ekstra planlegging for gjenoppretting.

En robust plan for katastrofegjenoppretting av PostgreSQL består av flere viktige komponenter:

• Regelmessige sikkerhetskopier: Både fullstendige base-backuper og kontinuerlig arkivering av Write-Ahead Log (WAL).
• Gjenopprettingsmål: Fastsettelse av RTO (Recovery Time Objective) og RPO (Recovery Point Objective).
• Lagring utenfor området: Sikker lagring av sikkerhetskopier utenfor det primære datasenteret.
• Testede prosedyrer: Dokumenterte og regelmessig øvde prosesser for gjenoppretting.

Disse to måleverdiene er avgjørende for enhver DR-plan:

• Recovery Time Objective (RTO): Dette er den maksimalt akseptable tiden et datasystem, en applikasjon eller et nettverk kan være utilgjengelig etter en katastrofe. Det handler om tid til gjenoppretting.
• Recovery Point Objective (RPO): Dette er den maksimalt akseptable mengden datatap, målt i tid. En RPO på én time betyr for eksempel at du kan miste opptil én times data. Det handler om hvor mye datatap du tåler.

RTO og RPO bestemmer hvor ofte du må ta sikkerhetskopier, og hvilken strategi du bør bruke for gjenoppretting.

I replikerte miljøer kombinerer du vanligvis to typer sikkerhetskopier:

• Base-backup: Et fullstendig øyeblikksbilde av databaseklyngen på et bestemt tidspunkt. Dette danner grunnlaget for all gjenoppretting.
• WAL-arkivering: Kontinuerlig lagring av Write-Ahead Log-filene (WAL). Disse loggene registrerer alle endringer i databasen og er nødvendige for gjenoppretting til et bestemt tidspunkt og for å holde standby-servere oppdatert.

Sammen gjør de det mulig å gjenopprette til et hvilket som helst tidspunkt i den arkiverte historikken.

pg_basebackup er standardverktøyet for å opprette en base-backup. Det kan til og med ta sikkerhetskopien fra en standby-server som er i drift, slik at primærserveren avlastes!

Denne kommandoen oppretter en fullstendig kopi av datakatalogen. Alternativene -X stream eller -X fetch brukes ofte for å inkludere WAL-filer, slik at sikkerhetskopien blir komplett i seg selv.

Prøv dette eksempelet:

WAL-arkivering er avgjørende for gjenoppretting til et bestemt tidspunkt og for å sikre at standby-serverne kan ta igjen etterslepet hvis primærserveren krasjer. Det innebærer å kopiere ferdigskrevne WAL-filer til et sikkert, ofte eksternt, sted.

Du konfigurerer dette i filen postgresql.conf:

Hvis primærserveren får et alvorlig havari, må du gjenopprette den. Dette innebærer vanligvis:

1. Initialisere en ny datakatalog.
2. Gjenopprette den nyeste base-backupen til den nye katalogen.
3. Konfigurere en recovery.signal-fil (eller standby.signal i eldre versjoner) og postgresql.conf slik at de peker til WAL-arkivet.
4. Starte PostgreSQL. Deretter spiller PostgreSQL av WAL-filene for å bringe databasen til ønsket tidspunkt.

Denne prosessen kan også brukes til å opprette en ny primærserver fra en standby-backup.

Etter en katastrofe kan det også hende at du må bygge opp standby-serverne på nytt slik at de kobler seg til den nylig gjenopprettede (eller promoterte) primærserveren. Prosessen ligner på å konfigurere en ny standby:

1. Ta en ny base-backup fra den nye primærserveren.
2. Konfigurer standby-serverens postgresql.conf og standby.signal slik at de kobler seg til den nye primærserveren.
3. Start standby-serveren. Den vil deretter strømme WAL fra den nye primærserveren for å synkronisere.

Dette sikrer at replikeringskjeden fungerer som den skal igjen.

En DR-plan er bare så god som den siste testen. Det er avgjørende å øve regelmessig på gjenopprettingsprosedyrene. Dette hjelper deg med å:

• Finne mangler eller feil i dokumentasjonen.
• Sikre at gjenopprettingstiden (RTO) er oppnåelig.
• Lære opp teamet i gjenopprettingsprosessen.
• Bekrefte at sikkerhetskopiene er gyldige og kan gjenopprettes.

Planlegg regelmessige DR-øvelser, for eksempel årlig eller halvårlig, i et miljø som ikke er i produksjon.

Vi har gått gjennom det viktigste om katastrofegjenoppretting for PostgreSQL i replikerte miljøer. Husk disse hovedpunktene:

• DR beskytter mot katastrofale feil og kompletterer høy tilgjengelighet.
• Definer RTO (tid til gjenoppretting) og RPO (hvor mye datatap systemene tåler).
• Kombiner base-backuper og WAL-arkivering for omfattende gjenoppretting.
• pg_basebackup og archive_command er viktige verktøy.
• Test alltid DR-planen regelmessig for å sikre at du er klar.

En godt innøvd DR-plan er sikkerhetsnettet ditt for kritiske data.