SMB share and local folder
The on-premises destinations. Both are read and written by an agent on the customer's network, which is the one thing to hold in mind: the Cloud Agent cannot reach them, and the console browses them through an agent.
What you need #
- SMB: server, share name, a username and password, and the domain if it is a domain account.
- Local folder: a path on the machine that runs the agent (
D:\Backups,/mnt/backup, a mapped USB disk).
Add it as a storage target #
- Storage → Add → SMB share or Local folder.
- Enter the details. A local path is always relative to the agent that will use it.
- Test — for these two, Browse via agent asks you which machine to test from.
Test on the target's row proves the credentials; a target that fails shows the provider's own message until it is fixed. From then on it can be a job's destination, a cloud-to-cloud source, a cloud drive, or an archive.
What it supports #
| Capability | SMB share and local folder |
|---|---|
| Streams uploads | No |
| Version history | Sidecar (local: by copy on the machine; SMB: copy over the share) |
| Realtime cloud-copy source | A local folder can be watched continuously by its agent |
| Cloud-drive mount | Yes (a share as a drive on another machine) |
| Reachable from the Cloud Agent | No — the wizard says so |
| Browse in the console | Through an agent you choose |
Things to know #
The agent's identity. On Windows the agent runs as SYSTEM, which cannot use the logged-in user's mapped drives or credentials: give the SMB target its own username and password rather than relying on a mapped letter. A local folder must be readable and writable by SYSTEM.
A USB disk that comes and goes is a fine destination for a Manual job and a poor one for a schedule — the run fails cleanly when the disk is absent and reports it.
3-2-1. A local or SMB copy is fast to restore from; pair it with a job to object storage for the copy that survives the building.