Enterprise Storage
SAN vs NAS: When Block Storage Is the Right Choice
A larger storage requirement does not automatically mean SAN. Learn when block storage helps, where NAS fits and how to check performance, redundancy and recovery before buying.
The business has added a second server. Backups run into office hours, a database pauses during busy periods, and someone suggests replacing the NAS with a SAN. That might be the right project, but first establish whether the problem is disk latency, a saturated network, competing jobs or a missing availability design. Changing the storage label does not automatically fix any of them.
File and Block Storage: Who Owns the File System?
Network-attached storage (NAS) presents files and folders. A NAS or file server manages the file system, permissions and shared access; clients normally connect through SMB or NFS. It can serve a small office, a creative team or a much larger enterprise file estate.
A storage area network (SAN) provides block storage to hosts, commonly through iSCSI or Fibre Channel. The server or supported cluster uses the storage as volumes or LUNs and supplies the file-system or application layer. iSCSI can use Ethernet; Fibre Channel uses its own compatible fabric. Neither description tells you the media type, usable capacity or achievable response time.
File Access: The NAS Manages the File System
- User / Application
- Ethernet Network
- NAS / File Service
The client requests files and folders. The file service manages shared access and permissions.
Block Access: The Host Manages the Volume
- Server / Cluster
- Supported SAN Path
- Block Storage
The host uses volumes or LUNs. Shared writes require a supported coordination and fencing design.
These roles can coexist. A file server may store its data on a SAN and still present SMB shares to staff. Some storage platforms offer both file and block services. Buy the services and failure behaviour you need, rather than treating NAS and SAN as mutually exclusive classes of hardware.
Match the Storage to the Workload
| Workload | A sensible starting point | What must be checked |
|---|---|---|
| Shared documents, project folders and permissions | NAS or a managed file service | Identity integration, file locking, snapshots and restore |
| Large media archive or backup repository | Capacity-oriented NAS, file server or object storage | Retention, concurrent streams, growth and restore throughput |
| Virtual machines | A hypervisor-supported file or block datastore | Supported protocol, latency, multipathing and cluster behaviour |
| Transactional database | The database vendor’s supported storage design | Sustained latency, write durability, logs and recovery |
| Several hosts sharing block volumes | A supported SAN and cluster design | Fencing, coordinated access and failure testing |
A useful question is “Which storage configurations does this application support?” A hypervisor may support both NFS and block datastores. A database may have particular write-ordering or resilience requirements. Check those requirements before assuming that one protocol is inherently more professional.
There Is No Automatic 500 TB Changeover Point
Crossing 100 TB, 500 TB or another round number is a capacity-planning event, not a command to switch to SAN. A mostly sequential archive with modest concurrency has different demands from a smaller, heavily used transaction system.
Plan usable space after RAID or erasure coding, filesystem overhead, snapshots, growth and working headroom. Then assess how long it takes to rebuild protection, back up changed data and recover the business. Our RAID calculator helps with the capacity arithmetic; it cannot decide application compatibility or a suitable recovery design.
Measure Latency and Contention Before Replacing Storage
Capture evidence during the actual slow period. Record the application response time, storage latency and queueing, read/write mix, disk utilisation and network throughput. Check what else runs at that time: a backup, antivirus scan, snapshot job or replication task can change the result.
- For large-file transfers, check sustained throughput across the client, switch, storage interface and disk pool.
- For databases and virtual machines, look at latency under a representative mix of small requests, not only a sequential copy.
- Test enough data to avoid mistaking a short cache burst for sustained disk performance.
- Compare normal operation with a realistic degraded or rebuild condition where the platform supports a controlled test.
A faster interface can remove a bottleneck without changing the storage protocol. Conversely, upgrading to 25GbE will not repair a pool that is already limited by disk access or an overloaded application. The slow NAS transfer troubleshooting guide gives a practical sequence for separating those causes.
Shared Block Access Needs Coordination
Presenting one LUN to two servers does not make their ordinary file systems safe for concurrent writes. Without a supported cluster, locking and fencing design, hosts can overwrite each other’s metadata and corrupt the volume.
Use the operating system, hypervisor and storage vendor’s supported shared-storage arrangement. That may involve a cluster-aware file system, a supported clustered datastore or an application that explicitly coordinates access. Define which host owns each volume and what happens when a host loses contact with the cluster. Never test this by attaching an existing production volume to another writable host.
Dual Controllers Are One Part of Availability
A dual-controller array can reduce a particular failure risk. The end-to-end service still depends on host adapters, cables, switches, power, path configuration and the application. Two paths through the same switch or power source may retain a common point of failure.
The Synology UC3400 is an example of a system designed around active-active SAN services, with iSCSI and Fibre Channel support subject to the appropriate supported configuration. It is a different role from a desktop file-sharing NAS. Confirm the host, adapters, firmware and multipathing requirements as one design.
Document expected behaviour before a controlled acceptance test: which path fails, how the host detects it, whether I/O resumes within application limits, and how service is restored after maintenance. Redundancy that has never been exercised is an assumption.
Future-Proof the Operating Plan
Look beyond spare drive bays. Allow for network uplinks, qualified adapters and transceivers, support coverage, firmware maintenance, monitoring, rack power and backup capacity. Confirm whether adding shelves or changing drive types is supported without disrupting the service.
Assign someone to capacity alerts, failed paths and recovery checks. A modest system with a clear operating plan can be a better business fit than a larger platform the team cannot maintain. For dense capacity behind host servers, read the separate Exos CORVAULT architecture guide; it explains why a SAS storage system still needs the appropriate server and front-end services.
Set an Acceptance Test Before the Purchase
- Name the application, supported protocol, host versions and required usable capacity.
- Define acceptable latency and throughput during the busiest representative workload.
- Set recovery point and recovery time objectives for both hardware failure and lost or damaged data.
- Agree the path, controller and power-failure tests that can be performed safely.
- Restore a representative application or dataset from an independent backup.
A proof of concept is especially useful when the decision depends on application behaviour rather than a published interface speed. Keep the test repeatable and preserve the configuration and results.
Frequently Asked Questions
Is SAN always faster than NAS?
No. Media, controllers, network paths, request size, concurrency and application design determine performance. A properly sized file service can outperform an undersized block-storage system. Compare the required workload and latency.
Should a business move to SAN above 500 TB?
There is no universal capacity threshold. Large file archives can remain on NAS or another file service. The decision depends on access method, performance, growth, availability and recovery requirements.
Can virtual machines run on NAS?
Yes, where the hypervisor and storage platform support the selected file protocol and configuration. Check the current compatibility matrix, datastore requirements and failure behaviour for the exact products.
Can two servers write to the same iSCSI LUN?
Only with a supported design that coordinates access, such as an appropriate cluster or application. Connecting an ordinary writable filesystem to two independent hosts can corrupt data.
Do dual controllers remove the need for backup?
No. Controller redundancy addresses particular hardware failures. It does not provide an independent recovery copy for deletion, ransomware, application corruption or a site incident.
What information is needed to size SAN or NAS?
Provide applications and host versions, usable capacity and growth, read/write workload, latency requirements, network design, backup window, recovery objectives and support expectations.
Which Storage Path Makes Sense?
Keep NAS on the shortlist for shared files, archives and supported file-based applications. Consider SAN when the application, clustering requirements or availability design calls for block storage. Validate the actual workload and complete data path before paying for a migration.
For a new project, start with the NAS selection guide or discuss a defined workload through networking and storage consulting. The most useful specification describes the service the business needs to keep running.
