---
title: PostgreSQL Recovery Backups
url: "/docs/backups/managed-database/"
canonical_url: https://docs.blossom88.com/docs/backups/managed-database/
markdown_url: https://docs.blossom88.com/docs/backups/managed-database.md
summary: Configure encrypted PostgreSQL recovery backups and restore into a new Database
categories:
- databases
- backups
- disaster-recovery
---

# PostgreSQL Recovery Backups

PostgreSQL Databases can store encrypted pgBackRest recovery backups in
Amazon S3, Cloudflare R2, DigitalOcean Spaces, or other S3-compatible storage.
The backup remains available if the source Database is deleted.

## Backup Storage

Blossom-managed Backup Storage is selected by default. You can choose your own
destination or turn backups off. Without Backup Storage, the Database
is usable immediately, but backups, standby, switchover, and automatic failover
are unavailable. New PostgreSQL databases start their initial backup during
provisioning. An existing Database can select Backup Storage later. Blossom
then runs recovery backups daily, encrypts the
repository, and keeps a 14-day recovery window by default.

Choose **Managed by Blossom** to use Blossom's storage. Under the Database
instance's **Backup → Edit settings**, choose storage and adjust the recovery
window (minimum seven days).

To use your own bucket, add a destination under **Integrations → Backup Storage**
or through the CLI. This list shows only your own destinations and links to
the resources using them:

    blossom backup_storage:create --data backup-storage.yml

backup-storage.yml:

```yaml
backup_storage:
  name: production
  cloud_storage_provider_id: cloud_storage_provider-100
  bucket: database-backups
  folder: managed-data
  # Optional. Leave blank to use Blossom's managed default.
  retention: 30
```

Blossom manages backup timing, repository encryption, verification, and
retries. Each Database can override its storage destination’s default retention.

Blossom encrypts the backup repository and does not show storage credentials,
database credentials, or repository encryption keys in API responses or
Activity logs.

You can turn on the standby as soon as Backup Storage is selected. Blossom
reuses a current backup, waits for one already running, or starts one and
continues standby creation automatically. A current completed backup remains
required before a planned switchover. A standby improves availability but does
not replace backup storage.

## Create A Backup

    blossom backup:create --data '{"backup":{"database_instance_id":"database_instance-100"}}' --follow

The backup runs while PostgreSQL remains available. `backup:show` reports its
status, source, format, size, storage location, and pgBackRest backup label.

## Restore A Backup

Restore always creates a new Database instance. It does not overwrite the source
database.

In the dashboard, open a completed backup and choose **Restore**. On the
Restore page, choose **Shared** or **Dedicated**, review the destination name,
Location and size, then select
**Restore to new instance**. Opening the page does not start a restore.

restore.yml:

```yaml
restore:
  name: restored-postgres
  location_id: location-100
  availability: shared
  size: medium
  backup_storage_id: backup_storage-100
  port: 5433
  # Optional point-in-time recovery target with an explicit time zone.
  target_time: 2026-07-17T14:30:00.123456Z
```

    blossom backup:restore --id backup-100 --data restore.yml --follow

Shared uses your Data Capacity; Dedicated runs on its own Server. Each restored
instance gets its own storage and endpoint. Shared is the default where the
Location supports it. Restore keeps the source's storage size and uses the same
capacity limits as creating an instance.

The restore defaults to the source Backup's Backup Storage; set
`backup_storage_id` to use another named destination. Choose the Account
region and an unused port. Blossom shows the price, creates a new Database,
restores the backup, verifies PostgreSQL readiness, and gives the Database its
own private endpoint.

When `target_time` is present, Blossom restores the selected physical backup
and replays archived PostgreSQL WAL through that time. The target must be at or
after the selected backup completed. If required WAL is unavailable, the
restore fails visibly rather than returning a database at a different point.
Leave `target_time` out to restore the selected backup normally.

## Download a PostgreSQL Database

Create a logical export of one Database, then download the completed Backup:

    blossom backup:create --data '{"backup":{"database_id":"database-100"}}' --follow
    blossom backup:download --id BACKUP_ID --output ./production.dump

The downloaded file is a standard PostgreSQL archive containing schema and data.
Blossom verifies and decrypts it locally; you can use it without Blossom later.
Existing files are never overwritten. Keep the file private and retain database
roles and grants separately, since exports omit ownership and privileges.

Check the archive without connecting to a database:

    pg_restore --list ./production.dump
    pg_restore --file=/dev/null ./production.dump

Use a compatible PostgreSQL client. Download applies to logical exports, not
whole-instance recovery backups. See [backup:download](/docs/reference/cli/backup/download/) for details.

## Current Scope

- PostgreSQL 18 full recovery backups
- MySQL 9 and MariaDB 12 encrypted logical recovery backups, restored to the
  backup's own consistency point
- MongoDB 8 encrypted archive recovery backups, restored to the backup's own
  point
- encrypted S3-compatible storage
- daily backups with configurable retention
- restore into a new Database
- point-in-time recovery through archived WAL, for PostgreSQL
- backup records that survive source database deletion
- PostgreSQL logical exports and verified local downloads

Downloads currently support PostgreSQL logical exports only.

## Related Documentation

- [Databases](/docs/databases/)
- [Backups Overview](/docs/backups/)