---
title: "pgBackRest"
description: "Use pgBackRest for MainSDK backups of self-hosted Postgres - WAL archiving, point-in-time restore, RPO and RTO checks and restore drills. Planned."
section: "integrations"
canonical: "https://mainsdk.dev/docs/integrations/pgbackrest"
updated: "2026-10-28"
---

# pgBackRest

> Use pgBackRest for MainSDK backups of self-hosted Postgres - WAL archiving, point-in-time restore, RPO and RTO checks and restore drills. Planned.

Canonical: https://mainsdk.dev/docs/integrations/pgbackrest · Updated: 2026-10-28

pgBackRest is an open-source backup and restore tool for Postgres you run yourself, and a planned driver behind [`backup`](https://mainsdk.dev/docs/interfaces/backup). It takes full, differential and incremental backups and archives the write-ahead log, which gives point-in-time restore. Pick it when you run [Postgres](https://mainsdk.dev/docs/integrations/postgres) on your own servers rather than a managed service.

> **Note:** pgBackRest is a planned driver, not in the spec yet. The backup-restore-evidence spec reads Neon, Supabase, AWS Backup and object lock; everything about pgBackRest on this page is provisional.

## Interfaces it serves

### Backups and restore drills (`backup`)

- Status: Building for 1.2 · ships as a beta API
- Driver: `pgbackrest` (pgBackRest, planned driver)
- Docs: https://mainsdk.dev/docs/interfaces/backup.md

```yaml
backup:
  driver: pgbackrest
```

Swap to another provider: `local`, `neon-pitr`, `supabase-pitr`, `aws-backup`, `object-lock`.

## Before you start

1. Install pgBackRest on your database hosts and configure a repository, on a backup server or in object storage, in the same region as the data.
2. Turn on WAL archiving to the repository, schedule full and incremental backups, and set retention.
3. Turn on repository encryption, and keep a second repository off-site if your policy calls for it.

## Configure

```yaml title="main.yaml"
backup:
  rpo: 15m
  rto: 1h
  keep: 35d
  drill: { every: 30d, to: scratch }
```

How you select pgBackRest as the backup driver, and how MainSDK reaches its repository, are not specified yet [TBD].

## Use it

```ts title="scripts/drill.ts"
import { runDrill } from "mainsdk/backup";

const result = await runDrill({ driver, declared, app: "my-app", at: new Date(), to: "scratch" });   // restores into scratch, never production
```

## Local development and testing

The drill is your test: run `npx mainsdk drill restore --to scratch` on a schedule in CI once the driver exists.

## What MainSDK adds on top

- A check that your backup and retention settings can meet your RPO and RTO.
- Timed restore drills into scratch, signed as evidence. MainSDK never runs or stores backups itself.

See [Backups and restore drills](https://mainsdk.dev/docs/interfaces/backup).

## Limits and notes

- Planned driver, not in the spec yet; the backup-restore-evidence spec itself is phase 3, milestone 1.2.
- Keep each region's repository in that region: US, EU or India.

## Swap to or from it

```yaml title="main.yaml"
db:
  driver: neon   # was self-hosted postgres; point-in-time recovery comes from Neon
```

> **Warning:** Backups don't move between providers. Keep your pgBackRest repository for its retention period and run a drill on the new provider before you rely on it.

## FAQ

**Can I use pgBackRest today?** You can run it on your own Postgres, but MainSDK does not read its settings or drill it until the driver lands.

## Next

- [Backups and restore drills](https://mainsdk.dev/docs/interfaces/backup)
- [Postgres](https://mainsdk.dev/docs/integrations/postgres), [AWS Backup](https://mainsdk.dev/docs/integrations/aws-backup) and [Neon](https://mainsdk.dev/docs/integrations/neon)