A modern storage system is not just a set of disks. Virtualisation, databases, file services and other critical workloads all run on one infrastructure, and the data has to stay available not only when hardware fails, but after accidental deletion, corruption or a destructive attack.
Sizing starts from the workload profile, not from nominal capacity.
The system has to work when not every component is healthy.
A successful backup is not yet proof that you can recover.
Hafaza Tech designs and implements storage systems and backup based on Huawei OceanStor, NetApp, Lenovo ThinkSystem Storage and Veeam — from workload assessment and sizing through to migration, replication, backup and recovery testing.
A storage platform. The OceanStor portfolio covers block, file and object scenarios: virtualisation, databases, enterprise applications, high-load workloads, file services, capacity environments, replication and data protection.
The specific platform is chosen by workload profile, performance, capacity, availability, growth and data protection requirements. Huawei is also developing cyber-resilience mechanisms inside its storage portfolio, but what is available depends on the model, the version and the architecture — that is verified for the specific configuration.
A storage platform. The architecture is built around ONTAP and mature data management capabilities. It suits block and file access, virtualisation, databases, enterprise file services, replication and data protection.
NetApp develops ransomware protection at the storage layer, tamper-resistant snapshots and isolated-copy approaches as additional layers of the recovery architecture. Such mechanisms do not replace a full backup and a disaster recovery plan.
A storage platform. ThinkSystem Storage is used for virtualisation, databases, enterprise applications, file services, backup repositories and general-purpose infrastructure workloads.
Lenovo has validated architectures together with Veeam for backup and recovery scenarios. A practical option where a predictable enterprise storage architecture and integration with an existing Lenovo infrastructure are needed.
The backup layer. Veeam works on top of the production infrastructure and solves a different problem: backup that accounts for the type of workload, retention policies, hardened repositories, application-consistent recovery, secondary copies and recovery testing.
Veeam does not replace snapshots, replication and resilience at the storage layer — it adds a separate layer with its own policy and its own lifecycle.
Huawei, NetApp and Lenovo are storage platforms. Veeam is the backup and recovery layer.
Together they give what the architecture is built for: several independent paths to recover the data.
A project starts with the architecture and the sizing; the specific model is chosen afterwards. Comparing cost per terabyte without a workload profile leads to a system that fails at the moment it is needed.
Where a project starts
The same 500 TB can serve transactional databases, virtualisation, virtual desktops, file services, analytics, an archive or a backup repository. A storage system for a large archive and one for a high-load database can have the same capacity and completely different latency and architecture requirements.
Workload profile
Usable capacity
Performance
Availability
Growth
Data protection and recovery
Volumes and LUNs for workloads that need predictable latency and performance: virtualisation, databases, enterprise applications.
Shared file access: NAS, user data, file services for applications.
Large volumes of unstructured data, archives, backup repositories and workloads where an object model is the natural fit.
When storage systems are compared, different capacity figures mean different things, and performance cannot be judged by a single number.
The physical capacity of the installed drives.
The capacity left after data protection overhead and system reserves. This is what we size against.
The projected capacity after compression, deduplication and other efficiency mechanisms.
Effective capacity depends heavily on the type of data: already compressed or encrypted sets may hardly shrink at all. An efficiency ratio cannot be treated as guaranteed without analysing the specific workload.
Performance
A hundred thousand operations on small random reads and a hundred thousand on a mixed large-block workload are completely different scenarios. So test results are read together with latency, block size, the read/write mix and the assumptions about cache.
IOPS and throughput
Latency
Block size
The read/write mix
Workload concurrency
Sequential and random access
Cache behaviour
Interfaces and internal architecture
A storage system that meets its requirements only in a healthy state may fail during a real incident.
Resilience
For critical workloads the storage infrastructure has to survive component failures: redundant controllers and nodes, multiple access paths, redundant fabrics, protection at the disk group level, clustering, synchronous or asynchronous replication, and site-level resilience.
Redundant controllers and nodes
Multiple access paths
Redundant fabrics
Protection at the disk group level
Clustering
Synchronous and asynchronous replication
Site-level resilience
Redundancy is not backup, and high availability is not data recovery. Resilience does not protect against logical corruption, accidental deletion, an administrator’s actions, ransomware or an incorrect change made by an application. These are different problems and different layers of the architecture.
Modern data protection normally uses several mechanisms at once, and each of them solves its own problem.
They create recovery points quickly and often allow a very fast rollback. But a snapshot stays part of the same storage system and is not a backup strategy in itself: its resilience depends on the retention policy, on administrator rights and on the protection mechanisms of the storage system.
It creates a copy of the data on another system or site and is useful for availability and disaster recovery. But replication passes on corruption, accidental deletion, an unwanted change or the work of ransomware just as quickly.
It creates copies with their own policy, retention period and recovery lifecycle. For critical workloads the copy is placed, where possible, in a failure and security domain separate from the production infrastructure.
Security of the storage platform
If an attacker gains privileged access to storage management, they can change the configuration, delete snapshots, switch off replication, destroy recovery points or break availability. So storage management is protected no less strictly than other critical systems.
Role-based access
Multi-factor authentication where supported
Separation of administrative roles
Isolation of the management network
Encryption at rest and in transit
Logging and audit
Control of administrative changes
Protected replication
Security and resilience are not the same thing. Security protects management and access, while resilience answers the question of whether the data can be recovered after a destructive event.
Immutability protects recovery points from being changed or deleted for a defined period. But the term “immutable copy” guarantees nothing on its own — what matters is the actual administration model.
The key design question: having compromised the management of the production environment, could an attacker destroy the recovery data with the same credentials or over the same network paths? If so, the recovery layer is not independent enough.
Who can delete the copy
Which credentials that requires
Whether the retention period can be changed
Whether the management platform can bypass the protection
What happens if management is compromised
Different technologies give different levels of protection: a read-only snapshot, a tamper-resistant snapshot, an immutable repository, an isolated or offline copy. For critical workloads we use logical isolation, separate credentials, a dedicated recovery zone or a physically isolated copy — where that is genuinely required.
Backup is a separate layer on top of production storage. Its performance depends on more than the repository.
The key question during an incident
A lot of design attention goes to the backup window. But during a serious incident something else matters more: how long recovery will take. A repository that ingests backups quickly will not necessarily restore tens of terabytes of critical workloads within the required time.
Acceptable data loss — RPO
Acceptable recovery time — RTO
Criticality of the workload
Retention of the copies
Required recovery speed
A critical database, an enterprise system, a file archive and a test virtual machine should not automatically get the same protection policy. So the chain looks like this: workload criticality → RPO → RTO → protection method.
One of the most common mistakes is treating a “job completed” status as proof that the service can be brought back up.
Backup is primarily about recovering data, while disaster recovery is about restoring a business service. Having a copy of a database does not mean the application can be brought up: you also need compute, network, accounts, dependencies and an order of operations.
The restore itself
Data integrity
Application consistency
Dependencies and start-up order
Credentials and access
Network configuration
Meeting the RPO
Meeting the RTO
The 3-2-1-1-0 approach remains a useful reference: three copies, two different storage media, one copy off site, one immutable or offline, zero unverified recovery errors. But it is a design reference, not a mandatory architecture: what matters is that the copies are independent of the failure and compromise domains.
A project rarely ends with installing a new storage system: the existing workloads have to be migrated safely.
For critical systems the migration is designed as carefully as the target architecture itself. Before the cutover we define the transfer method, the downtime requirements, compatibility, the copy or replication method, the rollback scenario and the acceptance criteria.
Acceptable downtime
Host compatibility
Multipathing
Fabric zoning
Application dependencies
Replication and bandwidth
The cutover window
Rollback
Data verification
The stages are ordered so that the architecture is sized from real workloads and recovery is tested before it is needed.
01
Assessment
02
Workload profile
03
Sizing
04
Architecture
05
Migration
06
Data protection
07
Backup
08
Recovery testing
09
Support
We review the existing storage, the network and fabric infrastructure, hypervisors, databases, applications, file services, the current backup and replication, capacity, growth, performance, availability, disaster recovery and security requirements. We check the protocols and interfaces in use.
For every critical workload we assess usable capacity, IOPS, throughput, latency, the read/write profile, concurrency, growth, criticality, availability requirements and the RPO and RTO.
The sizing accounts for the current load, growth, failure scenarios and data protection overhead: disk group protection, snapshots, replication, spare capacity, rebuilds, data efficiency assumptions, expansion and the load created by backup.
The architecture defines the requirements for block, file and object access, the protocols, the controller and node architecture, connectivity, resilience, multipathing, replication, snapshots, the management network and monitoring. Where required, a multi-site architecture is designed.
For each workload we define the set of recovery layers it needs: snapshot, replication, backup copy, hardened or isolated copy. Not every workload needs all of them — the set is chosen by criticality and recovery requirements.
After the rollout what is tested is not the creation of copies but the full cycle: backup → restore → start the application → verify the data. For critical workloads such tests are repeated regularly.
The choice cannot be reduced to a brand or to cost per terabyte. A project starts with the architecture and the sizing — the model is chosen afterwards.
The workload profile, usable capacity, IOPS, throughput, latency.
Supported protocols, the connectivity architecture, multipathing.
The resilience architecture, behaviour in a degraded state, scalability.
Snapshots, replication, data efficiency, the mechanisms that protect the copies.
Lifecycle, support, operational complexity.
Licensing and the total cost of ownership over the horizon of the project.
For backup we separately assess recovery speed, application consistency, retention policies, hardened repositories and the ability to test recovery.
A modern storage system is not only capacity, but performance, availability, data protection and the ability to recover.
Store data at the required performance → survive component failures → keep recovery points → have a separate backup → protect the copies → restore critical services within the agreed times.
Didn’t find the answer to your questions? Send your question below and our support team will answer it soon. We are here to help you with cybersecurity!
Ask a question!
If you want to learn more about our cybersecurity services or are not sure which solutions are right for you, leave a request and our specialists will contact you for a free consultation.
Complementary solutions for comprehensive infrastructure protection and a higher overall level of information security.
Protection of privileged access to storage and backup management.
Monitoring of critical administrative events, failures and attempts to delete copies.
Additional context during destructive incidents and ransomware attacks.
