Most organisations do not choose appliance lock-in. They arrive at it one purchase at a time, and notice when the third expansion quote lands. If you are holding a refresh quote and wondering whether that capacity increment is really the only option, this is the arithmetic underneath the feeling, and what changes when the storage layer stops being the hardware.
Worth separating two things that get bundled together. An appliance as a form factor is a good idea: pre-sized, software matched to the platform, quick to stand up. vStor ships as a virtual appliance for exactly that reason, and DPX is deliberately multi-function in the purpose-built backup appliance sense.
The problem is narrower: a fixed-capacity hardware appliance, where the vendor owns how and when you grow. That constraint shows up later, and it shows up as arithmetic.
The economics of buying capacity in vendor-sized steps
Four constraints arrive with the box:
- Capacity comes in the increments the vendor sells, not the ones you need.
- Performance upgrades usually mean another hardware quote.
- The refresh cycle follows a vendor roadmap rather than your infrastructure plan.
- Unplanned growth forces an expansion purely to hold retention where it already was.
This collides with a second fact. Most backup budgets are flat or shrinking while the data they cover keeps growing. The hardware-appliance answer to that squeeze is to buy the next increment, which forces a large purchase even when the actual shortfall is small or confined to one workload.
The awkward part is that this arrives at the same moment as everything else. Teams are being asked to improve ransomware recoverability, extend coverage to more hypervisors, support edge sites, and hold costs flat. A storage platform that only grows through proprietary purchases turns each of those into a capital request.
What changes when the storage layer is software-defined
Catalogic vStor separates the backup storage software from the hardware decision. It deploys as a virtual appliance or on a physical server, so the repository gets designed around your data rather than around a product catalogue.
| Fixed-capacity hardware | Software-defined | |
|---|---|---|
| Capacity grows in | Vendor increments | Whatever you can provision |
| Performance change | New hardware quote | Move to faster storage |
| Branch office | Rarely justifiable | Right-sized deployment |
| Refresh driven by | Vendor roadmap | Your own planning |
In practice that means faster storage under workloads with short restore expectations, cheaper capacity under long retention, and something small at a branch that could never justify its own hardware. The same protection controls apply across all of them.
DPX still gets a managed backup destination. What changes is who decides how that destination is funded and expanded.
Capacity efficiency is not a rounding error
Backup storage has to absorb data fast enough to keep jobs inside their window, and retain it efficiently enough to keep restore points available. When a repository is overloaded the symptoms are familiar:
- missed backup windows
- retention cleanup that overruns
- pressure to keep fewer restore points
That last one is a recovery decision being made by a storage constraint.
vStor uses ZFS compression and deduplication to reduce that pressure. Compression shrinks data as it is written. Deduplication stores repeated blocks once, where the workload makes that worthwhile.
Ratios depend entirely on the data. VM images, logs, databases and repeated backup sets usually benefit. Already-compressed or encrypted data does not, and no product will change that.
The point is not the ratio. It is that storage efficiency directly sets how long you can keep clean restore points available after an incident, which is a recovery capability rather than a cost line.
Mixed workloads make a fixed repository worse
A single DPX environment rarely protects one clean data type. It holds VM images, file servers, application volumes, databases, log-heavy systems and remote office data, and each behaves differently:
- some compresses well, or has repeated blocks worth deduplicating
- some changes so fast that yesterday’s copy is already stale
- some must be kept for years and will almost never be read
A fixed-capacity design hides those differences until the repository fills. Then every option is bad: shorten retention, drop restore points, move data by hand, or raise a purchase request. The first two weaken recovery posture to solve a storage problem.
Designing the repository with workload behaviour in mind avoids most of that, and it makes the resulting plan explainable. An administrator can say why a workload sits where it does, why its retention is what it is, and what protects its recovery points.
Remote sites and changing platforms
Branch and edge locations have real data and limited staff. They rarely justify a hardware appliance of their own, but they still need local restore capability and protected recovery points. Central-only backup creates bandwidth pressure and slow restores, particularly over a thin WAN link.
Deployment flexibility means a right-sized vStor at the branch handles local recovery, then replicates selected recovery points to a central target for resilience. That is a better answer than choosing between hardware nobody can justify and a restore that takes a day.
The same argument applies to virtualization strategy, which is unusually unsettled right now. Organisations are staying on VMware, expanding Hyper-V, adopting Nutanix AHV or Proxmox, or running several at once.
A repository tied to one hardware platform, or to one hypervisor assumption, becomes a migration constraint exactly when flexibility is worth most. Software-defined storage keeps the platform decision on its own merits, and DPX covers the workloads either way across VMware, Nutanix and Proxmox.
Working out the cost case
If the term itself is what you are pinning down, what is immutable storage covers WORM, deletion locks and what they do and do not protect. If the cost case is settled and the question is design, planning immutable storage covers what to keep local, what to replicate, and how to prove the restore works.
For the product view, see immutable storage for backups or request a demo.
Pawel Staniec
CTO
Pawel is CTO at Catalogic Software, where he owns DPX product architecture and technology direction and works with our developers, alliance partners and customers across EMEA to keep what we build aligned with how our data protection products are actually deployed. He writes about the engineering behind our releases, including NDMP backup management, Proxmox VE protection, and where hypervisor-native backup tooling stops being enough.
