10 Most storage evaluations for Veeam are run backwards. Teams size for how fast data goes in, then discover during an incident that what mattered was how fast it comes out, and whether the copy was still there. The best storage for Veeam is not the target with the highest ingest rate or the lowest price per terabyte. It is the target that still holds a restorable copy after an attacker has spent two weeks inside your environment with domain admin credentials. Those are different design goals, and they lead to different shortlists. The short answer As a profile rather than a product: the best storage for Veeam is an S3-compatible target that holds a current Veeam Ready Object with Immutability qualification, enforces S3 Object Lock in compliance mode, supports the Veeam Smart Object Storage API, restores quickly under concurrent load, and sits behind a small enough attack surface that compromising the backup server does not reach it. Scality ARTESCA is built to that profile, and this is our site, so treat that as the disclosure it is. Use the eight criteria below on ARTESCA. Use them on everything else you are looking at. The four architectural options Teams protecting Veeam workloads generally land on one of four approaches, and each fails differently. Hardened Linux repository. Strong immutability on local disk, small footprint, no extra platform to run. Tends to hit limits on scale and multi-site copies. Public cloud object storage, such as Amazon S3 or Azure Blob. Removes the capacity ceiling and the hardware refresh. The cost profile inverts at restore time, when egress arrives all at once. On-premises S3 object storage. Keeps the data and the recovery path local, with cloud-style scale and Object Lock immutability. A platform you own is a platform you operate. Integrated appliance. Backup software and object storage on one host, which cuts the operational surface and the network path between them. The tradeoff is tighter coupling. Most mature environments run more than one, because 3-2-1-1-0 asks for more than one copy. The criteria below apply to whichever holds the copy you are counting on. 1. Immutability your own backup admin cannot revoke Immutability is the most claimed and least examined capability in this category. The distinctions live one layer down. S3 Object Lock supports two retention modes. In governance mode, a user holding the right permissions can shorten or remove a retention setting. In compliance mode, nobody can, including the account owner, until the retention clock expires. Modern ransomware operators do not fight the lock. They find the identity that can turn it off. So the useful question is not “does it support Object Lock.” It is: which identities can shorten a retention period, and does an attacker inherit any of them by compromising the backup server? Ask the vendor to walk the deletion path with you. If the answer involves a support ticket rather than an API call, that is a good sign. 2. Veeam Ready qualification, and specifically which tier Veeam runs a formal qualification program, and object platforms can appear at more than one level. “Veeam Ready – Object” means the platform passed functional testing as an object target. “Veeam Ready – Object with Immutability” means it also passed immutability testing. The gap between those two badges is the gap that matters in a ransomware event. Vendors are not always precise about which one they hold, so check the Veeam Ready listing rather than the marketing page. Confirm too that it covers the version you run, since qualifications are version-scoped and a platform validated several releases back has not necessarily been retested. 3. SOSAPI support, which is more consequential than it sounds The Veeam Smart Object Storage API, or SOSAPI, lets an S3-compatible platform describe itself to Veeam. The mechanism is deliberately plain: the storage publishes small XML documents into a hidden location in the bucket, and Veeam reads them over ordinary S3 calls. No agent, no extra port. What those documents carry is the interesting part. One advertises capabilities. Another reports real capacity, which Veeam refreshes on a short interval. Without it, Veeam shows an on-premises bucket as effectively unlimited, because S3 has no standard way to ask how much room is left, and retention decisions get made against a number that does not exist. Other parts of the API let a multi-node platform route backup streams to specific nodes, and let storage signal that it is temporarily not ready to accept writes. None of this is glamorous. All of it shows up as fewer surprises at two in the morning. 4. Restore throughput, measured separately from backup throughput Backup is a streaming write of large sequential blocks. Restore, particularly instant recovery and file-level recovery, is a different access pattern: smaller reads, less predictable, often concurrent across many jobs because everyone is restoring at once. A platform can be excellent at the first and mediocre at the second, and published benchmarks tend to emphasize ingest. Test restores. Then test restores while a backup job is running, because that is the state your environment will be in. 5. Blast radius between the backup server and the storage This one gets skipped because it is architectural rather than a feature you can tick. In a conventional deployment, the backup server and the storage platform are separate systems on a shared network, authenticating with credentials that live somewhere. Every element of that is a surface. Credentials can be harvested. The network path can be traversed. Management interfaces are usually reachable from the same subnet as everything else. Designs that reduce this vary. Some collapse backup and storage onto one host so the traffic between them does not cross a general-purpose network. Some enforce a hardened repository model with a locked-down operating system and single-use credentials. Some do both. The question is simple to ask and revealing to hear answered: if the backup server is fully compromised, what can the attacker reach, and what is out of reach by construction rather than by policy? 6. Verification that does not touch production The last digit in the 3-2-1-1-0 rule stands for zero errors on recovery verification. It is the digit most often treated as aspirational, because verifying properly means spinning backups up, and that means borrowing production capacity or funding a lab nobody budgeted. Recent Veeam releases have made this cheaper by letting a second backup server attach to immutable object storage in read-only mode, for recovery testing, forensic examination and validation, without taking ownership of the data or disturbing production jobs. We covered that in Veeam 13.1: what’s new for object storage. If a platform makes independent verification cheap, verification actually happens. That is worth more than most performance deltas. 7. Growth that does not require a redesign Backup capacity does not grow smoothly. It steps, when a retention policy changes, when a compliance requirement lands, when a new workload arrives. Some architectures absorb those steps by adding nodes. Others hit a ceiling that forces a migration, which is unpleasant because the data is large, retention locks are still running, and the chain has to stay intact. Ask where the ceiling sits for the configuration you are buying, not for the product family. 8. Cost measured across the retention window Price per terabyte is the easiest number to compare and among the least useful in isolation. Backup data sits for years, and over that window what accumulates is egress if the target is public cloud, API request charges under the transaction volume backup software generates, power and rack space if it is on-premises, and the time spent keeping two platforms patched and in sync. Model the full retention period, and put a restore of meaningful size in the model. Where Scality ARTESCA fits ARTESCA is Scality’s S3-compatible object storage, built specifically as a backup target. Here is the mapping against the criteria above, stated so you can check it. On criteria one and two, ARTESCA was certified Veeam Ready Object with Immutability and has been validated across subsequent Veeam releases, including S3 Object Lock and SOSAPI. Our CORE5 framework describes the layering applied above the lock, spanning API, data, storage, geographic and architectural levels. A single control is a single thing to defeat. On criterion five, ARTESCA+ Veeam runs Veeam Backup & Replication and ARTESCA on the same host, so traffic between the backup application and the storage stays internal rather than crossing a general-purpose network. A multi-node high-availability configuration followed in 2026, layering application, database and storage resilience together. On criterion seven, that software runs from tens of terabytes into the petabyte range on standard x86 servers, so growth is intended to be a matter of adding nodes rather than replatforming. For sizing, licensing and how the appliance model differs from a two-platform deployment, the ARTESCA + Veeam FAQ has the operational detail. None of which makes it the right answer everywhere. A shop with an established hardened Linux repository and a working tape rotation may already satisfy criteria one, five and six. The criteria are the durable part. A product is one way of meeting them. What to take away Evaluate the restore, not the backup. Ingest is the number vendors publish and the number that matters least during an incident. Test restores under concurrent load before you sign anything. Trace the deletion path, not the immutability claim. Everything supports Object Lock. What separates targets is which identities can shorten retention, and whether an attacker inherits them along with the backup server. Treat integration depth as a resilience feature. SOSAPI capacity reporting and read-only verification access sound like conveniences. They are what makes retention decisions correct and recovery testing cheap enough to actually do. The through-line is short. Backup storage exists for a day that has not happened yet, and on that day the measures that count are whether the copy survived and how fast it comes back. Immutability an attacker cannot revoke decides the first. Restore behavior under load decides the second. Everything else is a supporting argument. Frequently asked questions What is the best storage for Veeam backups? The strongest candidates share a profile: immutability a compromised backup administrator cannot revoke, a current Veeam Ready Object with Immutability qualification, SOSAPI support, restore performance validated under concurrent load, and a small attack surface between the backup server and the storage. Scality ARTESCA is designed to that profile for on-premises deployments. Score any candidate against those criteria, not against a single throughput or price figure. Is object storage better than a hardened Linux repository for Veeam? They solve overlapping problems differently, and plenty of environments run both. A hardened repository gives strong immutability on local disk with a small operational footprint. Object storage generally scales further, handles multi-site copies more naturally, and integrates through SOSAPI. Since 3-2-1-1-0 asks for more than one copy, the real question is which holds which. Does Veeam require S3 Object Lock in compliance mode? Veeam works with Object Lock generally, but the retention mode determines how much protection you get. Governance mode permits a sufficiently privileged identity to alter retention. Compliance mode does not, until the period expires. If that copy is the one you are counting on after a credential compromise, compliance mode matches the threat. Is Scality ARTESCA Veeam Ready? Yes. ARTESCA was certified Veeam Ready Object with Immutability and has been validated against subsequent Veeam releases, including S3 Object Lock and SOSAPI support. It is available as a software appliance, a hardware appliance, and as ARTESCA+ Veeam, which runs Veeam Backup & Replication and ARTESCA on the same host. How should I test a backup target before buying it? Restore a realistically sized workload, then repeat it while a backup job is active. Separately, try to delete a locked object using every credential in the environment, including the most privileged, and document what stops you. Further reading: Veeam 13.1: what’s new for object storage, ARTESCA + Veeam backup FAQ, and Veeam’s own SOSAPI documentation.
