A storage system should be designed around the data and the applications using it. Starting with a drive capacity number alone can lead to the wrong solution.
Practical example: NAS, DAS or SAN?
For shared office files, NAS is often the natural architecture to evaluate first.
Scenario: A 25-user office needs shared departmental files, central backup storage and controlled user access.
A NAS is a natural candidate because it provides file services over the existing network. A directly attached enclosure would tie the storage more closely to one host. A SAN would make more sense where servers require shared block storage, for example in a more complex virtualisation environment.
Decision: For this example, start by evaluating NAS capacity, drive type, network speed, snapshots and backup replication. Do not deploy SAN architecture merely because it sounds more enterprise.
Common mistakes and selection checklist
Common mistakes
- Choosing NAS, DAS or SAN because one architecture sounds more enterprise rather than because it fits the workload.
- Sizing storage only by terabytes and ignoring IOPS, throughput, network speed, snapshots and backup.
- Using one storage system as both primary data and the only backup copy.
What happens if you get it wrong?
Users can experience slow file access or applications can be constrained by the wrong storage path. More importantly, a storage failure or data-loss event can affect both production data and the supposed recovery copy.
Selection checklist
- Decide whether applications need file storage, block storage or storage attached to one host.
- Estimate current usable capacity and realistic growth.
- Identify performance, network and concurrency requirements.
- Check drive type, RAID options, snapshots and expansion.
- Design backup and off-system recovery independently.
A resilient array keeps services available during some drive failures. Separate backups provide recovery from deletion, corruption, malware and site loss.
1. Establish the capacity requirement
Work out how much data needs to be stored today, then estimate reasonable growth. Separate usable capacity from raw drive capacity because RAID and other storage arrangements can reduce the capacity available to applications.
2. Understand how the data is accessed
Determine whether users need shared files, whether applications need storage presented directly to servers, or whether storage will be attached to a particular system. This helps narrow the architecture between NAS, SAN and DAS.
3. Consider performance
Some workloads are sensitive to storage response time and I/O performance. Others are more focused on capacity. The workload should determine whether HDDs, SSDs or a combination is appropriate.
4. Plan redundancy
Storage redundancy can reduce the impact of a drive failure. RAID is one common approach, but the correct configuration depends on capacity, performance and fault-tolerance requirements.
5. Plan the backup separately
Redundancy and backup solve different problems. A storage system can remain operational after a drive failure while still being vulnerable to deletion, corruption or other events. A separate backup strategy is therefore required.
6. Consider expansion
Storage requirements tend to grow. Consider how additional drives, expansion units or a larger storage platform could be accommodated later.
7. Check compatibility
Drives and storage components need to be compatible with the intended enclosure, server, controller or NAS platform. Physical form factor and interface are part of the selection.
- Current usable capacity
- Expected growth
- Access method
- Performance requirement
- Redundancy requirement
- Backup strategy
- Expansion path
- Hardware compatibility
A useful storage design balances capacity, performance, access, resilience, backup and future growth.
Confirm the exact product specification, supported configuration and compatibility before ordering. Platform generation, firmware, licences and optional components can change what a product supports.