Solutions
Hybrid should not mean three operating models.
AiRE runs as a physical appliance, a virtual instance in your cloud, or at the edge. The profiles, policies, protection model and fleet management are the same in all three.
- One policy model
- Block-level incremental replication
- Centralised fleet management
The problem
The estate modernised. The operating model did not.
Most hybrid estates were not designed; they accumulated. An array on premises, object storage in a public cloud, something at each branch, and a backup product joining them. Each has its own snapshot semantics, its own encryption story and its own console.
The cost is not primarily licensing. It is that a single requirement — retain this for seven years, encrypted, with a tested recovery path — has to be implemented three times, in three systems, by people who each understand one of them.
It is also why estate-wide questions are hard to answer. Where does this data set actually live? Is it encrypted everywhere? When was recovery last tested? These should be one query, not a project.
One policy set, defined once
- Performance profile
- Per-data-set encryption
- LZ4 compression
- RAID-Z protection
- 7-day snapshot retention
On-premises
AiRE Unified Data Platform
your rack, your control
- Performance profile
- Per-data-set encryption
- LZ4 compression
- …and the rest, identically
Public or private cloud
Virtual AiRE instance
your chosen region
- Performance profile
- Per-data-set encryption
- LZ4 compression
- …and the rest, identically
Edge site
Compact AiRE unit
no local administrator
- Performance profile
- Per-data-set encryption
- LZ4 compression
- …and the rest, identically
Block-level incremental replication moves only snapshot deltas between them
What STORViX does about it
The same platform wherever the workload runs.
An AiRE instance is an AiRE instance, whether it is a GEN 4 appliance in your rack or a virtual instance in a cloud region.
One policy model everywhere
Profiles and policies attach to the data set, not the deployment. A data set configured for resilience behaves the same on premises and in the cloud, because it is the same software making the decision.
- Performance, resilience and optimisation profiles
- Encryption per data set
- Consistent block sizing and cache behaviour
Replication that moves deltas only
Block-level incremental replication synchronises the differences between snapshots rather than resending data. That is what makes on-site and off-site copies affordable over ordinary links.
- Snapshot-based, block-level
- Minimal bandwidth and storage
- On-site and off-site
Centralised fleet management
Software updates, configuration changes and commands go to as many instances as needed at once. An estate stays consistent rather than drifting instance by instance.
- Fleet-wide updates
- One console for many instances
- Consistent configuration
Cloud connectivity in both directions
CloudSight provides the two-way cloud connection that carries telemetry up and remote assistance down. STORViX has established partnerships with AWS and Oracle.
- Two-way cloud connection
- CoPILOT Connect remote assistance
- AWS and Oracle relationships
Edge sites without local staff
AutoPILOT performs optimisations and administration autonomously, escalating what it cannot resolve. That is what makes a distributed estate manageable without a technician per site.
- Autonomous optimisation
- Escalation on unresolved issues
- Managed from the central console
Vault as the common off-site target
Wherever the primary instance runs, the off-site copy can land in STORViX-operated EU data centres under one set of terms — rather than a different archive arrangement per environment.
- Sweden, Italy and other EU countries
- AES 256 at rest
- Zero-knowledge privacy policy
Outcomes
What changes in practice
One requirement, implemented once
A retention or encryption requirement is expressed as a data set policy and behaves identically wherever that data set lives.
Estate-wide questions become answerable
Fleet management and CloudSight telemetry give one view of configuration, health and capacity across instances.
Workloads can move without a storage project
Because the platform is the same at both ends, relocating a workload is a replication task rather than a re-architecture.
Fewer specialisms to hire for
One platform to know, rather than one per environment — which matters more than licence cost in a small infrastructure team.
Where the boundaries actually sit
AiRE running in a public cloud is a virtual instance on that provider's compute and storage. The provider's infrastructure charges, including egress, remain the provider's — STORViX does not absorb them, and no page here should imply otherwise.
Performance of a cloud instance is bounded by the underlying instance type and its attached storage. The data services are identical; the hardware beneath them is not.
Data residency in a public cloud is determined by the region you select with that provider. Where residency is a hard requirement rather than a preference, owning the appliance or using Vault gives a guarantee that a cloud region setting does not.
Work out which parts belong where.
The useful conversation is about which workloads stay on premises, which move, and what the replication topology between them should be. That is an architecture discussion, not a product pitch.