Storage Area Network (SAN): What It Is and How It Works

What is a storage area network (SAN), and what does it do?

A storage area network (SAN) is a dedicated network that gives servers shared, block level access to centralized storage. Each server sees its slice of the shared pool as if it were a local disk. As a result, many servers can use one storage system, and the disk no longer lives inside a single machine.

SNIA, the vendor neutral storage industry association, defines a SAN in its online dictionary as a network whose primary purpose is moving data between computer systems and storage devices. In other words, a SAN does a different job from your office LAN. For example, the LAN carries email and web traffic. The SAN, however, carries only disk reads and writes.

In this guide we explain how SAN storage differs from NAS and DAS, which parts make up a SAN, which protocols it uses, and what it means for hosting. We are a digital marketing and web team, not a hosting company. So we keep the technical claims tied to primary sources such as SNIA, the IETF and Linux distribution documentation. Our goal is simple: help you read a hosting offer and ask the right questions.

What does block level storage actually mean?

A disk stores data in fixed size blocks. The operating system builds a file system on top of those blocks and keeps track of which file sits where. With block level access, the server asks the storage system for specific blocks at specific addresses. File names, folders and permissions are not part of that conversation.

File level access works differently. Here the server asks for a file by name, and the remote system manages the file system. A shared office folder is a typical example of this model. SNIA makes the same point: a SAN on its own does not provide the file abstraction, only block operations.

In practice, this distinction has real consequences. Block access suits workloads that need low latency and consistent writes, such as databases and virtual machine disks. That is because the operating system formats the disk directly and uses its own cache and file system. On the other hand, two servers writing to the same block device at once will corrupt data unless they use a cluster aware file system.

How is a SAN different from NAS and DAS?

All three are ways to give a server disk space. DAS (direct attached storage) connects the disk straight to one server. NAS (network attached storage) shares files over a regular network. A SAN shares blocks over a separate storage network. The table below also sums up the differences.

The most important row is the one about who manages the file system. With NAS, many clients can safely open the same files because the NAS handles locking and permissions. With a SAN, each volume usually belongs to one server, or to a group of servers that coordinate through cluster software. As a result, NAS fits shared folders, while a SAN fits virtual machine disks.

So the real question is not which one is better. Instead, ask which workload needs what. A small business website usually runs fine on DAS. However, when dozens of virtual machines share one pool, SAN storage adds a lot of flexibility.

What are the main components of a storage area network?

A storage area network has several layers that depend on each other. So if one layer is weak, the whole system slows down. The core components are:

• Storage array: A central system that groups many disks with RAID and adds controllers and cache.
• HBA or network adapter: The card that lets a server talk to the SAN. Fibre Channel uses an HBA, while iSCSI usually uses an Ethernet adapter.
• Switches: Network devices that route traffic between servers and the array, usually deployed in pairs.
• Cabling: Fiber optic or copper links. Good designs include two independent paths.
• Management software: The interface that carves up capacity, grants access and monitors health.

Notice also that every layer appears in pairs. This matters because a SAN failure hits every connected server at the same time. Therefore, serious deployments treat two switches, two adapters and two controllers as a baseline, not an upgrade.

If you want more detail on how the array arranges its disks, see our guide to RAID levels. Put simply, RAID protects the disks inside the array, and the SAN distributes that protected pool across the network.

How does Fibre Channel work?

Fibre Channel is a networking technology built for storage traffic, with its own cabling, switches and addressing rules. The T11 technical committee under INCITS develops its standards. Despite the name, it can run over copper. In data centers, though, you will mostly see fiber optic links.

Every port on a Fibre Channel network has a unique identifier called a WWN (World Wide Name). It plays a role similar to a MAC address on Ethernet. Switches then use these identifiers to decide which server may talk to which storage port.

The big strength of Fibre Channel is isolation. Storage traffic never shares a wire with web traffic, so a traffic spike on a web server does not directly slow disk access. That said, isolation has a price: separate adapters, separate switches and a team that knows the technology. Consequently, Fibre Channel is mostly a choice for large organizations and data centers.

Fibre Channel networks usually run as two independent fabrics, often called fabric A and fabric B. Specifically, you connect each server to both fabrics with separate adapters. Then, when one switch goes down for maintenance or fails, the other fabric keeps carrying traffic. This layout is the classic way to remove a single point of failure from a SAN design.

What is iSCSI, and why is it so common for SAN storage?

iSCSI is a protocol that carries SCSI disk commands over TCP/IP. The IETF document RFC 7143 describes it as a transport protocol for SCSI that works on top of TCP. In practice, this means you can build a SAN on standard Ethernet hardware.

iSCSI has two roles. The server that uses the disk is the initiator, and the system that provides the disk is the target. In addition, both sides carry a unique name, typically starting with iqn and based on a domain name. The target listens on TCP port 3260, the port registered for iSCSI with IANA.

iSCSI is popular because of cost and familiarity. You can start with the Ethernet skills and gear you already have. Still, a good iSCSI setup keeps storage traffic on its own VLAN or its own switches. Otherwise, a backup job or a sudden traffic burst can raise your database disk latency. We also recommend turning on authentication such as CHAP.

A few network details also matter. For example, use a consistent MTU on every adapter and switch that carries storage traffic, because a mismatch causes slowdowns that are hard to trace. In addition, try not to mix management traffic and storage traffic on the same adapter.

What about FCoE and newer transport options?

FCoE (Fibre Channel over Ethernet) places Fibre Channel frames directly inside Ethernet frames. You keep the Fibre Channel management model but run it on one Ethernet infrastructure. However, FCoE needs lossless Ethernet, so your switches must support Data Center Bridging features.

NVMe over Fabrics also gets a lot of attention. It carries the NVMe command set across a network and can run over TCP, RDMA or Fibre Channel. The NVM Express organization publishes the specification. In short, you can group the options like this:

• Fibre Channel: A separate, mature storage network with a higher upfront investment.
• iSCSI: Runs over Ethernet and TCP/IP, with a lower starting cost.
• FCoE: Fibre Channel logic on Ethernet cabling, but it requires a lossless network.
• NVMe over Fabrics: A newer path that aims to bring flash level latency across the network.

Real world speed depends on hardware generation and configuration, not on the protocol name alone. So when you compare offers, ask about the number of redundant paths and measured latency, not just the protocol.

What do LUN, zoning and masking mean?

A SAN array splits its large disk pool into smaller logical disks. Each one goes by the name a LUN, short for logical unit number. From the server side, a LUN looks like a freshly attached disk. The server then formats it and creates a file system on it.

So which server gets to see which LUN? Here, two layers of access control come into play:

• Zoning: Configured on the Fibre Channel switch. It decides which ports can see each other, so it works at the network level.
• LUN masking: Configured on the storage array. It decides which server can access which LUN.
• iSCSI access lists: On the iSCSI side, access depends on the initiator name and, optionally, CHAP authentication.

If one of these layers is wrong, two servers may each think a disk belongs to them. For instance, if two separate Linux servers mount the same LUN with a standard file system, they will overwrite each other. Therefore, SAN administration needs the same careful change discipline as network administration.

Why does multipathing matter?

Multipathing means a server reaches the same LUN through more than one physical path. Suppose the server has two adapters, the SAN has two switches and the array has two controllers. In that case, you may have four paths to the same disk. If a cable fails, traffic continues on the remaining paths.

On Linux, DM Multipath usually handles this job. According to Red Hat's DM Multipath documentation, multipathing aggregates the I/O paths and creates a new device made of those paths. The application sees one disk, and the lower layer handles path changes.

Without multipathing, the same LUN can appear as two or four separate disks. That opens the door to mistakes such as formatting the wrong device or using only one path. Therefore, multipath configuration belongs on the mandatory checklist for every SAN attached server.

What are the advantages of a storage area network?

The biggest benefit of a storage area network is that it separates the disk from the server. The disk no longer sits inside one machine; it lives in a central pool. That separation brings several advantages:

• Central management: You monitor, grow and assign capacity from one place.
• Flexible capacity: When a server runs out of space, you allocate more from the pool, often without touching hardware.
• Live migration: You move a virtual machine from one physical host to another while its disk stays put.
• Snapshots: You take array level snapshots and create a fast rollback point before an update.
• High availability: When a server fails, another server that sees the same disk takes over the workload.

In addition, many arrays offer replication, which copies data to a second array in another location. However, having a feature is not the same as configuring it well. When a hosting provider says it runs on a SAN, ask which of these benefits it actually uses.

What are the downsides and risks of SAN storage?

A SAN is powerful, but it does not fit every scenario. The first downside is cost. The array, redundant switches, adapters and licenses add up to a serious investment. On top of that, you need a team that understands storage networking.

The second downside is complexity. Zoning, LUN masking, multipathing and firmware compatibility rarely fit into a small team's daily routine. A single wrong change can affect every server that shares the pool, not just one.

The third risk comes from sharing. When one virtual machine on the array runs heavy disk operations, its neighbors may see higher latency. As a result, good providers set per machine disk limits. We explain how to measure disk performance in our guide to IOPS and disk performance. Finally, a SAN adds network latency to every disk access. Compared with a local NVMe drive, some workloads will notice that gap.

Why do virtualization clusters need shared storage?

In a virtualization cluster, several physical hosts run dozens or even hundreds of virtual machines together. If a virtual machine's disk sits inside one host, that disk becomes unreachable when the host fails. With shared storage, the disk sits in a common space that every host in the cluster can reach.

In practice, this setup makes two important things easier. The first is live migration: the hypervisor moves the virtual machine's memory to another host while the disk stays where it is. The second is high availability: when a host stops, the cluster restarts the virtual machine on another host.

Shared storage does not always mean a classic SAN. NFS based NAS, or distributed storage systems that pool local disks across servers, can meet the same need. If you want the basics of the hypervisor layer, our KVM virtualization guide is a good place to start.

Could your VPS disk live on a SAN?

Yes, it could. When you buy a VPS, its disk sits in one of three places: on the physical host's local drive, on network attached shared storage such as a SAN or NAS, or in a distributed storage cluster. Providers often do not state this clearly on the plan page.

Still, you can spot some clues. For example, if a provider can bring your VPS back on another host within minutes after a hardware failure, it likely uses shared storage. On the other hand, plans that highlight local NVMe usually keep the disk inside the physical host. In that case latency is lower, but moving the VPS after a hardware failure is harder.

To decide which model suits you, check the decision criteria in our VPS vs cloud server vs VDS comparison. If you want to see which provider and IP block your site sits on, try our IP lookup tool.

How does a SAN failure affect a website?

A well designed SAN tolerates the failure of a single component. However, a design gap or a fault that hits several components at once affects every server using the pool. As a result, SAN related problems rarely show up on one site alone. Instead, many sites on the same platform slow down together.

The symptoms rarely start with a full outage. First, disk latency rises, database queries take longer and page response times climb. Next, some requests time out. In the worst case, the operating system decides it lost the disk and remounts the file system read only. At that point the site cannot save new orders or form entries, so sales stop.

As a site owner, you cannot fix this yourself, but you can collect the right evidence. For instance, note when the problem started, which pages it affects and any error messages. Also check the provider's status page. Then you can hand support a measurable picture instead of a vague complaint, and the fix usually comes faster.

Where does an enterprise SAN project start?

If you run your own infrastructure, a SAN decision should start with workload analysis, not a hardware catalog. First, find out how much capacity, how many disk operations and how much latency tolerance each application needs. Then look for the simplest design that meets those needs.

In practice, the order usually looks like this:

1. Measure current disk usage, the read and write ratio, and peak hour disk operations on existing servers.
2. Agree on downtime tolerance with business owners and decide how long each system can stay down.
3. Choose the technology your team already knows. Strong Ethernet skills point to iSCSI, while an existing Fibre Channel investment deserves a fair look.
4. Build redundant paths, redundant controllers and a separate backup target into the design from day one.
5. Before going live, test path failure, controller failover and restore procedures.

This process prevents years of trouble from an oversized array or an undersized network. Also, budget for operating costs, not just the purchase. Support contracts, spare parts, license renewals and training time make up a large share of the total. We recommend comparing that total with a cloud provider's managed block storage as well.

Does a SAN replace RAID or backups?

No, SAN storage replaces neither RAID nor backups. RAID protects the disks inside the array against drive failure. The SAN then distributes that protected pool to servers over the network. In short, the two work at different layers and complement each other.

Backups answer a different question altogether. A dropped table, ransomware or a bad update affects the data on the SAN immediately, because the SAN faithfully stores every change you make. Snapshots help here, but as long as they live on the same array, they will not save you if the array itself fails.

A solid plan therefore combines three layers:

• RAID on the array to survive drive failures.
• Snapshots for short term, fast rollback points.
• Backups on a different system, ideally in a different location, with tested restores.

For the backup side, read our website backup strategy guide.

How do you attach an iSCSI disk on a Linux server?

Here is a short example for readers who manage their own servers. The steps follow Red Hat's iSCSI initiator documentation and apply to RHEL family distributions. The IP address and name in the example are documentation values only.

# Install the initiator package (RHEL family)
dnf install iscsi-initiator-utils

# Show the server's iSCSI initiator name
cat /etc/iscsi/initiatorname.iscsi

# Discover targets on the storage system
iscsiadm -m discovery -t st -p 192.0.2.10

# Log in to the discovered target
iscsiadm -m node -T iqn.2005-01.com.example:store1 -l

# List the new block device
lsblk

# If you use multipathing, check the paths
multipath -ll

Before you run these commands, keep the following in mind:

1. The storage side must allow access for your server's initiator name.
2. Check the lsblk output twice before you format anything. After all, you cannot undo formatting the wrong disk, so slow down here.
3. If several paths exist, use the multipath device, not a single path.
4. Debian and Ubuntu use different package and service names, so follow your distribution's own documentation.

When should you leave this to your hosting provider?

To be honest, building or running a SAN is the wrong job for most website owners. If you use shared hosting, a managed VPS or a cloud server, the storage layer is already your provider's responsibility. Your job is to ask how that layer works and to measure the results.

We recommend leaving it to the provider in these cases:

• Nobody on your team has hands on experience with Fibre Channel, iSCSI and multipathing.
• Your workload fits on one server and you do not truly need a high availability cluster.
• You cannot set aside a separate budget and support contract for storage hardware.
• You have no on call routine that can respond within hours when something breaks.

Building your own SAN mostly makes sense for organizations that run their own data center or virtualization cluster. To weigh the cost side, our article on what drives server hosting cost gives you a useful frame.

What does SAN storage mean in practice for a website owner?

As a website owner, you never deal with SAN storage directly, but you feel its effects every day. For instance, when a page loads, database queries hit the disk. Whether that disk is local or remote, and how busy it is, shapes how fast the query returns.

For example, on an online store during a sale, traffic jumps and the order table takes frequent writes. If the storage layer struggles, pages slow down and checkout drags. To diagnose a slow site, follow the order in our article on server side causes of a slow website.

On the other hand, a SAN can also cut downtime. If a host fails and your virtual machine restarts elsewhere within moments, visitors may barely notice. In our web design and ecommerce consulting projects, we judge infrastructure choices on exactly these two points: speed and continuity.

Which storage questions should you ask a hosting provider?

Hosting offers usually highlight disk size and labels like SSD or NVMe. To understand storage quality, though, you need to ask a few more questions:

1. Does my virtual machine's disk sit on a local drive or on network attached shared storage?
2. Does the storage layer have redundant paths and redundant controllers?
3. Do you apply per machine limits on disk operations or bandwidth?
4. If a physical host fails, does my virtual machine restart on another host automatically?
5. Do snapshots and backups live on the same array or on a separate system?
6. How long does a restore take, and when did you last test one?

Put simply, the answers reveal the real difference between two plans with similar prices. To understand how disk and network interact, see our hosting bandwidth guide. For broader selection criteria, our guide to choosing web hosting gives you a checklist.

Who is a storage area network the right choice for?

A storage area network separates disks from servers and delivers central management, live migration and high availability. For that reason, it suits virtualization clusters, large databases and business systems with little tolerance for downtime. However, its cost, complexity and need for specialist skills make it overkill for small projects.

If you own a website or an online store, the right question is not whether to build a SAN. Instead, ask how your provider designs its storage layer. Ask the questions above, get the answers in writing and measure your site's real performance. That way you decide with a clear view of where your data lives and how it is protected, not just a label like SSD.