Tag backup af og gendan managed PostgreSQL — til din egen S3

Et højt tilgængeligt Postgres-cluster overlever at en member-VM crasher: Patroni forfremmer en sund replika, og dit :5432-endpoint følger med. Men replikering er ikke en backup. Hver replika kopierer trofast alt hvad primæren gør — inklusive et DROP TABLE eller en dårlig migration. Når fejlen er en time gammel, vil du ikke have en trofast kopi af den; du vil tilbage til lige før den skete.

Det er hvad den nye Backups-fane på et managed Postgres-cluster er til. Suble kører pgBackRest mod din egen S3-bucket: planlagte fulde backups plus kontinuerlig arkivering af write-ahead-loggen (WAL), så du kan gendanne dit cluster til ethvert sekund i dit opbevaringsvindue. Her er hvordan det virker og hvordan du bruger det.

Brug din egen S3-bucket

Backups går til storage du selv ejer og styrer — enhver S3-kompatibel udbyder virker: AWS S3, Cloudflare R2, Backblaze B2, MinIO eller et andet object store. Dine backups ligger på din konto, under dine livscyklus-regler, prissat af din udbyder. Suble beholder aldrig en ekstra kopi.

I Console → Clusters → dit DB-cluster → Backups peger du Suble mod bucketen:

S3 endpoint:   https://<accountid>.r2.cloudflarestorage.com
Region:        auto            (standard — de fleste S3-stores accepterer det)
Bucket:        my-suble-backups
Path:          /               (standard — et præfiks inde i bucketen)
Access key:    <din access key id>
Secret key:    <din secret access key>

Region er som standard auto og path /, hvilket er hvad de fleste S3-kompatible udbydere vil have — typisk udfylder du kun endpoint, bucket og nøgler. Før noget gemmes, verificerer Suble dine credentials live: der laves et rigtigt skriv-og-slet test-objekt mod bucketen, og konfigurationen afvises hvis det fejler, så en tastefejl i en nøgle dukker op med det samme i stedet for klokken 3 om natten når den første backup ikke kan uploade. Der er en Test forbindelse-knap der kører samme tjek på forespørgsel.

Hvad en backup faktisk er her

To ting arbejder sammen om at give dig point-in-time-gendannelse:

• Planlagte fulde backups — en daglig eller ugentlig fuld kopi af databasen, taget af pgBackRest og uploadet til din bucket. Du vælger kadencen og hvor mange fulde backups der beholdes (retention).
• Kontinuerlig WAL-arkivering — mellem fulde backups streamer Postgres sin write-ahead-log til samme bucket. WAL er den løbende log over hver ændring, så en fuld backup plus WAL efter den lader Suble spole databasen fremad til ethvert præcist sekund.

Når du aktiverer backups, gør Suble den forsigtige del for dig: den initialiserer pgBackRest-stanzaen og beviser først at den kan nå din bucket, tænder så archive_mode med en rullende genstart — replikaer først, så primæren genstartet på stedet til sidst (en kort pause i skrivninger på få sekunder, ingen failover, endpointet uændret) — og tager derefter den første fulde backup. Kan bucketen ikke nås, rulles ændringen tilbage og du alarmeres — WAL får aldrig lov at hobe sig op på memberens lokale disk indtil den er fuld.

Gendannelse — altid ind i et nyt cluster

En gendannelse på Suble er ikke-destruktiv. Den overskriver aldrig dit kørende cluster — den provisionerer et helt nyt cluster gendannet til det øjeblik du vælger, så du kan inspicere det, sammenligne og skifte over på dine egne præmisser. Originalen betjener trafik hele tiden. Der er to måder at vælge øjeblikket på:

• Point in time — angiv et tidsstempel. Suble gendanner den nyeste fulde backup taget før det og spoler WAL fremad til det præcise sekund. Det er den du vil have efter en dårlig deploy eller en utilsigtet sletning: gendan til 14:59, et minut før fejlen.
• En specifik backup — vælg en af dine fulde backups ved navn og gendan den præcist, uden WAL-genafspilning ud over den. Praktisk når du vil have et kendt-godt checkpoint frem for et præcist tidspunkt.

Backups-fane -> Gendan
  Tilstand:     Point in time
  Mål:          2026-07-19 14:59:00
  Nyt cluster:  prod-db-recovered

# Suble provisionerer et friskt HA-cluster, gendanner den nyeste
# fulde backup før målet, spoler WAL til 14:59:00 og bringer den
# op med automatisk failover — et normalt cluster du kan forespørge.
# Din live 'prod-db' røres aldrig.

Under motorhjelmen kommer det gendannede cluster op som en frisk Postgres-primær på en ny timeline, hvorefter dens replikaer tilslutter sig og streamer fra den — samme shared-nothing, Patroni-styrede HA som ethvert andet cluster. Det er isoleret fra kildens backup-repository, så en gendannet klon kan aldrig skrive ind i den bucket den blev født fra.

Backups på forespørgsel, og at slette gamle

Du kan udløse en fuld backup når som helst — før en risikabel migration for eksempel — uden at vente på planen. Og når du sletter en backup fra dashboardet, udløber Suble den også fra din S3-bucket, ikke kun fra sin egen liste, så din storage-regning afspejler hvad du faktisk beholder.

Går noget galt — en planlagt eller on-demand backup fejler, den første opsætning kan ikke nå repositoriet, eller en gendannelse fejler undervejs — bliver projektejeren notificeret i appen og over de email/webhook-alarmkanaler du har konfigureret. Tavs backup-fejl er den klassiske måde at opdage, midt i en rigtig hændelse, at man slet ingen backups havde; det lukker det hul.

HA og backups er forskellige opgaver

Det er værd at sige rent ud, for det er den fejl der gør mest ondt: replikering er ikke en backup, og en backup er ikke replikering. Høj tilgængelighed beskytter dig mod at en node dør lige nu — databasen bliver online gennem hardware- og procesfejl. Backups beskytter dig mod en ændring du ønsker du kunne fortryde — en droppet tabel, en dårlig migration, en bug der korrumperede data for en time siden. Du vil have begge dele, og på Suble får du begge fra samme cluster-side.

Managed HA Postgres med point-in-time-backups til din egen S3 er live nu. Opret et database-cluster, åbn Backups-fanen og peg den mod en bucket — så har du gendannelige backups uden for dit cluster på et par minutter. Se dokumentationen for managed PostgreSQL for den fulde reference.