Choosing storage capacity by guessing a single number is risky. A better approach is to establish the current requirement, add a realistic growth allowance and then account for the storage architecture.
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.
Start with current data
Measure the data that actually needs to be stored. Separate active business data from temporary files and data that does not need to reside on primary storage.
Estimate growth
Look at historical growth if it is available. If the business is changing, consider new users, applications, higher-resolution media, larger databases or other known sources of growth.
Raw versus usable capacity
The sum of the drive capacities is not necessarily the capacity available to applications. RAID, filesystem overhead and the storage platform can all affect usable capacity.
Leave room for operation and growth
A storage system should not be planned around the assumption that every available unit of capacity will always be usable. Growth and operational requirements should be part of the plan.
Think about backup capacity too
The storage required for primary data is not necessarily the storage required for backups. Retention periods, versions and backup schedules can increase the amount of backup storage required.
- Current data volume
- Annual or expected growth
- Required usable capacity
- RAID or redundancy overhead
- Operational headroom
- Backup and retention requirements
- Future expansion options
Confirm the exact product specification, supported configuration and compatibility before ordering. Platform generation, firmware, licences and optional components can change what a product supports.