{"id":1085,"date":"2026-10-31T15:53:20","date_gmt":"2026-10-31T15:53:20","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=1085"},"modified":"2026-10-31T15:46:04","modified_gmt":"2026-10-31T15:46:04","slug":"san-vs-nas","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/san-vs-nas\/","title":{"rendered":"SAN vs NAS: Choosing Storage for Your Server Infrastructure"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; SAN vs NAS<\/p>\n<p>NAS provides file shares to clients; SAN provides block storage. Your choice depends on how the application accesses data and how you will operate the infrastructure, not the device&#039;s name.<\/p>\n<ul>\n<li><strong>File access<\/strong> \u2014 With NAS, the storage server manages the filesystem, and clients access files through NFS or SMB.<\/li>\n<li><strong>Block access<\/strong> \u2014 With SAN, the client or cluster layer manages the filesystem on block storage presented through iSCSI or Fibre Channel.<\/li>\n<li><strong>Shared writes<\/strong> \u2014 Mounting the same ext4 LUN read-write on two clients simultaneously is unsafe; shared files require NAS or an appropriate cluster architecture.<\/li>\n<li><strong>Performance criteria<\/strong> \u2014 Compare IOPS, MiB\/s and latency percentiles under the same workload; the protocol name alone does not determine which option is faster.<\/li>\n<li><strong>Access security<\/strong> \u2014 In this example, restrict access to TCP 2049 for NFSv4.1 and TCP 3260 for iSCSI; AUTH_SYS and CHAP do not encrypt traffic.<\/li>\n<li><strong>Failure planning<\/strong> \u2014 Both models require separate planning for independent backups, restore rehearsals and redundancy that meets your RPO and RTO targets.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">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.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 17 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#two-servers-need-the-same-data-a-disk-or-a-file-share\">Two Servers Need the Same Data: A Disk or a File Share?<\/a><\/li>\n<li><a href=\"#san-vs-nas-starts-with-who-manages-the-filesystem\">SAN vs NAS Starts with Who Manages the Filesystem<\/a><\/li>\n<li><a href=\"#the-nas-path-exposing-an-nfs-share-to-two-clients\">The NAS Path: Exposing an NFS Share to Two Clients<\/a><\/li>\n<li><a href=\"#san-with-iscsi-the-lun-appears-the-client-creates-the-filesystem\">SAN with iSCSI: The LUN Appears, the Client Creates the Filesystem<\/a><\/li>\n<li><a href=\"#workload-matters-more-than-the-protocol-name-in-performance-comparisons\">Workload Matters More Than the Protocol Name in Performance Comparisons<\/a><\/li>\n<li><a href=\"#failures-access-control-and-backups-what-the-protocol-does-not-solve\">Failures, Access Control and Backups: What the Protocol Does Not Solve<\/a><\/li>\n<li><a href=\"#choosing-for-your-workload-file-shares-vm-disks-or-application-data\">Choosing for Your Workload: File Shares, VM Disks or Application Data<\/a><\/li>\n<li><a href=\"#choosing-for-your-workload-file-shares-vm-disks-or-application-data-2\">Choosing for Your Workload: File Shares, VM Disks or Application Data<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<li><a href=\"#sources\">Sources<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"two-servers-need-the-same-data-a-disk-or-a-file-share\">Two Servers Need the Same Data: A Disk or a File Share?<\/h2>\n<p>A document visible on <code>app01.example<\/code> but missing from <code>app02.example<\/code> suggests shared file access. An application expecting a dedicated disk needs a different model. Start there. I would base the <strong>SAN vs NAS<\/strong> decision on application requirements, not terabytes.<\/p>\n<p>In this hypothetical lab, <code>storage.example<\/code> (192.0.2.10) serves <code>app01.example<\/code> (192.0.2.21) and <code>app02.example<\/code> (192.0.2.22). All run Ubuntu Server 24.04 LTS with the GA 6.8 kernel series. Documentation-reserved <code>.example<\/code> names and <code>192.0.2.0\/24<\/code> addresses stay inside the lab, without external routing. These are planning examples, not completed deployments or measured results.<\/p>\n<p>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 <code>nfs-kernel-server<\/code> and <code>nfs-common<\/code> for NFSv4.1\/TCP; clients access the server&#8217;s <code>\/srv\/nfs\/shared<\/code> at <code>\/mnt\/nas<\/code>. Both see the files, but concurrent edits need verification: protocol-level locking does not guarantee correct application use.<\/p>\n<p>The second requirement gives only <code>app01.example<\/code> dedicated block storage. IETF RFC 7143 specifies iSCSI transport of SCSI commands over TCP. Using Linux LIO, <code>targetcli-fb<\/code> and <code>open-iscsi<\/code>, this iSCSI\/TCP example presents a LUN, not a file share. <strong>This LUN is not intended for simultaneous writes from both clients.<\/strong> Suitability depends on application support for a client-managed filesystem on that block device.<\/p>\n<p>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.<\/p>\n<p>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: <code>\/dev\/vdb<\/code> exclusively for NAS, <code>\/dev\/vdc<\/code> exclusively for the iSCSI LUN. Verify device identities with <code>lsblk<\/code> before changes. Two clients do not make one storage server redundant. Write down, in minutes, how long your application can tolerate <code>storage.example<\/code> being unavailable.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>In the hypothetical Ubuntu Server 24.04 LTS lab, app01.example and app02.example will access shared files through NFSv4.1; only app01.example will use the iSCSI LUN. This is a deployment plan, not a completed test or customer experience. The .example names and 192.0.2.0\/24 addresses are reserved for documentation; here, they represent only a lab with no routing to external networks.<\/p>\n<\/div>\n<h2 id=\"san-vs-nas-starts-with-who-manages-the-filesystem\">SAN vs NAS Starts with Who Manages the Filesystem<\/h2>\n<p>A directory on your client does not mean it manages the filesystem. Files under <code>\/mnt\/nas<\/code> 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.<\/p>\n<p>This hypothetical lab uses Ubuntu Server 24.04 LTS with the GA 6.8 kernel series. For NAS, <code>storage.example<\/code> manages ext4 on the dedicated 40 GiB <code>\/dev\/vdb<\/code> disk, sharing <code>\/srv\/nfs\/shared<\/code>. Both <code>app01.example<\/code> and <code>app02.example<\/code> mount it at <code>\/mnt\/nas<\/code>; neither directly manages the underlying disk blocks.<\/p>\n<p>IETF RFC 8881 describes NFSv4.1 filehandles and operations including <code>OPEN<\/code>, <code>READ<\/code> and <code>WRITE<\/code>. Here, <code>nfs-kernel-server<\/code> and <code>nfs-common<\/code> provide NFSv4.1\/TCP. Clients request file operations; the server handles them through its filesystem. <a href=\"https:\/\/www.vps.tc\/blog\/en\/how-to-set-up-smb-file-sharing-on-windows-server\/\">SMB file sharing<\/a> belongs in the same file-access category, but uses a different protocol. A local mount point changes neither model.<\/p>\n<p>With iSCSI, filesystem responsibility moves to <code>app01.example<\/code>. The storage server, <code>storage.example<\/code>, exposes the separate 40 GiB <code>\/dev\/vdc<\/code> disk as a raw block device through Linux LIO and <code>targetcli-fb<\/code>. Using <code>open-iscsi<\/code>, the client accesses the LUN, creates ext4 and manages it. The storage server does not mount ext4 on that LUN.<\/p>\n<p>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. <strong>SAN is not exclusively Fibre Channel or a particular appliance type.<\/strong> iSCSI\/TCP provides another option.<\/p>\n<p>The Linux kernel&#8217;s ext4 documentation describes on-disk structures such as block groups and inode tables. Here, <code>storage.example<\/code> manages them for NAS; <code>app01.example<\/code> manages them for iSCSI. Presenting that LUN to another client does not make concurrent ext4 mounts safe. Block access is not safe file sharing.<\/p>\n<p>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.<\/p>\n<h2 id=\"the-nas-path-exposing-an-nfs-share-to-two-clients\">The NAS Path: Exposing an NFS Share to Two Clients<\/h2>\n<p>You can share files without attaching one disk to two servers. In this hypothetical lab, <code>storage.example<\/code> (<code>192.0.2.10<\/code>) manages ext4; <code>app01.example<\/code> (<code>192.0.2.21<\/code>) and <code>app02.example<\/code> (<code>192.0.2.22<\/code>) 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 <code>.example<\/code> and <code>192.0.2.0\/24<\/code> stay inside this externally unrouted lab.<\/p>\n<p>The storage server has two empty 40 GiB disks, separate from its OS disk: <code>\/dev\/vdb<\/code> exclusively for NAS, <code>\/dev\/vdc<\/code> for iSCSI. Check first. The subsequent <code>mkfs.ext4<\/code> destroys data on its target.<\/p>\n<pre><code>lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL<\/code><\/pre>\n<p>I would confirm ownership next: map UID\/GID <code>2000:2000<\/code> to the intended accounts across all three machines, ruling out conflicts. Record exact package revisions with <code>dpkg-query<\/code>.<\/p>\n<pre><code>sudo apt update\nsudo apt install nfs-kernel-server\ndpkg-query -W -f='${Package}\\t${Version}\\n' nfs-kernel-server | tee nas-server-packages.txt\nsudo mkfs.ext4 \/dev\/vdb\nsudo mkdir -p \/srv\/nfs\/shared\nsudo mount \/dev\/vdb \/srv\/nfs\/shared\nsudo chown 2000:2000 \/srv\/nfs\/shared\nsudo chmod 2770 \/srv\/nfs\/shared\nsudo mkdir -p \/etc\/exports.d\nsudo tee \/etc\/exports.d\/shared.exports &gt;\/dev\/null &lt;&lt;'EOF'\n\/srv\/nfs\/shared 192.0.2.21(rw,sync,root_squash,sec=sys) 192.0.2.22(rw,sync,root_squash,sec=sys)\nEOF\nsudo systemctl enable --now nfs-server\nsudo exportfs -rav\nsudo exportfs -v<\/code><\/pre>\n<p><code>exportfs -rav<\/code> applies the exports; <code>exportfs -v<\/code> should list both addresses and configured options, possibly with additional defaults. Check other exports for broader access. <code>rw<\/code> does not override permissions: <code>2770<\/code> excludes other users and gives new files the directory&#8217;s group. Application umask also affects group writability.<\/p>\n<p>On both clients, explicitly select NFSv4.1 with <code>vers=4.1<\/code>, preventing version fallback, and TCP with <code>proto=tcp<\/code>:<\/p>\n<pre><code>sudo apt update\nsudo apt install nfs-common\ndpkg-query -W -f='${Package}\\t${Version}\\n' nfs-common | tee nas-client-packages.txt\nsudo mkdir -p \/mnt\/nas\nsudo mount -t nfs -o vers=4.1,proto=tcp,sec=sys 192.0.2.10:\/srv\/nfs\/shared \/mnt\/nas\nfindmnt -T \/mnt\/nas -o TARGET,SOURCE,FSTYPE,OPTIONS<\/code><\/pre>\n<p>Expect <code>findmnt<\/code> to report target <code>\/mnt\/nas<\/code>, source <code>192.0.2.10:\/srv\/nfs\/shared<\/code>, type <code>nfs4<\/code>, and options <code>vers=4.1<\/code> and <code>proto=tcp<\/code>. These are verification criteria, not observed results.<\/p>\n<p>IETF RFC 8881 describes AUTH_SYS&#8217;s trust in client-supplied numeric UID\/GID values; matching usernames is insufficient. <code>root_squash<\/code> maps client root to an anonymous identity but cannot strongly authenticate against a client administrator. NFSv4.1 alone does not guarantee encryption; <code>sec=sys<\/code> leaves traffic unencrypted. Allow TCP 2049 only from these two clients; block other sources.<\/p>\n<p>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.<\/p>\n<h2 id=\"san-with-iscsi-the-lun-appears-the-client-creates-the-filesystem\">SAN with iSCSI: The LUN Appears, the Client Creates the Filesystem<\/h2>\n<p>A disk is not a shared folder. RFC 7143 defines iSCSI transport of SCSI commands over TCP. In this hypothetical lab, <code>storage.example<\/code> exposes raw <code>\/dev\/vdc<\/code> only to <code>app01.example<\/code>; the client creates the filesystem. NAS disk <code>\/dev\/vdb<\/code> stays untouched.<\/p>\n<p>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 <code>dpkg-query<\/code>. The file&#8217;s IQN must match the target ACL exactly.<\/p>\n<pre><code># app01.example - yeni laboratuvar kurulumu\nsudo apt-get update\nsudo apt-get install -y open-iscsi\ndpkg-query -W -f='${Package}\\t${Version}\\n' open-iscsi\nprintf '%s\\n' 'InitiatorName=iqn.2026-10.example:app01' | sudo tee \/etc\/iscsi\/initiatorname.iscsi\nsudo cat \/etc\/iscsi\/initiatorname.iscsi\nsudo systemctl restart iscsid\n<\/code><\/pre>\n<p>I would verify storage disk <code>\/dev\/vdc<\/code> against the VM disk mapping, not just its expected 40 GiB size. Stop if <code>lsblk<\/code> shows partitions, filesystems or mountpoints. <code>wipefs --no-act<\/code> lists signatures without changing them; silence does not prove emptiness.<\/p>\n<pre><code># storage.example\nsudo apt-get update\nsudo apt-get install -y targetcli-fb\ndpkg-query -W -f='${Package}\\t${Version}\\n' targetcli-fb\nlsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL\nsudo wipefs --no-act \/dev\/vdc\n<\/code><\/pre>\n<p>Before creating the portal, allow TCP 3260 only from <code>192.0.2.21<\/code> through the firewall; block other sources. CHAP is disabled in this externally unrouted lab. IQNs are spoofable: ACLs are not cryptographic authentication. RFC 7143&#8217;s CHAP authenticates but does not encrypt traffic. Plan production network isolation and, where needed, IPsec.<\/p>\n<p>LIO exposes the unformatted disk as LUN 0. Automatic ACL generation and LUN mapping are disabled; access is explicitly mapped to one initiator. Expect <code>targetcli ls<\/code> to show <code>\/dev\/vdc<\/code>, portal <code>192.0.2.10:3260<\/code> and that mapping. Save configuration to the specified JSON file.<\/p>\n<pre><code># storage.example - disk kimli\u011fi do\u011fruland\u0131ktan sonra\nsudo targetcli set global auto_add_default_portal=false auto_add_mapped_luns=false\nsudo targetcli \/backstores\/block create name=app01_lun dev=\/dev\/vdc\nsudo targetcli \/iscsi create iqn.2026-10.example:storage.shared\nsudo targetcli \/iscsi\/iqn.2026-10.example:storage.shared\/tpg1 set attribute generate_node_acls=0 authentication=0 prod_mode_write_protect=0\nsudo targetcli \/iscsi\/iqn.2026-10.example:storage.shared\/tpg1\/portals create 192.0.2.10 3260\nsudo targetcli \/iscsi\/iqn.2026-10.example:storage.shared\/tpg1\/luns create \/backstores\/block\/app01_lun lun=0\nsudo targetcli \/iscsi\/iqn.2026-10.example:storage.shared\/tpg1\/acls create iqn.2026-10.example:app01\nsudo targetcli \/iscsi\/iqn.2026-10.example:storage.shared\/tpg1\/acls\/iqn.2026-10.example:app01 create mapped_lun=0 tpg_lun=0\nsudo targetcli saveconfig \/etc\/rtslib-fb-target\/saveconfig.json\nsudo targetcli ls\n<\/code><\/pre>\n<p>Discovery should return the target IQN; session details should identify the attached SCSI disk. Verify that the stable <code>\/dev\/disk\/by-path\/<\/code> link resolves to that disk and check its 40 GiB capacity. Stop for unexpected devices or signatures.<\/p>\n<pre><code># app01.example\nsudo iscsiadm -m discovery -t sendtargets -p 192.0.2.10:3260\nsudo iscsiadm -m node -T iqn.2026-10.example:storage.shared -p 192.0.2.10:3260 --login\nsudo udevadm settle\nsudo iscsiadm -m session -P 3\nLUN=\/dev\/disk\/by-path\/ip-192.0.2.10:3260-iscsi-iqn.2026-10.example:storage.shared-lun-0\nreadlink -f \"$LUN\"\nlsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN \"$LUN\"\nsudo wipefs --no-act \"$LUN\"\n<\/code><\/pre>\n<p>Formatting destroys data. Proceed only after verifying identity and emptiness. After mounting, the client manages files under <code>\/mnt\/san<\/code>.<\/p>\n<pre><code># app01.example - kimlik ve bo\u015fluk do\u011frulamas\u0131ndan sonra\nsudo mkfs.ext4 \/dev\/disk\/by-path\/ip-192.0.2.10:3260-iscsi-iqn.2026-10.example:storage.shared-lun-0\nsudo mkdir -p \/mnt\/san\nsudo mount \/dev\/disk\/by-path\/ip-192.0.2.10:3260-iscsi-iqn.2026-10.example:storage.shared-lun-0 \/mnt\/san\n<\/code><\/pre>\n<p>The journal described in Linux&#8217;s ext4 documentation does not coordinate writes between clients. <strong>Mounting the same ext4 LUN writable on two clients simultaneously can corrupt data.<\/strong> Do not add an ACL for <code>app02.example<\/code>; keep shared file access on NAS.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>A LUN being visible to two servers does not mean both can safely write to its ext4 filesystem. Simultaneous read-write mounts can cause data corruption; shared write access requires components such as a cluster filesystem, locking and fencing. Before formatting, verify the LUN identity and target device with lsblk.<\/p>\n<\/div>\n<h2 id=\"workload-matters-more-than-the-protocol-name-in-performance-comparisons\">Workload Matters More Than the Protocol Name in Performance Comparisons<\/h2>\n<p>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.<\/p>\n<p>Use <code>app01.example<\/code>: Ubuntu Server 24.04 LTS, GA kernel series 6.8, in this hypothetical lab. Prepared mounts are <code>\/mnt\/nas<\/code>, the NFSv4.1\/TCP share from <code>storage.example<\/code>, and <code>\/mnt\/san<\/code>, ext4 on the iSCSI\/TCP LUN. Never mount that ext4 LUN simultaneously on <code>app02.example<\/code>. This script checks mounts, not storage setup; it writes only disposable files it creates. Your user needs write access to both directories.<\/p>\n<p>The Bash example fills each target&#8217;s 2 GiB file before running 4 KiB random reads, 1 MiB sequential reads, and 4 KiB random writes with <code>fsync<\/code> after every write. Each profile runs for 60 seconds: one job, queue depth 1. Synchronous <code>psync<\/code> cannot measure highly parallel capacity. <code>dpkg-query<\/code> records package revisions.<\/p>\n<pre><code>set -eu\nsudo apt-get update\nsudo apt-get install -y fio\n\nout=$(mktemp -d \"$HOME\/fio-results.XXXXXX\")\nuname -r &gt; \"$out\/kernel.txt\"\ndpkg-query -W -f='${Package}\\t${Version}\\n' \\\n  fio nfs-common open-iscsi &gt; \"$out\/packages.txt\"\n\nfor base in \/mnt\/nas \/mnt\/san; do\n  mountpoint -q \"$base\"\n  test -w \"$base\"\n  findmnt -T \"$base\" -o TARGET,SOURCE,FSTYPE,OPTIONS \\\n    &gt;&gt; \"$out\/mounts.txt\"\ndone\n\nfor base in \/mnt\/nas \/mnt\/san; do\n  label=${base##*\/}\n  work=$(mktemp -d \"$base\/fio-work.XXXXXX\")\n  file=\"$work\/test.bin\"\n\n  fio --name=prepare --filename=\"$file\" --size=2G \\\n    --rw=write --bs=1M --ioengine=psync --iodepth=1 \\\n    --numjobs=1 --direct=1 --end_fsync=1 \\\n    --output-format=json --output=\"$out\/$label-prepare.json\"\n\n  for profile in random-read sequential-read sync-write; do\n    case \"$profile\" in\n      random-read) rw=randread; bs=4k; sync_every=0 ;;\n      sequential-read) rw=read; bs=1M; sync_every=0 ;;\n      sync-write) rw=randwrite; bs=4k; sync_every=1 ;;\n    esac\n\n    fio --name=\"$profile\" --filename=\"$file\" --size=2G \\\n      --rw=\"$rw\" --bs=\"$bs\" --ioengine=psync --iodepth=1 \\\n      --numjobs=1 --direct=1 --fsync=\"$sync_every\" \\\n      --time_based=1 --runtime=60 --randrepeat=1 \\\n      --lat_percentiles=1 --percentile_list=50:95:99 \\\n      --output-format=json --output=\"$out\/$label-$profile.json\"\n  done\n\n  rm -- \"$file\"\n  rmdir -- \"$work\"\ndone\nprintf 'Rapor dizini: %s\\n' \"$out\"<\/code><\/pre>\n<p>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 (<code>bw_bytes \/ 1048576<\/code>), and p50\/p95\/p99 latencies together. Write and <code>fsync<\/code> latencies are separate: write percentiles alone do not represent durability waits. Adding separate percentiles does not produce an operation percentile.<\/p>\n<p>Metadata needs another experiment. Single-file profiles miss creation, <code>stat<\/code>, directory listing, and deletion costs; fix file count, directory distribution, and concurrency separately.<\/p>\n<p><code>direct=1<\/code> does not remove every cache. Each VM&#8217;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 <a href=\"https:\/\/www.vps.tc\/blog\/en\/prometheus-grafana-setup-vps-monitoring\/\">Prometheus and Grafana<\/a>. Repeat in reverse order; keep these lab results separate from claims about enterprise SAN\/NAS products.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>Keep block size, queue depth, test file size, duration and synchronous write behavior consistent across comparisons. Run fio only against disposable test files; never target production data or a raw LUN. Sharing the same physical disk and virtual network affects measurements, so do not generalize lab results to all SAN and NAS products.<\/p>\n<\/div>\n<h2 id=\"failures-access-control-and-backups-what-the-protocol-does-not-solve\">Failures, Access Control and Backups: What the Protocol Does Not Solve<\/h2>\n<p>A protocol cannot keep a failed storage server available. In this hypothetical Ubuntu Server 24.04 LTS, GA 6.8 lab, <code>storage.example<\/code> (192.0.2.10) and the single network path are single points of failure for NFSv4.1\/TCP and iSCSI\/TCP-even while <code>app01.example<\/code> and <code>app02.example<\/code> remain running. iSCSI multipath needs genuinely independent paths, not two connections through one virtual switch. It supplies neither server nor controller redundancy alone.<\/p>\n<p>Two disks are not redundancy. Here, <code>\/dev\/vdb<\/code> serves NAS and <code>\/dev\/vdc<\/code> 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 <a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-a-vps-snapshot-point-in-time-backups\/\">What Is a VPS Snapshot?<\/a> 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.<\/p>\n<p>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.<\/p>\n<p>I keep authorization separate. RFC 8881 describes NFSv4.1 security; <code>sec=sys<\/code> trusts client-supplied UID\/GID values. <code>root_squash<\/code> 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.<\/p>\n<pre><code># app01.example \u00fczerinde durumu de\u011fi\u015ftirmeyen kontroller\nfindmnt --mountpoint \/mnt\/nas --output TARGET,SOURCE,FSTYPE,OPTIONS\nsudo iscsiadm -m session -P 3\nsudo journalctl -u iscsid.service --since '15 minutes ago' --no-pager\nsudo journalctl -k --since '15 minutes ago' --no-pager<\/code><\/pre>\n<p>These read-only checks remain unperformed. With NAS mounted, expect <code>\/mnt\/nas<\/code>, <code>nfs4<\/code> and <code>vers=4.1<\/code> from <code>findmnt<\/code>. <code>iscsiadm<\/code> reports session targets, portals and states, or no sessions. <code>journalctl<\/code> shows service and kernel logs for connection troubleshooting. Silence proves nothing.<\/p>\n<p>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.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>The single storage.example server in this hypothetical environment is a shared single point of failure for NAS and iSCSI. iSCSI multipath requires genuinely independent paths; it does not make the storage server redundant by itself. Treat connection-loss and file-restore exercises as planned lab validation steps that have not yet been performed.<\/p>\n<\/div>\n<h2 id=\"choosing-for-your-workload-file-shares-vm-disks-or-application-data\">Choosing for Your Workload: File Shares, VM Disks or Application Data<\/h2>\n<p>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.<\/p>\n<table>\n<thead>\n<tr>\n<th>Decision criterion<\/th>\n<th>Shared files<\/th>\n<th>VM disks<\/th>\n<th>Database data<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Access model<\/td>\n<td>Shared NFS file tree.<\/td>\n<td>NFS images or iSCSI blocks.<\/td>\n<td>Supported file or block access.<\/td>\n<\/tr>\n<tr>\n<td>Vendor support<\/td>\n<td>Client compatibility, locking.<\/td>\n<td>Hypervisor version, storage driver, clustering.<\/td>\n<td>Version, mount options, write durability.<\/td>\n<\/tr>\n<tr>\n<td>Latency target<\/td>\n<td>Small-file and directory operations.<\/td>\n<td>Queueing under concurrent VM workloads.<\/td>\n<td>Transaction commits, synchronous writes.<\/td>\n<\/tr>\n<tr>\n<td>Operational burden<\/td>\n<td>Permissions, exports, locks.<\/td>\n<td>Image\/LUN management, backup coordination.<\/td>\n<td>Consistency, logs, recovery procedures.<\/td>\n<\/tr>\n<tr>\n<td>Total cost<\/td>\n<td>Capacity, networking, backups, administration time.<\/td>\n<td>Those costs plus redundancy and support.<\/td>\n<td>Infrastructure, licensing, operations, recovery time.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>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&#8217;s repositories or your database. iSCSI guarantees neither speed nor high availability. One storage server remains one storage server.<\/p>\n<p>In the hypothetical Ubuntu Server 24.04 LTS lab with GA kernel series 6.8, I would choose NAS for shared application files. On <code>storage.example<\/code>, <code>\/dev\/vdb<\/code> holds ext4 at <code>\/srv\/nfs\/shared<\/code>, shared over NFSv4.1\/TCP and mounted at <code>\/mnt\/nas<\/code> on <code>app01.example<\/code> and <code>app02.example<\/code>. The server manages the filesystem; applications writing the same file still need coordination.<\/p>\n<p>For <code>app01.example<\/code> to manage its own filesystem, I would choose a dedicated iSCSI\/TCP LUN backed by raw <code>\/dev\/vdc<\/code> through Linux LIO. The Linux kernel&#8217;s ext4 documentation describes filesystem features, not shared-disk clustering: ext4 is not a cluster filesystem. Never mount this LUN&#8217;s ext4 filesystem writable on both clients simultaneously.<\/p>\n<p>I would require access, performance and restore acceptance tests with your target application. <a href=\"https:\/\/www.vps.tc\/blog\/en\/prometheus-grafana-setup-vps-monitoring\/\">Monitoring a VPS with Prometheus and Grafana<\/a> can reveal resource pressure; measure application latency separately. Before production, verify concurrent-access correctness, your predefined latency target and consistent recovery from backup.<\/p>\n<h2 id=\"choosing-for-your-workload-file-shares-vm-disks-or-application-data-2\">Choosing for Your Workload: File Shares, VM Disks or Application Data<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Determine whether your application needs shared file access or a block device it will manage itself.<\/li>\n<li>Verify your application and virtualization platform&#039;s NFS or iSCSI support in their official documentation.<\/li>\n<li>Record numerical targets for capacity, growth, latency, RPO and RTO.<\/li>\n<li>Verify devices with lsblk before disk operations, and confirm the LUN&#039;s stable device path after iSCSI discovery.<\/li>\n<li>Check UID\/GID consistency and file permissions for NFS, review initiator ACLs and CHAP settings for iSCSI, and restrict network access.<\/li>\n<li>Plan equivalent performance tests using only disposable files, and record cache and network conditions.<\/li>\n<li>Validate connection-loss behavior and restoration from an independent backup in the lab before going into production.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>Before finalizing your storage choice, document access, performance and restore acceptance criteria for your target application. Make production deployment conditional on validating those criteria in the lab.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>What is the main difference between SAN and NAS?<\/summary>\n<p>The main difference is the level of access presented to the client. NAS shares files and directories through NFS or SMB, with the storage server managing the filesystem. SAN presents block devices through protocols such as iSCSI or Fibre Channel. The client or cluster layer manages the filesystem. A single storage product can support both models.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Is SAN always faster than NAS?<\/summary>\n<p>No. Disks, network capacity, latency, caching, concurrent operations and the application&#039;s access pattern all affect performance. Small random writes and large sequential reads behave differently on the same infrastructure. Compare NAS and SAN under equivalent test conditions using IOPS, MiB\/s and latency percentiles. Keep synchronous write behavior consistent before deciding which is faster.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can two servers use the same iSCSI disk?<\/summary>\n<p>Technically, the same LUN can be presented to multiple initiators, but safe use depends on the filesystem and application architecture. Mounting a local filesystem such as ext4 read-write on two servers simultaneously can cause data corruption. Shared writes require a cluster filesystem, coordination and fencing. If you only need to share files, NAS offers a more straightforward approach.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can NAS be used for virtual machines and databases?<\/summary>\n<p>Yes, in configurations supported by the platform and application. NFS is a valid storage option for some virtualization and database deployments; it is not limited to storing shared documents. Verify vendor support, locking behavior, synchronous write requirements and behavior after a connection loss. Running VM disks or databases does not, by itself, require choosing SAN.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Is NFS or iSCSI traffic encrypted by default?<\/summary>\n<p>Using NFSv4.1 or iSCSI does not itself guarantee encryption. NFS AUTH_SYS relies on user identities reported by the client; iSCSI CHAP authenticates but does not encrypt data traffic. Depending on your requirements, consider Kerberos privacy protection for NFS or suitable network encryption solutions. Restrict access to TCP 2049 and TCP 3260 to the clients that need it.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Do I still need backups if I have RAID or snapshots?<\/summary>\n<p>Yes. RAID provides resilience against certain disk failures; it does not replace independent backups for accidental deletion, application errors or loss of the entire storage system. Snapshots can provide quick rollback, but those kept on the same system can be affected by the same failure. Define acceptable data loss through RPO and recovery time through RTO, then test restoration from an independent backup.<\/p>\n<\/details>\n<\/div>\n<h2 id=\"sources\">Sources<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc8881.html\" target=\"_blank\" rel=\"noopener\">IETF RFC 8881 &#8211; NFSv4.1 Protocol<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc7143.html\" target=\"_blank\" rel=\"noopener\">IETF RFC 7143 &#8211; iSCSI Protocol<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/docs.kernel.org\/filesystems\/ext4\/index.html\" target=\"_blank\" rel=\"noopener\">Linux Kernel Documentation &#8211; ext4 Filesystem<\/a> \u2014 docs.kernel.org<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Two servers accessing shared files and one server managing a remote disk are different requirements. Evaluate SAN and NAS by access model, application support, measured performance and recovery targets.<\/p>\n","protected":false},"author":2,"featured_media":1083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-1085","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datacenter"],"lang":"en","translations":{"en":1085,"tr":1084},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/1085","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=1085"}],"version-history":[{"count":1,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/1085\/revisions"}],"predecessor-version":[{"id":1087,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/1085\/revisions\/1087"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/1083"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=1085"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=1085"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=1085"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}