0.79.1
Guides

Storage and backup targets

Settings → Storage is the cluster-wide storage policy: where backups ship, what host paths applications may bind, and how long things are kept. Per-node pools are configured elsewhere, on Nodes → Storage.

Status: S3 targets and NAS connections are shipped and verified here against a live cluster. Storage locations are shipped; that section is still being written.

The page has five tabs.

Settings, Storage, on the Backup Targets tab with no targets yet.
Backup Targets are destinations backups ship to. Backups always archive locally first and ship within a minute.

Tab What it holds
Bind Mounts Named host paths containers mount directly. Not included in backups
Backup Targets Destinations backups ship to
NAS Connections SMB and NFS shares ProxDock mounts on every node
Unassigned Datasets Datasets left behind by deletes and migrations
Retention How long each kind of leftover is kept

Adding an S3 target

+ Backup target asks what kind of destination first.

The destination kind picker, offering S3-compatible object storage or a NAS share subfolder.
A NAS share subfolder needs a NAS connection first, which is the tab beside this one.

S3 covers anything that speaks the S3 API. The provider dropdown carries the handful ProxDock knows the quirks of, plus a generic option.

Provider
aws Amazon S3
r2 Cloudflare R2
gcs Google Cloud Storage
minio MinIO / self-hosted
generic Other S3-compatible

The S3 target form, filled in for a self-hosted MinIO, with path-style addressing, plain HTTP and encryption all enabled.
The Endpoint wants a host and port, not a URL. Keep per app is retention at this destination, independent of local retention: 0 keeps everything.

A few fields worth understanding:

  • Bucket must already exist. ProxDock never creates buckets.
  • Prefix scopes every key, so one bucket can hold more than one cluster. Objects land at <prefix>/<cluster>/<app>/<file>.
  • Path-style addressing suits MinIO and most self-hosted gateways. Hosted providers generally want it off.
  • Allow plain HTTP exists for a trusted LAN. A self-signed certificate is rejected outright, so the alternative is installing that CA on every node.
  • Encrypt artifacts seals what leaves the host. See Backups and restore for the format and the recovery phrase.

Test before you save

Test connection does not just open a socket. It lists the bucket, writes an object, reads it back and deletes it, and times each step.

The connection test reporting connected, with list, write, read and delete each succeeding and timed.
A target that passes this can actually be shipped to. Credentials that can write but not delete will fail here rather than at 3am.

The saved target listed, showing its provider, bucket and prefix, and an encrypted marker.
Saved targets show what they are and whether artifacts are encrypted. Recovery phrase reveals the key for encrypted targets; keep it somewhere that is not the cluster.

NAS connections

A NAS connection is a share ProxDock mounts on the nodes you choose. It is defined once, cluster-wide, and each node mounts it at the same path, so an application that moves between nodes finds its files where it left them.

Adding a NAS connection: SMB or NFS.
SMB authenticates with an account. NFS is granted by the server's export list, so there is nothing to authenticate with here.

An SMB connection filled in: name, server, share, username, password, uid and gid, and which nodes mount it.
uid / gid decide who the mounted files belong to. Match what your containers run as, or they will not be able to write.

Credentials are stored in the replicated cluster store and reach each node as a root-only credentials file, never on a command line.

Test connection mounts it for real before you commit to it.

Testing an SMB connection before saving.
The connection cannot be created until this passes, which is why the save button appears only afterwards.

The saved NAS connection.
Mounts are on access: a connection showing as not mounted has simply not been touched yet, and the first read triggers it.

Mounted at /mnt/proxdock/<name> on every node that has it selected.

Using one as a backup target

Once a connection exists, a backup target can point at a subfolder of it.

A NAS backup target, naming a connection and a subfolder inside it.
The connection supplies the server, share and credentials; the target only picks the subfolder and its retention.

A NAS target is a filesystem path rather than an object store, so shipping is a copy rather than an upload, and the same per-destination retention applies.

Sending a backup to it

A destination can be pinned on a single manual backup, or set as the application's policy so every backup goes there.

The manual backup dialog with a destination chosen.
Choosing here pins the destination on that backup, so a copy taken to one place is never confused with one taken to another.

Scheduled backups use the application's job instead.

The backup schedule editor.
A job is per application: a schedule, a destination and its own retention.

Backups archive locally first and the shipper picks them up within a minute, so a slow upload never holds up the snapshot or the application.

Where to go next