Storage Destinations
DBackup supports multiple storage backends for your backups.
Supported Destinations
Local & Network
| Destination | Type | Best For |
|---|---|---|
| Local Filesystem | File | Quick setup, on-premise |
| SFTP | Remote | Existing Linux/Unix servers |
| FTP / FTPS | Remote | Legacy infrastructure, shared hosting |
| SMB / Samba | Network | Windows shares, NAS devices |
| WebDAV | Network | Nextcloud, ownCloud, NAS |
| Rsync (SSH) | Remote | Efficient delta transfers |
S3-Compatible
| Destination | Best For |
|---|---|
| Amazon S3 | AWS infrastructure, high durability |
| S3 Compatible | MinIO, DigitalOcean, Backblaze |
| Cloudflare R2 | Zero egress fees |
| Hetzner Object Storage | EU data residency, GDPR |
Cloud Drives
| Destination | Free Tier | Auth |
|---|---|---|
| Google Drive | 15 GB | OAuth 2.0 |
| Dropbox | 2 GB | OAuth 2.0 |
| Microsoft OneDrive | 5 GB | OAuth 2.0 |
Destination or Directory Source
The same storage backends serve two different purposes, and each configured adapter is set to exactly one of them:
| Role | What it does | Path it uses |
|---|---|---|
| Backup Destination | Receives backups | The configured path, with one folder per job written into it (plus a folder per chain for incremental jobs) |
| Directory Source | Provides files to back up | Folders below the configured path, picked per job |
They are mutually exclusive on purpose. A destination owns its path and creates folders there, while a source reads from that same path - and a source set to "Back up everything" reads the path itself. One adapter doing both would mean a job backing up its own previous archives, growing without limit.
Both live on the Connections page, on the Destinations and Directory sources tabs.
Same server for both
Pick Create as directory source in the menu of a destination, or Create as backup destination on a source, to copy it into the opposite role with its login, then adjust the path. Two adapters for one server is intentional: they point at different paths and are monitored separately.
Adding a Destination
- Navigate to Connections → Destinations → New destination
- Select the storage type
- Fill in the parts listed on the left. A check marks each part that has everything it needs.
- Leave Used as on Backup destination in the Behavior part
- Click Test connection, then Create destination
Air-Gapped Destinations
A destination that is connected only now and then, like a USB disk you plug in once a week or a NAS that is only switched on for its backups, can be marked Air-gapped in the Behavior part of its form. This works with every destination type, since DBackup asks it with the same connection check the health check uses. Being away is then how it is meant to be, not a problem.
Several destinations are marked at once: tick them on the Destinations tab of Connections and pick Mark as air-gapped under More.
While it is not connected:
- A run asks it right before its upload and leaves it out when it does not answer. The run stays a Success as long as another destination took the backup. A run that reaches no destination at all fails.
- No A connection is offline or A connection is back notification goes out for it, so its Health alerts switch is off.
- Connections and the Backups page show it as Not connected in gray, with since when, instead of offline in red.
- A backup made meanwhile is no missing copy there. A copy that lies on it shows grayed out with an unplugged icon, and the destinations timeline marks the days it was away in gray.
- The integrity check, the hourly list refresh and retention leave it alone, and an incremental chain carries on without it.
Once it answers again, the next run uploads to it as usual and its copies get their green dot back. An incremental job starts a new full backup if the destination lacks part of the current chain.
Get told when a run left it out
The system notification An air-gapped destination was skipped reports the first run that leaves it out, once each time it goes away. It is off by default, see Notifications.
Removable disks
Point a Local Filesystem destination at a folder on the disk, not at its mount point. An empty mount point answers like a connected disk, and the backups would land on the system disk.
The configuration backup is no run of a job, so a configuration backup to an air-gapped destination that is not connected still fails and reports it.
Storage Structure
Every run writes one .tar with two sidecars into a folder named after the job:
/your-prefix/
└── job-name/
├── job-name_2026-10-08_12-00-00.tar
├── job-name_2026-10-08_12-00-00.tar.index
└── job-name_2026-10-08_12-00-00.tar.meta.jsonThe .tar holds one entry per database and the files of any directory sources, each compressed and encrypted on its own when the job asks for it. The .index is a copy of its table of contents, so browsing a backup never downloads the archive. The .meta.json is cleartext and stores the job, the source and its version, the names of the databases, the checksums and the encryption profile, never a key. Incremental jobs keep each chain in a folder of its own inside the job folder. The layout is described in Archive Format.
Upload Performance (S3)
A backup is one large file, so the only way to use more of a fast link is to send several pieces of it at the same time. Every S3 destination (Amazon S3, Cloudflare R2, Hetzner Object Storage, S3-Compatible) splits an upload into parts and sends 8 parts of 8 MB at once by default.
Both values are adjustable per destination in the Speed part of its form:
| Field | Description | Default | Range |
|---|---|---|---|
| Parts at once | Parts uploaded simultaneously | 8 | 1 to 32 |
| Largest part (MB) | Upper bound on the size of each part | 8 | 5 to 64 |
Parts at once is the speed setting
Each part travels over its own connection, and a single connection to an object store is usually capped somewhere between 5 and 10 MB/s no matter how much bandwidth is available. Total throughput is therefore roughly parts at once x per-connection speed, so raising this is what makes an upload faster.
Raise it when the upload speed in the run log is well below what the server's link can do. Lower it if the provider starts answering with SlowDown or 503.
Measured example
Uploading a 1.39 GB backup to Cloudflare R2 over a 10 Gbit link, where each connection managed about 5.9 MB/s:
| Parts at once | Throughput |
|---|---|
| 4 | 26 MB/s |
| 32 | 187 MB/s |
Max part size is a memory setting
Parts in flight are held in memory, so an upload uses roughly (parts + 1) x part size while it runs. The form shows the figure as you change the values. The default works out to about 72 MB, the maximum to about 2 GB.
You are setting an upper bound, not a fixed size. DBackup picks the largest part size at or below your value that still gives every connection something to upload. The right size depends on how large a backup turns out to be, and that differs from run to run, so it is not something a static setting can track.
Why it matters: with 32 parts at once, a 1.39 GB backup split into 64 MB parts is only 21 parts. Eleven connections would get nothing, and the upload would take as long as its single slowest part. The automatic adjustment prevents that, and the run log reports the size actually used.
Concurrent jobs
If Max Concurrent Jobs is above 1, several uploads can run at once and each one uses its own memory budget. Destinations within a single job upload one after another, so those do not add up.
DBackup also raises the part size above your maximum in one case: when an archive is so large that your value would need more than S3's limit of 10,000 parts. The alternative there is an upload the service rejects.
Retention Policies
Destinations work with retention policies to automatically clean up old backups:
- Simple: Keep last N backups
- Smart (GFS): Grandfather-Father-Son rotation
See Retention Policies for details.
Next Steps
Choose your storage destination: