DAS, NAS and SAN

Three ways to attach storage

Storage Fundamentals explains block, file and object storage as interfaces. DAS, NAS and SAN describe something related but different: how the storage is physically and logically attached to the servers that use it. The question that separates them is simple: who can reach the storage, and over what?

Direct-attached storage (DAS)

Direct-attached storage (DAS) is storage connected straight to one server, with no network in between: the drives in the server's own bays, or an external enclosure cabled to the server's host adapter, usually with Serial Attached SCSI (SAS). The server's operating system sees the drives (or the RAID volumes built from them) as local disks; see storage interfaces for SATA, SAS and NVMe.

DAS has real strengths: no storage network to design, the lowest possible latency, and the lowest cost per terabyte. That is why it is everywhere: boot drives, single database servers, backup servers with a large disk shelf, and the nodes of software-defined storage and hyperconverged clusters, which turn many servers' local drives into one shared pool with software.

JBOD enclosures

JBOD ("just a bunch of disks") means drives that are presented as they are, without RAID. In a data center you mostly meet the word as a product type: a JBOD enclosure or expansion shelf is a box of drive bays with power supplies, fans and SAS expanders, but no RAID controller of its own. Redundancy has to come from somewhere else: a RAID controller in the server, a software RAID or ZFS pool, or a storage array whose controllers the shelf is cabled to. On a single machine, JBOD can also mean drives spanned into one volume with no redundancy at all (see RAID).

The limits of DAS

• Not shared. Only the attached server uses the capacity. Free space on one server cannot help another that is full, so DAS estates tend to be both over-bought and out-of-space at the same time.
• Tied to the server's fate. If the server dies, its data is unavailable until the server is repaired or the drives are moved. A virtualization cluster cannot restart a VM on another host if the VM's disk lives inside the failed one (see Data Center Virtualization in Practice).
• Managed one box at a time. Firmware, RAID monitoring and capacity have to be watched per server.

Some two-node clusters share one SAS enclosure, cabled to both servers, with dual-ported SAS drives. That is still DAS — no network — but shared by two hosts, a cheap middle ground for small sites.

Network-attached storage (NAS)

Network-attached storage (NAS) is a storage system that runs its own file system and shares it over the ordinary Ethernet and IP network as file shares. Clients ask for files and folders by name; the NAS handles where the blocks go, who may open what, and who holds a lock. A NAS can be a small appliance, a Windows or Linux file server, a "unified" storage array that also serves block storage, or a scale-out NAS cluster that grows by adding nodes.

Because the NAS owns the file system, many clients can safely work in the same folders at once. Two protocols dominate: NFS and SMB.

NFS

The Network File System (NFS) is the file-sharing protocol of the Unix and Linux world, also widely used for VMware datastores. It runs on TCP port 2049. The server exports directories; clients mount them into their own directory tree (see Linux storage in practice).

On a Linux NFS server, exports are listed in /etc/exports. Each line names a directory, the clients that may mount it, and options:

/srv/scans    198.51.100.0/24(rw,sync,root_squash)  203.0.113.20(ro,sync,root_squash)
/srv/vmstore  198.51.100.31(rw,sync,no_root_squash) 198.51.100.32(rw,sync,no_root_squash)

sync makes the server confirm a write only once it is on stable storage; root_squash maps a client's root user to an unprivileged account, so root on a client is not root on the share. Hypervisor datastores are the usual exception that needs no_root_squash, which is why such exports are limited to the exact host addresses. A Linux client mounts the share:

$ sudo mount -t nfs -o vers=4.2 nas01.example.com:/srv/scans /mnt/scans

SMB

Server Message Block (SMB) is the file-sharing protocol of Windows, also implemented by Samba on Linux and by almost every NAS. It runs on TCP port 445. Users connect to shares by Universal Naming Convention (UNC) path, such as \\fs01.example.com\contracts, and access is controlled with Active Directory accounts and NTFS-style permissions.

• CIFS (Common Internet File System) is the old name of an early SMB dialect from the 1990s. The name survives in product menus, Linux mount types (mount -t cifs) and exam objectives, but nobody should run that dialect any more.
• SMB1 is insecure (the WannaCry ransomware spread through an SMB1 flaw in 2017) and is no longer installed by default in current Windows versions. A device that "needs SMB1" — an old scanner, say — is a reason to replace the device, not to enable SMB1.
• SMB 3.x added encryption, multichannel (several network links in parallel) and transparent failover between cluster nodes, which made SMB fit for Hyper-V and SQL Server data on file shares.
• In Windows Server 2025, SMB signing is required by default for outbound connections, and SMB over QUIC (UDP 443, protected by TLS 1.3) is available in all editions. Signing stops tampering and relay attacks, at some CPU cost on older hardware.

One share, two protocols

Many NAS systems can serve the same folder over NFS and SMB. That sounds convenient but is a classic source of trouble: NFS identifies users by number (UID and GID), SMB by Windows security identifiers, and the two permission models (POSIX mode bits or NFSv4 ACLs versus Windows ACLs) do not map one to one. Multiprotocol shares need a consistent identity mapping (usually through Active Directory or LDAP) and a decision about which permission style wins. When in doubt, give each share one protocol.

NAS performance

A NAS shares the network with everything else, so its speed is capped by the slower of two things: the network link and what its drives can absorb. File protocols also add overhead per file, so millions of small files move much more slowly than a few large ones. A migration estimate:

# Copying 6 TB of scanned contracts to a new NAS: which link speed is worth it?
DATA_TB = 6
EFFICIENCY = 0.80        # protocol overhead and small files: about 80% of line rate
NAS_WRITE_MB_S = 1_100   # what the NAS's drives can absorb, from the vendor sheet

for name, gbit_per_s in [("1 GbE", 1), ("10 GbE", 10), ("25 GbE", 25)]:
    network_mb_s = gbit_per_s * 1000 / 8 * EFFICIENCY
    rate_mb_s = min(network_mb_s, NAS_WRITE_MB_S)
    limit = "network" if network_mb_s < NAS_WRITE_MB_S else "NAS drives"
    hours = DATA_TB * 1_000_000 / rate_mb_s / 3600
    print(f"{name:7} {rate_mb_s:6.0f} MB/s  {hours:5.1f} h  (limited by {limit})")

1 GbE      100 MB/s   16.7 h  (limited by network)
10 GbE    1000 MB/s    1.7 h  (limited by network)
25 GbE    1100 MB/s    1.5 h  (limited by NAS drives)

Going from 1 to 10 GbE turns an overnight job into a lunch break; 25 GbE barely helps because the NAS itself becomes the bottleneck. The efficiency figure is an assumption: measure it with a test copy of real data before promising a migration window.

Storage area network (SAN)

A storage area network (SAN) is a network dedicated to carrying block storage traffic between servers and storage arrays. The array presents volumes (LUNs, logical unit numbers) to specific servers; each server sees its LUNs as local disks and puts its own file system on them, just as with DAS — except the disks are in a shared, highly available array across the room.

Why build a separate network just for storage?

• Predictable latency. A database waiting for a block read cannot tolerate the queues of a busy user network. A SAN carries only storage traffic, and Fibre Channel is designed not to drop frames at all.
• Redundancy by design. SANs are built as two completely separate fabrics (A and B). Every server and every array connects to both, and multipathing software on the server uses whichever paths are up.
• Shared block storage. A virtualization cluster needs every host to see the same datastores, so a VM can be restarted or moved to any host. A SAN, together with a cluster file system such as VMFS or Cluster Shared Volumes, provides exactly that.

The protocols — Fibre Channel, iSCSI over Ethernet, and NVMe over Fabrics — together with zoning and multipathing are covered in SAN Protocols; what happens inside the array (LUNs, thin provisioning, snapshots) is in Storage Arrays in Practice.

DAS, NAS and SAN compared

Choosing in practice

Most data centers run all three side by side. A small regional energy supplier's own server room might look like this:

• SAN: an all-flash array with two controllers, reached over iSCSI on two separate 25 GbE storage switches, holds the datastores of the four-host virtualization cluster — including the billing database VMs.
• NAS: the same array (or a separate one) serves SMB shares for departments and an NFS export for the web servers' shared content.
• DAS: the backup server has a 24-bay JBOD shelf of large HDDs as its backup repository, deliberately outside the array it protects, so a failed array does not take the backups with it.

Hyperconverged infrastructure blurs these lines: each host's local drives (DAS) are pooled by software into shared storage that behaves like a SAN for the cluster. See Software-Defined Storage and Hyperconverged Infrastructure.

Common problems and first checks