storages key on a job is an array — the job uploads every archive to all configured storages. Use defaultStorage on the job to mark which storage the UI surfaces first.
Supported types
Shared fields
Every storage entry, regardless of type, supports these fields:snapr.yaml
On-disk layout
snapr writes every snapshot under a per-job subdirectory inside the storage’spath:
Prefix, the others list one directory — instead of scanning the whole path and filtering by name. Sharing one storage across many jobs stays cheap.
Split snapshots get an extra wrapper directory; see Splitter.
Skipping the per-job subdirectory
SetincludeJobName: false on a storage to drop the <job-name>/ level and write snapshots directly under path:
snapr.yaml
includeJobName defaults to true, so existing configs keep the per-job subdirectory. Every backend supports it.
Retention
Retention is configured on the job (retention.last), not on the storage, but snapr applies it independently on each storage after every run:
- snapr lists the backup sets for the job on that storage.
- Sets are sorted by last-modified time, newest first.
- The newest
retention.lastsets are kept; everything older is deleted.
retention option itself.
Listing cache
The backups list returned to the UI is cached per(job, storage) pair for 5 minutes. snapr invalidates the cache immediately after every upload, delete, and retention sweep, so its own changes show up right away. Files placed or removed manually (outside snapr) appear up to 5 minutes later.
Storage types
Local
Write archives to a directory on the host or a mounted volume.
S3
AWS S3 or any S3-compatible service such as MinIO, Wasabi, or R2.
SFTP
Upload over SSH with password or private-key authentication.
WebDAV
Nextcloud, OwnCloud, or any generic WebDAV endpoint.
bunny.net
bunny.net Storage Zone with optional signed Pull Zone downloads.