> ## Documentation Index
> Fetch the complete documentation index at: https://www.towbar.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Database backups

> Protect managed databases with workspace object-storage providers.

Towbar backs up all eight managed database engines. Use AWS S3, generic S3, Cloudflare R2, Google Cloud Storage, or Azure Blob Storage. The manifest stores the runtime provider name, location policy, retention, and schedule; provider credentials remain in the API environment.

## Prerequisites

Enable the storage provider in `.env`, restart the API, and confirm it appears under **Manage → Integrations → Backup providers**. Grant the runtime identity access to the buckets, containers, prefixes, and encryption keys used by workload policies.

* [AWS](/docs/integrations/aws), generic S3, or R2 for S3-compatible storage.
* [Google Cloud](/docs/integrations/gcp) for Google Cloud Storage.
* [Azure](/docs/integrations/azure) for Azure Blob Storage.

Deploy a healthy database resource, choose storage buckets or containers, and keep permissions scoped to the declared paths. Backup schedules remain paused if a declared destination lacks credentials (indicated by a warning indicator in the secondary sidebar).

## Runtime provider configuration

The compact policy below references the enabled AWS runtime integration by its provider name. Use `s3`, `r2`, `gcs`, or `azureBlob` for the other providers. `restoreFrom` is derived and must not be supplied with this form:

```yaml theme={"system"}
backup:
  integration: aws
  schedule:
    cron: 0 3 * * *
    timezone: UTC
  retention:
    keepLast: 14
```

Database backup execution revalidates that the runtime provider is still enabled before it reads credentials. Disabling or changing the runtime integration therefore stops queued work that can no longer resolve its provider.

## Legacy multi-provider configuration

The original three-provider object remains accepted within the clean-break v2 manifest while teams move to provider configurations. A resource must declare at least one destination:

* **AWS S3 (`s3`)**: Declare `bucket`, optional `prefix` (defaults to `towbar`), optional `region` (defaults to the runtime AWS integration region), and optional `encryption` (`AES256` or `aws:kms`). When using `encryption: aws:kms`, supply `kmsKeyId`.
* **Google Cloud Storage (`gcs`)**: Declare `bucket`, optional `prefix` (defaults to `towbar`), and optional `region`. Encryption uses Google-managed keys or Cloud KMS keys (CMEK) configured on the bucket.
* **Azure Blob Storage (`azureBlob`)**: Declare `container`, `storageAccount`, and optional `prefix` (defaults to `towbar`). Encryption uses Microsoft-managed keys.

### Multi-destination backups

To store backups across multiple clouds simultaneously, declare more than one destination block (`s3`, `gcs`, `azureBlob`). Towbar executes backups to all declared destinations concurrently and verifies restore-readiness on each.

When multiple destinations are declared, specify `restoreFrom` (`s3`, `gcs`, or `azureBlob`) to identify which provider serves as the authoritative source for database restores. If only one destination is declared, `restoreFrom` defaults to that provider automatically.

A retained recovery point keeps its original storage provider and location. Changing the manifest’s `restoreFrom` later affects new backups; it does not redirect an older backup to another cloud. Keep credentials for the retained provider available until those recovery points expire. If retention cannot delete every stored copy, Towbar keeps the recovery point eligible for another cleanup attempt.

## Define a database policy

This complete manifest creates a PostgreSQL resource with daily backups at 03:00 UTC, retains the latest 14 recovery points, and replicates backups to AWS S3 and Google Cloud Storage:

```yaml title="towbar.yml" theme={"system"}
version: 2
environments:
  production:
    previews:
      enabled: true
```

```yaml title=".towbar/resources/database.resource.yml" theme={"system"}
id: database
name: Primary database
type: postgres
server: 192.0.2.10
backup:
  schedule:
    cron: 0 3 * * *
    timezone: UTC
  retention:
    keepLast: 14
  s3:
    bucket: example-production-backups
    prefix: databases
    region: ap-south-1
    encryption: AES256
  gcs:
    bucket: example-gcs-backups
    prefix: databases
    region: asia-south1
  restoreFrom: s3
environments:
  production: {}
```

You can also target Azure Blob Storage individually:

```yaml title="towbar.yml" theme={"system"}
version: 2
environments:
  production:
    previews:
      enabled: true
```

```yaml title=".towbar/resources/cache.resource.yml" theme={"system"}
id: cache
name: Redis cache
type: redis
server: 192.0.2.10
backup:
  schedule:
    cron: 0 4 * * *
    timezone: UTC
  retention:
    keepLast: 7
  azureBlob:
    storageAccount: prodbackups
    container: database-archives
    prefix: redis
environments:
  production: {}
```

Replace the host and storage values, then save `POSTGRES_PASSWORD` in the resource's runtime secrets. Sync the Repository and open **Resource → Settings → Backup**.

Schedules use five-field UTC cron expressions and cannot run more frequently than hourly. Retention accepts 1–100 backups and defaults to 7. Omitting `schedule` leaves backups manual.

## Backup management UI

In the secondary sidebar under **Resource → Settings → Backup**, Towbar provides an operational dashboard for your database backups:

1. **Credentials & health alert**: Displays an immediate warning if a manifest destination is not enabled by the Towbar runtime environment.
2. **Provider destination tabs**: Each configured destination (`AWS S3`, `Cloudflare R2`, generic S3-compatible storage, `Google Cloud Storage`, or `Azure Blob Storage`) appears with its provider identity and exact object location.
3. **Provider configuration card**: Inside each tab, view the destination URI, encryption mode, credentials status, backup schedule, and retention limit. The schedule shows cron notation; hover or focus it for a plain-language description.
4. **Retained backups table**: Positioned directly beneath the configuration card, listing recovery points with creation timestamp, size, engine version, format, and object key.

## Verify a recovery point

Choose **Back up now** to trigger an immediate backup run. Towbar performs a 3-stage verification pipeline:

* **Backup run**: Executes the engine-native export for PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB, or ClickHouse inside the owned container and validates the resulting archive.
* **Saved copy**: Uploads the archive to all configured destinations with SHA-256 checksum metadata.
* **Restore check**: Verifies object existence, size, checksum metadata, encryption, engine compatibility, and format across all destinations.

Freshness and usability answer different questions. An older retained backup can miss the schedule's recovery-point objective while remaining usable for an explicit restore.

<div className="towbar-doc-screenshot">
  <div className="towbar-product-light">
    <img src="https://mintcdn.com/avgeek/7IKQY5hBmeQaVMw0/assets/release-v2/backups-light.jpg?fit=max&auto=format&n=7IKQY5hBmeQaVMw0&q=85&s=37306069e0f600dc5bc642be740ff6e4" alt="Backup configuration shows the location, retention, cron schedule, and provider credential status." width="1280" height="919" loading="lazy" data-path="assets/release-v2/backups-light.jpg" />
  </div>

  <div className="towbar-product-dark">
    <img src="https://mintcdn.com/avgeek/7IKQY5hBmeQaVMw0/assets/release-v2/backups-dark.jpg?fit=max&auto=format&n=7IKQY5hBmeQaVMw0&q=85&s=b7da1fdad03dee15ca99ed4a701b7d90" alt="Backup configuration shows the location, retention, cron schedule, and provider credential status." width="1280" height="919" loading="lazy" data-path="assets/release-v2/backups-dark.jpg" />
  </div>

  <p>
    Backup configuration shows the location, retention, cron schedule, and
    provider credential status.
  </p>
</div>

## Practice recovery

A completed upload is not proof that your application can recover. Follow the [restore guide](/docs/restores) in a controlled environment and verify the restored data with the application.

These features protect managed workload data. Back up Towbar's own PostgreSQL database and `.env` with your infrastructure tooling; the dashboard does not provide control-plane backup or restore operations.

## App and Compose volumes

Towbar lists app and Compose volumes on each app's **Storage** page, but it does not back up or restore their contents. Protect persistent application files with storage or infrastructure tooling appropriate for the server, and test that recovery process independently.