Veeam can write primary backups straight to an object storage repository, with no disk landing zone in front of it. On paper that removes a tier, a cost line and a copy step. In practice it moves the whole backup window onto a path that previously carried only offload traffic, and it changes where every restore reads from. The question is rarely whether it works. It is which environments it suits and which it quietly penalizes.
The case for it is simplicity. One target instead of two, one capacity number, immutability applied to the primary copy rather than a secondary one, and no performance tier to size, monitor and replace on its own cycle. For a small team, removing a tier removes a category of work.
The case against is usually stated as speed, which is too coarse to act on. Object storage is not uniformly slower. It behaves differently, and the difference shows up in specific operations rather than across the board. Knowing which ones separates a deployment that suits direct-to-object from one that gets unpicked six months later.
With a performance tier in front, a backup job writes to local disk and finishes. Everything afterward, offload, synthetic construction, copies to a second location, happens on its own schedule. The job duration reflects only the write to fast local media.
Without it, the job duration includes the write to object storage, over whatever network sits between the two. Every operation the backup software performs during the job now travels that path: not only bulk data, but the metadata operations, the existence checks and the small writes that a local filesystem answers in microseconds. Latency that was irrelevant for offload becomes part of the critical path.
The second change is that there is no local copy to restore from. With a landing zone, recent restore points sit on disk beside the backup server and the fastest restores use them. Without one, every restore, including the one requested twenty minutes after the job finished, reads from object storage across the same network.
Sizing this is not a matter of dividing nightly change by the hours available, though that figure is the floor. Backup traffic is bursty, it runs concurrently across jobs and proxies, and it shares the path with whatever else runs at night: replication, copy jobs, patching, monitoring.
Three properties matter. Sustained throughput between the machines doing the writing and the storage endpoint, measured during the hours the backup runs rather than at midday. Round trip latency on that path, since object operations are request and response and a job performs a great many of them. And the concurrency the endpoint handles comfortably, since Veeam parallelizes across tasks and the aggregate matters more than any single stream.
The failure mode when this is misjudged is not an error. It is a window that creeps, then a window that overruns, then a recovery point objective that is missed without anything turning red. Teams already dealing with a window that no longer finishes overnight should be cautious about moving the primary write onto a longer path before the existing phases are understood.
| Operation | How it behaves without a landing zone | What to measure before committing |
|---|---|---|
| Nightly incremental | Writes travel the full path, including small metadata operations | Sustained throughput and round trip latency during backup hours |
| Synthetic full | Assembled from data the object repository already holds | Duration on a representative job, and the day it is scheduled |
| Single file restore | Reads objects across the network rather than local disk | Time to first byte and total time for a realistic file set |
| Full machine restore | Reads the whole chain from object storage | Restore rate on one large machine, not an average |
| Instant recovery | Runs the machine from object storage, reading data on demand | Boot time and application responsiveness under real load |
| Retention processing | Deletions and merges become object operations at volume | How long housekeeping runs and whether it overlaps the window |
Direct-to-object suits workloads whose recovery expectation is measured in hours rather than minutes, and whose restores are usually partial. File servers, secondary application servers, test and development estates, and archival-leaning data all fit comfortably. They restore rarely, and when they do the business tolerates a read across the network.
It suits physical machines protected by Veeam Agent well, since those often have no local repository nearby and already accept a network path for both backup and restore.
It suits less well the workloads with the tightest recovery expectations: the database that has to be back inside a stated number of minutes, the application with a documented recovery time, the machines a continuity plan names individually. Those justify a performance tier, and folding them into a direct-to-object design because everything else fits is how a recovery commitment quietly becomes unachievable.
The structure of the backup chain matters too. How chains are represented on object storage determines how much reading a restore has to do, and a deep incremental chain costs more to traverse over a network path than over local disk. The chain type chosen for a direct-to-object repository is a recovery decision, not only a capacity one.
The first is that job durations become sensitive to things that never mattered before. A network change, a firewall rule update, an unrelated workload added to the same path at night: any of these moves the backup window in a way a local repository absorbed silently.
The second is that restore behavior needs re-baselining. Recovery expectations were usually set when restores read from local disk. After the change, the slowest step in a restore is often somewhere new, and the honest response is to re-time the restores the business actually cares about rather than assume the previous figures hold.
The third is that capacity behaves differently. No fast tier absorbs recent data and no offload schedule smooths growth, so the repository carries everything from the first night. Where immutability is enabled, locked objects cannot be removed early, so the habit of deleting something to buy a week no longer applies. Planning headroom on the repository matters more here than in a tiered design.
ARTESCA is object storage software used as a backup target, deployed on infrastructure the customer runs. In a direct-to-object design it is the only backup tier, which means the endpoint, the network path to it and its available capacity are on the critical path for both the backup window and every restore.
Because it runs on customer infrastructure rather than at a provider, the network path is local, controlled and measurable, and no per-request or egress charge attaches to the reads a restore performs. That removes one common objection to direct-to-object, though not the need to measure the path.
ARTESCA supports immutability through S3 Object Lock and presents an S3-compatible API, so it is addressed as an object storage repository in the usual way. Capacity runs from roughly 50 TB to several petabytes, and in a direct-to-object design the sizing has to account for the full retention rather than a recent subset.
Two tests answer most of the question. Run one representative job against the object repository for a full week, including whatever synthetic or housekeeping day exists, and record duration and reported bottleneck each night. Then restore from it: one full machine, one set of individual files, and one instant recovery held long enough to show whether the machine is usable rather than merely booted.
Record the results next to the recovery expectations they are meant to satisfy. A restore time is only meaningful beside the number someone committed to, and this is the point at which a workload gets moved back behind a performance tier cheaply, before the design is in production.
Once running, keep two figures under monthly review: the backup window trend and the last measured restore time for the workloads that matter most. Both drift, neither raises an alert, and both are what the decision will eventually be judged on.