SAN vs NAS: Choosing Storage for Your Server Infrastructure

Two servers needing the same data does not mean they should share a disk. SAN vs NAS is about access: NAS shares files; SAN presents a block device. NAS is usually more straightforward for shared files, while SAN may suit applications that manage their own filesystem. Performance and availability need separate validation.

Two Servers Need the Same Data: A Disk or a File Share?

A document visible on app01.example but missing from app02.example suggests shared file access. An application expecting a dedicated disk needs a different model. Start there. I would base the SAN vs NAS decision on application requirements, not terabytes.

In this hypothetical lab, storage.example (192.0.2.10) serves app01.example (192.0.2.21) and app02.example (192.0.2.22). All run Ubuntu Server 24.04 LTS with the GA 6.8 kernel series. Documentation-reserved .example names and 192.0.2.0/24 addresses stay inside the lab, without external routing. These are planning examples, not completed deployments or measured results.

First requirement: both clients read and write user documents in a shared directory. IETF RFC 8881 specifies NFSv4.1 file access and locking. The NAS example uses nfs-kernel-server and nfs-common for NFSv4.1/TCP; clients access the server’s /srv/nfs/shared at /mnt/nas. Both see the files, but concurrent edits need verification: protocol-level locking does not guarantee correct application use.

The second requirement gives only app01.example dedicated block storage. IETF RFC 7143 specifies iSCSI transport of SCSI commands over TCP. Using Linux LIO, targetcli-fb and open-iscsi, this iSCSI/TCP example presents a LUN, not a file share. This LUN is not intended for simultaneous writes from both clients. Suitability depends on application support for a client-managed filesystem on that block device.

Before choosing a protocol, I would document supported storage: shared directory or specific filesystem? For concurrent writers, check locking, caching and retries after failures. Include existing data, growth, temporary files and separately stored backup capacity; avoid a universal multiplier.

Each VM gets 2 vCPUs and 4 GiB RAM-example allocations, not product minimums. The storage VM has two empty 40 GiB disks separate from its OS disk: /dev/vdb exclusively for NAS, /dev/vdc exclusively for the iSCSI LUN. Verify device identities with lsblk before changes. Two clients do not make one storage server redundant. Write down, in minutes, how long your application can tolerate storage.example being unavailable.

SAN vs NAS Starts with Who Manages the Filesystem

A directory on your client does not mean it manages the filesystem. Files under /mnt/nas can live on ext4 managed elsewhere. NAS offers file access; SAN offers block storage that can hold a filesystem. I draw the SAN vs NAS boundary there, not around the enclosure. Ownership matters.

This hypothetical lab uses Ubuntu Server 24.04 LTS with the GA 6.8 kernel series. For NAS, storage.example manages ext4 on the dedicated 40 GiB /dev/vdb disk, sharing /srv/nfs/shared. Both app01.example and app02.example mount it at /mnt/nas; neither directly manages the underlying disk blocks.

IETF RFC 8881 describes NFSv4.1 filehandles and operations including OPEN, READ and WRITE. Here, nfs-kernel-server and nfs-common provide NFSv4.1/TCP. Clients request file operations; the server handles them through its filesystem. SMB file sharing belongs in the same file-access category, but uses a different protocol. A local mount point changes neither model.

With iSCSI, filesystem responsibility moves to app01.example. The storage server, storage.example, exposes the separate 40 GiB /dev/vdc disk as a raw block device through Linux LIO and targetcli-fb. Using open-iscsi, the client accesses the LUN, creates ext4 and manages it. The storage server does not mount ext4 on that LUN.

According to IETF RFC 7143, iSCSI carries SCSI commands over TCP: block-device requests, not requests to open remote files. Fibre Channel can also provide SCSI-based block access in SAN environments. SAN is not exclusively Fibre Channel or a particular appliance type. iSCSI/TCP provides another option.

The Linux kernel’s ext4 documentation describes on-disk structures such as block groups and inode tables. Here, storage.example manages them for NAS; app01.example manages them for iSCSI. Presenting that LUN to another client does not make concurrent ext4 mounts safe. Block access is not safe file sharing.

One storage system can offer NFS or SMB shares alongside iSCSI LUNs; two access models need not require two devices. On your diagram, label each storage area with the machine managing its filesystem.

The NAS Path: Exposing an NFS Share to Two Clients

You can share files without attaching one disk to two servers. In this hypothetical lab, storage.example (192.0.2.10) manages ext4; app01.example (192.0.2.21) and app02.example (192.0.2.22) are NFS clients. All run Ubuntu Server 24.04 LTS, GA kernel series 6.8. Each VM gets 2 vCPU and 4 GiB RAM-example allocations, not minimum requirements. Documentation-reserved .example and 192.0.2.0/24 stay inside this externally unrouted lab.

The storage server has two empty 40 GiB disks, separate from its OS disk: /dev/vdb exclusively for NAS, /dev/vdc for iSCSI. Check first. The subsequent mkfs.ext4 destroys data on its target.

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL

I would confirm ownership next: map UID/GID 2000:2000 to the intended accounts across all three machines, ruling out conflicts. Record exact package revisions with dpkg-query.

sudo apt update
sudo apt install nfs-kernel-server
dpkg-query -W -f='${Package}\t${Version}\n' nfs-kernel-server | tee nas-server-packages.txt
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /srv/nfs/shared
sudo mount /dev/vdb /srv/nfs/shared
sudo chown 2000:2000 /srv/nfs/shared
sudo chmod 2770 /srv/nfs/shared
sudo mkdir -p /etc/exports.d
sudo tee /etc/exports.d/shared.exports >/dev/null <<'EOF'
/srv/nfs/shared 192.0.2.21(rw,sync,root_squash,sec=sys) 192.0.2.22(rw,sync,root_squash,sec=sys)
EOF
sudo systemctl enable --now nfs-server
sudo exportfs -rav
sudo exportfs -v

exportfs -rav applies the exports; exportfs -v should list both addresses and configured options, possibly with additional defaults. Check other exports for broader access. rw does not override permissions: 2770 excludes other users and gives new files the directory’s group. Application umask also affects group writability.

On both clients, explicitly select NFSv4.1 with vers=4.1, preventing version fallback, and TCP with proto=tcp:

sudo apt update
sudo apt install nfs-common
dpkg-query -W -f='${Package}\t${Version}\n' nfs-common | tee nas-client-packages.txt
sudo mkdir -p /mnt/nas
sudo mount -t nfs -o vers=4.1,proto=tcp,sec=sys 192.0.2.10:/srv/nfs/shared /mnt/nas
findmnt -T /mnt/nas -o TARGET,SOURCE,FSTYPE,OPTIONS

Expect findmnt to report target /mnt/nas, source 192.0.2.10:/srv/nfs/shared, type nfs4, and options vers=4.1 and proto=tcp. These are verification criteria, not observed results.

IETF RFC 8881 describes AUTH_SYS’s trust in client-supplied numeric UID/GID values; matching usernames is insufficient. root_squash maps client root to an anonymous identity but cannot strongly authenticate against a client administrator. NFSv4.1 alone does not guarantee encryption; sec=sys leaves traffic unencrypted. Allow TCP 2049 only from these two clients; block other sources.

For persistent operation, configure UUID-based disk mounting and make the NFS service depend on that mount. Otherwise, a missing disk can leave you exporting the empty directory underneath.

SAN with iSCSI: The LUN Appears, the Client Creates the Filesystem

A disk is not a shared folder. RFC 7143 defines iSCSI transport of SCSI commands over TCP. In this hypothetical lab, storage.example exposes raw /dev/vdc only to app01.example; the client creates the filesystem. NAS disk /dev/vdb stays untouched.

On Ubuntu Server 24.04 LTS, GA kernel series 6.8, prepare the initiator. This IQN assignment is for a fresh lab only; never change it with existing sessions. Record package revisions with dpkg-query. The file’s IQN must match the target ACL exactly.

# app01.example - yeni laboratuvar kurulumu
sudo apt-get update
sudo apt-get install -y open-iscsi
dpkg-query -W -f='${Package}\t${Version}\n' open-iscsi
printf '%s\n' 'InitiatorName=iqn.2026-10.example:app01' | sudo tee /etc/iscsi/initiatorname.iscsi
sudo cat /etc/iscsi/initiatorname.iscsi
sudo systemctl restart iscsid

I would verify storage disk /dev/vdc against the VM disk mapping, not just its expected 40 GiB size. Stop if lsblk shows partitions, filesystems or mountpoints. wipefs --no-act lists signatures without changing them; silence does not prove emptiness.

# storage.example
sudo apt-get update
sudo apt-get install -y targetcli-fb
dpkg-query -W -f='${Package}\t${Version}\n' targetcli-fb
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo wipefs --no-act /dev/vdc

Before creating the portal, allow TCP 3260 only from 192.0.2.21 through the firewall; block other sources. CHAP is disabled in this externally unrouted lab. IQNs are spoofable: ACLs are not cryptographic authentication. RFC 7143’s CHAP authenticates but does not encrypt traffic. Plan production network isolation and, where needed, IPsec.

LIO exposes the unformatted disk as LUN 0. Automatic ACL generation and LUN mapping are disabled; access is explicitly mapped to one initiator. Expect targetcli ls to show /dev/vdc, portal 192.0.2.10:3260 and that mapping. Save configuration to the specified JSON file.

# storage.example - disk kimliği doğrulandıktan sonra
sudo targetcli set global auto_add_default_portal=false auto_add_mapped_luns=false
sudo targetcli /backstores/block create name=app01_lun dev=/dev/vdc
sudo targetcli /iscsi create iqn.2026-10.example:storage.shared
sudo targetcli /iscsi/iqn.2026-10.example:storage.shared/tpg1 set attribute generate_node_acls=0 authentication=0 prod_mode_write_protect=0
sudo targetcli /iscsi/iqn.2026-10.example:storage.shared/tpg1/portals create 192.0.2.10 3260
sudo targetcli /iscsi/iqn.2026-10.example:storage.shared/tpg1/luns create /backstores/block/app01_lun lun=0
sudo targetcli /iscsi/iqn.2026-10.example:storage.shared/tpg1/acls create iqn.2026-10.example:app01
sudo targetcli /iscsi/iqn.2026-10.example:storage.shared/tpg1/acls/iqn.2026-10.example:app01 create mapped_lun=0 tpg_lun=0
sudo targetcli saveconfig /etc/rtslib-fb-target/saveconfig.json
sudo targetcli ls

Discovery should return the target IQN; session details should identify the attached SCSI disk. Verify that the stable /dev/disk/by-path/ link resolves to that disk and check its 40 GiB capacity. Stop for unexpected devices or signatures.

# app01.example
sudo iscsiadm -m discovery -t sendtargets -p 192.0.2.10:3260
sudo iscsiadm -m node -T iqn.2026-10.example:storage.shared -p 192.0.2.10:3260 --login
sudo udevadm settle
sudo iscsiadm -m session -P 3
LUN=/dev/disk/by-path/ip-192.0.2.10:3260-iscsi-iqn.2026-10.example:storage.shared-lun-0
readlink -f "$LUN"
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN "$LUN"
sudo wipefs --no-act "$LUN"

Formatting destroys data. Proceed only after verifying identity and emptiness. After mounting, the client manages files under /mnt/san.

# app01.example - kimlik ve boşluk doğrulamasından sonra
sudo mkfs.ext4 /dev/disk/by-path/ip-192.0.2.10:3260-iscsi-iqn.2026-10.example:storage.shared-lun-0
sudo mkdir -p /mnt/san
sudo mount /dev/disk/by-path/ip-192.0.2.10:3260-iscsi-iqn.2026-10.example:storage.shared-lun-0 /mnt/san

The journal described in Linux’s ext4 documentation does not coordinate writes between clients. Mounting the same ext4 LUN writable on two clients simultaneously can corrupt data. Do not add an ACL for app02.example; keep shared file access on NAS.

Workload Matters More Than the Protocol Name in Performance Comparisons

Fast large-file copies tell you little about opening thousands of small files. IETF RFC 8881 specifies NFSv4.1 file and directory operations; RFC 7143 specifies SCSI transport over iSCSI. Neither ranks speed. I would separate random I/O, sequential transfers, and metadata workloads before comparing SAN vs NAS.

Use app01.example: Ubuntu Server 24.04 LTS, GA kernel series 6.8, in this hypothetical lab. Prepared mounts are /mnt/nas, the NFSv4.1/TCP share from storage.example, and /mnt/san, ext4 on the iSCSI/TCP LUN. Never mount that ext4 LUN simultaneously on app02.example. This script checks mounts, not storage setup; it writes only disposable files it creates. Your user needs write access to both directories.

The Bash example fills each target’s 2 GiB file before running 4 KiB random reads, 1 MiB sequential reads, and 4 KiB random writes with fsync after every write. Each profile runs for 60 seconds: one job, queue depth 1. Synchronous psync cannot measure highly parallel capacity. dpkg-query records package revisions.

set -eu
sudo apt-get update
sudo apt-get install -y fio

out=$(mktemp -d "$HOME/fio-results.XXXXXX")
uname -r > "$out/kernel.txt"
dpkg-query -W -f='${Package}\t${Version}\n' \
  fio nfs-common open-iscsi > "$out/packages.txt"

for base in /mnt/nas /mnt/san; do
  mountpoint -q "$base"
  test -w "$base"
  findmnt -T "$base" -o TARGET,SOURCE,FSTYPE,OPTIONS \
    >> "$out/mounts.txt"
done

for base in /mnt/nas /mnt/san; do
  label=${base##*/}
  work=$(mktemp -d "$base/fio-work.XXXXXX")
  file="$work/test.bin"

  fio --name=prepare --filename="$file" --size=2G \
    --rw=write --bs=1M --ioengine=psync --iodepth=1 \
    --numjobs=1 --direct=1 --end_fsync=1 \
    --output-format=json --output="$out/$label-prepare.json"

  for profile in random-read sequential-read sync-write; do
    case "$profile" in
      random-read) rw=randread; bs=4k; sync_every=0 ;;
      sequential-read) rw=read; bs=1M; sync_every=0 ;;
      sync-write) rw=randwrite; bs=4k; sync_every=1 ;;
    esac

    fio --name="$profile" --filename="$file" --size=2G \
      --rw="$rw" --bs="$bs" --ioengine=psync --iodepth=1 \
      --numjobs=1 --direct=1 --fsync="$sync_every" \
      --time_based=1 --runtime=60 --randrepeat=1 \
      --lat_percentiles=1 --percentile_list=50:95:99 \
      --output-format=json --output="$out/$label-$profile.json"
  done

  rm -- "$file"
  rmdir -- "$work"
done
printf 'Rapor dizini: %s\n' "$out"

On success, the final line prints the report directory containing JSON results and kernel, package, and mount records. These are instructions, not measured results. Compare IOPS, MiB/s (bw_bytes / 1048576), and p50/p95/p99 latencies together. Write and fsync latencies are separate: write percentiles alone do not represent durability waits. Adding separate percentiles does not produce an operation percentile.

Metadata needs another experiment. Single-file profiles miss creation, stat, directory listing, and deletion costs; fix file count, directory distribution, and concurrency separately.

direct=1 does not remove every cache. Each VM’s 2 vCPU and 4 GiB RAM are example allocations, not minimum requirements; 2 GiB may fit in storage cache. Record cache state, shared physical disk effects, virtual networking, and concurrent loads. I would correlate CPU utilization and disk waits with test times using Prometheus and Grafana. Repeat in reverse order; keep these lab results separate from claims about enterprise SAN/NAS products.

Failures, Access Control and Backups: What the Protocol Does Not Solve

A protocol cannot keep a failed storage server available. In this hypothetical Ubuntu Server 24.04 LTS, GA 6.8 lab, storage.example (192.0.2.10) and the single network path are single points of failure for NFSv4.1/TCP and iSCSI/TCP-even while app01.example and app02.example remain running. iSCSI multipath needs genuinely independent paths, not two connections through one virtual switch. It supplies neither server nor controller redundancy alone.

Two disks are not redundancy. Here, /dev/vdb serves NAS and /dev/vdc the iSCSI LUN; no RAID exists. RAID tolerates certain disk failures depending on level, not accidental deletion. Snapshots support rollback; independent backups survive source-storage loss. As What Is a VPS Snapshot? explains, same-storage snapshots are not independent backups. Journaling in the Linux ext4 documentation is not file backup either. High availability requires failover, data consistency and fencing against failed-node writes.

A hypothetical 15-minute RPO sets acceptable data loss; a 30-minute RTO sets the restoration target. Daily-only backups miss that RPO. These targets shape copy frequency, independent-copy locations and standby infrastructure. Recovery includes server preparation and application validation.

I keep authorization separate. RFC 8881 describes NFSv4.1 security; sec=sys trusts client-supplied UID/GID values. root_squash cannot replace strong authentication. RFC 7143 describes CHAP authentication for iSCSI, not traffic encryption. LUN authorization differs from file permissions; ordinary ext4 cannot safely support simultaneous writes from two clients to one LUN.

# app01.example üzerinde durumu değiştirmeyen kontroller
findmnt --mountpoint /mnt/nas --output TARGET,SOURCE,FSTYPE,OPTIONS
sudo iscsiadm -m session -P 3
sudo journalctl -u iscsid.service --since '15 minutes ago' --no-pager
sudo journalctl -k --since '15 minutes ago' --no-pager

These read-only checks remain unperformed. With NAS mounted, expect /mnt/nas, nfs4 and vers=4.1 from findmnt. iscsiadm reports session targets, portals and states, or no sessions. journalctl shows service and kernel logs for connection troubleshooting. Silence proves nothing.

I would restrict the planned, unperformed disconnection and restoration checks to this externally unrouted lab. Prepare console access; observe application behavior during interruption and storage access after reconnection. Restore a sample file from an independent backup into another directory. Verify contents and permissions, then compare total recovery time with the RTO.

Choosing for Your Workload: File Shares, VM Disks or Application Data

Two applications sharing files do not necessarily need the same block device. That distinction matters. I frame SAN vs NAS around access responsibility: IETF RFC 8881 defines NFSv4.1 file access; RFC 7143 defines iSCSI transport of SCSI commands over TCP.

NFS is not limited to documents: supported virtualization and database deployments can use it too. Protocol standards do not establish product support; check version-specific storage requirements for QEMU 8.2/KVM from Ubuntu’s repositories or your database. iSCSI guarantees neither speed nor high availability. One storage server remains one storage server.

In the hypothetical Ubuntu Server 24.04 LTS lab with GA kernel series 6.8, I would choose NAS for shared application files. On storage.example, /dev/vdb holds ext4 at /srv/nfs/shared, shared over NFSv4.1/TCP and mounted at /mnt/nas on app01.example and app02.example. The server manages the filesystem; applications writing the same file still need coordination.

For app01.example to manage its own filesystem, I would choose a dedicated iSCSI/TCP LUN backed by raw /dev/vdc through Linux LIO. The Linux kernel’s ext4 documentation describes filesystem features, not shared-disk clustering: ext4 is not a cluster filesystem. Never mount this LUN’s ext4 filesystem writable on both clients simultaneously.

I would require access, performance and restore acceptance tests with your target application. Monitoring a VPS with Prometheus and Grafana can reveal resource pressure; measure application latency separately. Before production, verify concurrent-access correctness, your predefined latency target and consistent recovery from backup.

Choosing for Your Workload: File Shares, VM Disks or Application Data

• Determine whether your application needs shared file access or a block device it will manage itself.
• Verify your application and virtualization platform's NFS or iSCSI support in their official documentation.
• Record numerical targets for capacity, growth, latency, RPO and RTO.
• Verify devices with lsblk before disk operations, and confirm the LUN's stable device path after iSCSI discovery.
• Check UID/GID consistency and file permissions for NFS, review initiator ACLs and CHAP settings for iSCSI, and restrict network access.
• Plan equivalent performance tests using only disposable files, and record cache and network conditions.
• Validate connection-loss behavior and restoration from an independent backup in the lab before going into production.

Frequently Asked Questions

Sources

• IETF RFC 8881 – NFSv4.1 Protocol — rfc-editor.org
• IETF RFC 7143 – iSCSI Protocol — rfc-editor.org
• Linux Kernel Documentation – ext4 Filesystem — docs.kernel.org