Overview

A source is what a job backs up. Each job defines a sources array, and one job can combine multiple sources — for example an application database plus its upload directory — into a single archive.

snapr.yaml

jobs:
  - name: app
    sources:
      - type: postgresql
        host: db.internal
        port: 5432
        username: backup
        password: env:PG_PASSWORD
        database: app
      - type: local
        path: /var/data/uploads

Shared fields

Every source entry must set type. The remaining fields depend on the type, but a few conventions apply across all of them:

Field	Applies to	Description
`type`	all	One of `local`, `sqlite`, `postgresql`, `mysql`, `mariadb`, `mongodb`, `redis`, `s3`, `bunny`. Required.
`extraParams`	CLI-backed and object-store sources	A `key: value` map. For database sources, each key becomes a `--key=value` flag on the dump command; an empty string value produces a bare `--key` flag. For `s3` and `bunny`, it tunes snapr itself (for example `workers`).
`excludes`	`local`, `s3`, `bunny`	Glob patterns for files to skip.
`env:` prefix	any secret value	`password: env:PG_PASSWORD` reads the value from the environment instead of the config file.

Required external tools

Most database sources shell out to the vendor’s own dump utility. snapr does not bundle these tools — they must be on PATH (or inside the snapr Docker image you build or extend).

Source	Required binary	Typical package (Debian/Ubuntu)
`postgresql`	`pg_dump`	`postgresql-client-<version>`
`mysql`	`mysqldump`	`mysql-client` or `default-mysql-client`
`mariadb`	`mariadb-dump` (falls back to `mysqldump`)	`mariadb-client`
`mongodb`	`mongodump`	`mongodb-database-tools` (separate package from MongoDB itself)
`redis`	`redis-cli`	`redis-tools`
`sqlite`	`sqlite3`	`sqlite3`
`local`	none	—
`s3`	none (uses the AWS SDK)	—
`bunny`	none (uses the HTTP API)	—

If encryption is enabled, openssl must also be on PATH.

Match the major version of pg_dump / mysqldump to the server version, otherwise the dump may fail or omit data. The official Docker image ships matching client tooling — when running outside Docker, install the client package that pairs with your server.

How remote sources are fetched

Database, S3, and bunny.net sources are pulled to the snapr host first, then archived and uploaded to the configured storages. snapr does not stream data directly from the source to the storage backend. This has practical implications:

The host needs free disk space at least equal to the uncompressed source size, plus headroom for the resulting archive.
The first run downloads everything. Object-store sources (s3, bunny) support a persistent local cache via syncPath — later runs only fetch files whose size or modification time changed. Without syncPath, every run re-downloads the full tree.
For very large buckets, factor in egress costs and transfer time.

snapr cleans up the working directory after the job finishes, whether it succeeds or fails. When syncPath is set, the cache directory is preserved between runs.

Source types

Local files

Files and directories on the host filesystem.

PostgreSQL

Logical dumps via pg_dump.

MySQL

Logical dumps via mysqldump.

MariaDB

mariadb-dump with a mysqldump fallback.

MongoDB

Dumps via mongodump, with optional oplog.

Redis

Live RDB snapshots or RDB file copies.

SQLite

SQL dumps of a single database file.

S3

Files from any S3-compatible bucket.

bunny.net

Files from a bunny.net Storage Zone.

Getting started

Configuration

Shared fields

Required external tools

How remote sources are fetched

Source types

Local files

PostgreSQL

MySQL

MariaDB

MongoDB

Redis

SQLite

S3

bunny.net

​Shared fields

​Required external tools

​How remote sources are fetched

​Source types

Local files

PostgreSQL

MySQL

MariaDB

MongoDB

Redis

SQLite

S3

bunny.net

Shared fields

Required external tools

How remote sources are fetched

Source types