Storage destinations
Connect the S3 bucket, FTP/SFTP server or Google Drive that backups are written to, and check the credentials actually work.
A backup has to go somewhere that is not this server, and that somewhere is a storage destination. You connect one once, under Integrations → Storage, and then pick it on each application you protect.
Until there is at least one destination, the Backups screen can only offer to create one.
What you can connect
| Provider | Addressed by | Credentials |
|---|---|---|
| Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, Other | bucket + region (+ endpoint) | access key, secret key |
| FTP | host + port (default 21) | username, password |
| SFTP | host + port (default 22) | username, and either a password or a private key |
| Google Drive | your Google account | OAuth client ID + secret |
The first six entries are all S3 — they differ only in which endpoint and region the form prefills. Pick Other for any other S3-compatible service and fill the endpoint in yourself.
The panel refuses a host that resolves to loopback or to the cloud metadata range. Private LAN addresses are allowed — a NAS on the same network is a normal backup target.
Add a destination
Open Integrations → Storage and click Add destination. The form opens as a dialog and starts on Amazon S3.
Pick the provider. The rest of the form changes with it — each provider asks only for what it needs.
For FTP, that is host, port, username, password, remote directory, and two switches: Use TLS (FTPS) and Passive mode, both on by default. Leave TLS on unless the server genuinely cannot do it; without it the password and the whole backup travel in the clear.
For SFTP, authenticate with a password or a private key — one of the two
is required, not both. Paste the whole key, including the BEGIN/END lines,
and add the passphrase only if the key itself is encrypted.
Name it. The name is what you will see on every application, every history
row and every restore — Offsite SFTP, Hetzner box, S3 — production. It
has to be unique on the server.
Set the folder, if you want one. FTP and SFTP have a Remote directory (where the login lands, by default); S3 and Drive have a Folder prefix. Either way the panel then creates one subfolder per application inside it, so several applications can share a destination without colliding.
Leading ../ is refused — a prefix cannot walk out of the bucket or folder it
names.
Click Add destination. The panel tests the connection as part of saving. A destination that cannot be reached is not stored and you get the error immediately instead of at 2 AM.
Google Drive
Drive is the one provider with setup work outside the panel. The dialog walks you through it in five steps and gives you the exact redirect URI to paste into Google.
Three things in there are easy to get wrong:
- Enable the Google Drive API. Skipping it still lets sign-in succeed, and then every upload fails.
- Publish the consent screen. Left in Testing, Google expires access after about seven days: the backups work all week and fail the next, with nothing in the panel having changed.
- The redirect URI must match exactly. Copy it from the dialog.
A free Google account is enough — no Workspace, no domain. After saving, press Connect on the destination to approve access. The panel creates its own folder in your Drive, so there is no folder ID to find, and it can only see files it created.
Test, edit and remove
Every row has a Test button that opens a real connection and reports how long it took. The row shows the result until the next test.
The … menu has the rest:
- Edit changes the address, folder and name. Credentials you do not retype are kept.
- Replace credentials rotates the password, key or access key. Secrets are stored encrypted and never shown again, so rotating is the only way to change one.
- Delete removes the destination from the panel. It does not delete the archives already sitting on the remote storage — clean those up there.