When a backup estate outgrows its repository, UK teams face a fork: buy more of a purpose-built deduplication appliance, or build a high-capacity landing zone on a dense server and let the backup software do the clever parts. The HPE Apollo, with its petabyte-scale disk density, is a natural fit for the second path, a large, cost-effective backup target that your backup application writes to directly. This article looks at the Apollo as that capacity tier, how it sits alongside an HPE StoreOnce dedupe appliance, and the decision of when each is the right tool. It pairs with our deeper guidance on sizing the repository itself.
Two philosophies for a backup target
There are two established ways to land backups on disk, and they differ in where the intelligence lives. A purpose-built backup appliance, such as HPE StoreOnce, performs deduplication and compression in the appliance itself: it is a turnkey box optimised to store the least possible data for a given set of backups, with that efficiency built in and managed for you.
The alternative is a capacity-tier target: a large, relatively simple pool of disk that the backup software writes to, with deduplication, compression and immutability handled by the backup application rather than the storage. The Apollo fits this model perfectly, providing dense, economical capacity as the landing zone while the software does the data reduction. It is the same dense-disk strength described in our look at the HPE Apollo family, pointed at backup rather than primary storage.
- •Purpose-built appliance (StoreOnce): dedupe and compression built into the box
- •Capacity tier (Apollo): dense disk the backup software writes to and reduces
- •Appliance optimises stored capacity; capacity tier optimises cost per raw TB
- •Both can be part of one estate, serving different tiers
How the Apollo capacity target is built
As a backup target, the Apollo is configured for capacity and throughput rather than the low latency a primary array chases. The bulk of the storage is high-capacity disk to hold the backups economically, presented to the backup software as a repository. The design emphasis is on sustained write throughput, so backups complete inside their window, and on enough resilience that the repository itself does not become a single point of failure.
A detail that matters increasingly is the role of fast flash within an otherwise capacity-oriented target. Backup software performance, and especially the speed of restores and synthetic-full operations, benefits from a layer of NVMe for metadata and caching, even when the main capacity is disk. Sizing that flash layer alongside the bulk capacity is part of getting a backup repository right, and it is where the drive choices in our SSD and NVMe guidance feed into the Apollo build. The fuller method for sizing any repository, throughput, capacity, resilience and immutability, is set out in how to spec a Veeam backup repository server.
Immutability and the role of software
A backup target that can be encrypted or deleted by ransomware is not really a backup, so immutability, the guarantee that backups cannot be altered or removed within a retention window, is now a baseline requirement. On a capacity-tier Apollo, that protection is delivered by the backup software and operating system, for example a hardened repository with immutable flags on a Linux filesystem, rather than by a dedicated appliance feature.
This is the trade at the heart of the capacity-tier approach: you take on responsibility for configuring deduplication, compression and immutability in the software layer, in exchange for cheaper, denser raw capacity and the flexibility of a general-purpose platform. Done correctly it is robust and economical; done carelessly it is just a big disk. Getting the immutability and hardening right is exactly the kind of build detail we cover when sizing a repository, and which we apply when configuring an Apollo as a backup landing zone.
Apollo capacity tier vs StoreOnce
The choice between an Apollo capacity tier and a StoreOnce appliance comes down to a handful of factors. Choose StoreOnce when you want turnkey, vendor-managed deduplication, tight integration with backup software through HPE's Catalyst, and the operational simplicity of an appliance that just works, particularly where storing the absolute minimum data is the priority and you are happy to pay for that efficiency in a packaged product.
Choose an Apollo capacity tier when the priority is the lowest cost per raw terabyte at large scale, when your backup software already provides strong deduplication and immutability, and when you value the flexibility of a general-purpose platform you can repurpose or scale on your own terms. Many estates run both, a dedupe appliance for one tier and a dense capacity target for another, and the right split is a design question. We work it through as part of an Apollo engagement, with the appliance side covered by our HPE StoreOnce range. The decision flow below summarises the main branches.
Where the Apollo backup target fits
The Apollo earns its place as a backup target where scale and cost dominate: large capacity-tier or long-retention repositories, secondary copies, and estates whose backup software already does the data reduction and immutability well. It is the dense, economical landing zone those designs are built around, and for organisations standardised on HPE it stays within a familiar support and management model.
It is the less natural choice when you specifically want appliance-managed deduplication and the minimum stored footprint with the least configuration, where StoreOnce is purpose-built for the job. As with the rest of the portfolio, the answer follows the requirement and the scale, and the two approaches are complementary rather than mutually exclusive. We size the target, capacity, flash layer and immutability, using our SSD and NVMe guidance and the repository method in spec a Veeam backup repository server.