A repository that reads as slow while the storage behind it looks idle is usually a routing problem rather than a storage problem. Object traffic in a Veeam deployment does not always take the path the diagram suggests. It is marshalled by a gateway, and where that gateway sits decides which links the data crosses, which interfaces it saturates, and in many designs what the achievable throughput actually is.
The gateway is easy to overlook because it is not usually a dedicated machine. It is a role assigned to a server that already exists, often chosen during setup by accepting whatever was offered, and then never revisited. Nothing in the console draws attention to it afterward.
That matters because the gateway is the only point where all object traffic for a repository is concentrated. Everything else in the data path can be scaled out. A single gateway is one set of interfaces, one CPU budget and one position in the network, and a poor choice on any of the three shows up as a storage complaint.
When traffic goes direct and when a gateway handles it
Veeam can send object traffic either through a designated gateway server or directly from the component doing the work. Which of the two applies depends on the repository configuration and on the type of job, and the behavior has changed across versions, so the setting in the deployment at hand is worth reading rather than assuming.
The distinction has a practical consequence. Where traffic goes direct, the path is drawn from each proxy or agent to the storage, and the number of network paths in play equals the number of components. Where a gateway is used, every one of those flows converges on one server first. The first arrangement scales with the component count. The second scales with whatever that one server can carry.
Neither is automatically better. A gateway is useful when the storage should not be reachable from every proxy, when a firewall rule set is simpler with one source address, or when certificate and credential handling should sit in one place. Direct paths are useful when throughput is the priority and the network permits it. The choice is a design decision, and it is most often made by default instead.
What the gateway role consumes
A gateway server terminates the object protocol, assembles and sends the objects, and handles the transport security for that traffic. The work is not heavy per byte compared with what a proxy does, but it is continuous and it scales with the number of concurrent tasks pointed at the repository. CPU, memory and network interface all get used, and interface capacity is usually the first to run out.
Memory deserves attention because object uploads are buffered. Each concurrent task holds working memory, so a gateway comfortable with a handful of tasks can start failing when the same host is asked to carry many. When a gateway role is placed on a server that also runs the backup console or a proxy, those demands are added to whatever that server was already doing, and the contention is not reported as a gateway problem.
Because the ceiling moves with concurrency, gateway capacity and task slot counts are the same question asked from two directions. Raising concurrency settings without knowing what the gateway can absorb tends to convert a throughput limit into a set of retries.
Why the wrong side of a boundary costs throughput
Backup object storage is frequently placed behind a boundary on purpose, in its own segment, reachable only through specific rules. That is sound design. It also means the position of the gateway relative to that boundary determines whether traffic crosses it once, twice or not at all.
A gateway placed on the production side of the boundary pulls every byte through the firewall or inspection device on its way to the storage. A gateway placed on the storage side moves that crossing to a single controlled hop and leaves the bulk transfer on the storage network. The difference is often large, because inspection devices are sized for user traffic rather than for a backup window, and they are not usually instrumented in a way that makes the saturation obvious. Where the segment exists for isolation reasons, the placement decision has to respect what the network segmentation was built to achieve, since moving a gateway across a boundary can undo it.
| Observation | Likely cause | What to check |
|---|---|---|
| Throughput flat well below the link rate | A single gateway interface is saturated | Interface utilization on the gateway during the job, not on the storage |
| Storage nodes show low utilization while jobs run | Traffic is constrained before it reaches the storage | Every device in the path from gateway to storage subnet |
| Throughput falls when a second job starts | CPU or memory contention on the gateway host | Concurrent task count and what else runs on that server |
| Backup acceptable, restore slow, same repository | A different component handled the restore path | Which server performed the restore and which interface it used |
| Traffic crossing a site or segment boundary unexpectedly | Gateway placed on the wrong side of that boundary | Gateway host location relative to the storage subnet and the routing between them |
| Timeouts and retries under load, no errors on the storage | An inspection or proxy device in the path | Devices terminating or inspecting object traffic on that route |
Reading a slow repository when the storage is idle
The diagnostic order is short. Start at the interface counters on the gateway host during a busy job. If one interface is running at line rate, the answer is found and the question becomes how to add paths. If not, move to CPU and memory on the same host, then to the concurrent task count, then to the devices between the gateway and the storage subnet.
The storage side is checked last on purpose, because it is the most common first guess and the least common cause. Object storage absorbs writes across many nodes, and the aggregate it can take is usually well above what one gateway can send. Node level utilization figures that stay low while the repository is reported as the bottleneck are a strong indication that the limit is somewhere in the path.
Restore is worth measuring separately rather than inferring from backup performance. The component that reads during a restore is not always the one that wrote, and a path that is adequate in one direction can be constrained in the other. Reading gateway metrics alongside repository counters in whatever monitoring the operations team already watches makes both directions visible without a separate investigation.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, presenting an S3 compatible API and supporting immutable backup storage through S3 Object Lock. To Veeam it is an S3 object repository, so the gateway questions are the standard ones: whether a gateway is designated, where that server sits, and how many of them serve the repository.
Since ARTESCA runs on infrastructure the customer operates, its network position is a local decision rather than a fixed property. The subnet it sits in, the boundary in front of it and the interfaces available to it are all chosen during deployment, which means the gateway placement can be designed alongside them instead of inherited. Teams evaluating direct to object configurations against a gateway design have the same latitude, since both ends of the path are theirs.
What to document and when to recheck it
A short record of the data path is worth more than it costs to write. Which server holds the gateway role for each repository, which interface and subnet it uses, what sits between it and the storage, and whether any job is configured to send traffic directly. One page, dated, kept where the backup runbooks live. Most gateway problems are discovered during an incident, and the record turns a diagnosis into a lookup.
Rechecking belongs on the same schedule as other infrastructure review, and unavoidably after any change to the network, the virtualization hosts or the backup components themselves. A gateway role can move when a server is rebuilt, and a path that was deliberate a year ago can become accidental without any change to the backup configuration. Comparing observed throughput against the figures recorded at deployment is usually enough to show whether anything has drifted.