The short answer to how to implement SAN storage on a small budget: choose the transport first, give storage its own network, restrict access at the network before you mask LUNs to named hosts, add a second independent path and prove it fails over, and prove a restore works before you trust it.
On a mini-PC and a NAS, the transport is usually iSCSI over Ethernet you already own. Fibre Channel and NVMe/TCP are real options, but at this scale they mostly add shopping. If block storage versus a file share is still fuzzy, read what a SAN storage area network is first; a SAN is the wrong answer to a lot of homelab problems.
Who this is for, and who should skip it
Build one if two or more hypervisor hosts need the same block storage for live migration or HA restart, or if you want to learn the model before you meet it at work. Skip it if you run a single Proxmox box: local NVMe is faster and does not stall when someone reboots the switch.
Skip it too if you actually want shared folders. A LUN belongs to one host unless a cluster filesystem coordinates writes, so a media library for three machines is an SMB or NFS job.
Time cost: an afternoon to get a LUN mounted, the rest of the weekend to get multipath, timeouts and backups right. The second half decides whether you still like this setup next spring.
What hardware works for a small SAN?
An N100-class mini-PC as the initiator and a NAS as the target is plenty. The constraint is network ports, not CPU. ServeTheHome’s review of the N305-based Beelink EQ12 Pro lists two 2.5GbE ports on Intel i225-V B3, which is the useful shape: one port for the LAN, one dedicated to storage.
Two ports force the first real trade-off. One storage port means one path, so a cable pull or switch reboot stalls every VM disk on the LUN. Using both ports for storage buys multipath but pushes management onto a USB NIC. For a lab, one path plus good backups is defensible. Just know you chose it.
For the target:
- Synology Plus models such as the DS923+. SAN Manager runs iSCSI targets and LUNs. Synology’s SAN Manager specifications say instant snapshots need thin-provisioned LUNs on Btrfs, and thick LUNs support neither snapshots nor space reclamation. The DS923+ is on the compatibility list for the E10G22-T1-Mini 10GbE module when the onboard ports run out.
- TrueNAS. Block shares export zvols, ZFS volumes that behave as disks (TrueNAS iSCSI docs). ZFS checksums, scrubs and snapshot replication sit underneath the LUN, which is the main reason to pick it.
- Linux with LIO and targetcli. Teaches you the most, and has no UI to stop you mapping a LUN to the wrong host.
How to implement SAN storage, step by step
Order matters more than commands: transport, network and paths, access control, capacity, multipath, hypervisor, restore drill. Build it out of order and you get a volume visible to every host on the LAN.
1. Choose the transport
The transport fixes the hardware budget before anything else does. Fibre Channel needs its own HBAs, optics and usually switches, plus zoning skills, and none of it shares your existing Ethernet. NVMe/TCP runs on Ethernet too, but it carries NVMe rather than SCSI commands and needs a different host and target stack, so it is a candidate only when both the host and the array support it. iSCSI carries SCSI over ordinary TCP/IP, and on Linux the initiator is open-iscsi, already packaged for Debian and Proxmox.
For a mini-PC and a NAS, that usually settles on iSCSI. NVMe-oF vs iSCSI vs Fibre Channel walks through the trade-offs if your hardware leaves the question open; the rest of this guide assumes iSCSI.
2. Build the storage link and its paths
Give storage its own VLAN or its own cable, with no gateway and no routing to the rest of the house. iSCSI uses TCP port 3260 by default per RFC 7143, and anything that reaches the portal can attempt discovery, so bind the target to the storage interface only.
Leave MTU at 1500 unless every hop agrees on jumbo frames. Even TrueNAS’s documentation cautions that jumbo frames cost admin time to configure and to troubleshoot when they go wrong.
If you have two storage ports, decide now whether they become two paths, and make the paths independent: separate switch ports at minimum, separate switches if you have them. Draw the topology and confirm no single device appears on every path from host to LUN. A second path that shares a switch with the first fails with it.
3. Restrict access: network first, then masking
On Fibre Channel, zoning decides which ports may talk and LUN masking on the array decides which volumes a permitted host may use. On iSCSI, the storage VLAN and the portal binding from step 2 play the zoning role; masking on the NAS maps each LUN to named initiators. Build them in that order, so at no point is a volume reachable by a host that has not been given explicit permission to use it. The SAN zoning and LUN masking guide explains why the two are separate layers.
Never leave the mapping open. The TrueNAS iSCSI wizard offers to leave Initiator blank to allow all, and that setting is how a LUN later gets presented to a machine that formats it. One Synology quirk from its spec sheet: CHAP is not supported for discovery, so discovery is never your access control. The mapping is.
Creating the LUN, mapping it to an initiator IQN with per-host CHAP and logging the initiator in are protocol mechanics that differ by NAS and operating system. What is an iSCSI LUN? Targets, initiators and MPIO on iSCSI Hub covers those steps, so this guide stays on the design decisions around them.
4. Size capacity before you carve the LUN
Export one big LUN and put LVM on it; Proxmox’s iSCSI docs call that usually best. On Synology, thin provisioning is the price of snapshots, which makes the volume’s real free space the number to watch: a thin LUN on a volume that fills up is the classic slow-motion outage.
For a first pass at the numbers, the SAN LUN Capacity Calculator estimates RAID-adjusted space and aggregate Fibre Channel bandwidth; on iSCSI, only the capacity half applies. Its ratios are planning aids, so confirm the NAS’s own capacity figures and reserves before you size the LUN.
5. Add multipath, then pull a cable
The open-iscsi README documents a 120-second default for replacement_timeout and recommends 5 to 15 seconds under dm-multipath; Proxmox’s multipath guide uses 15. On a single path, keep the default: waiting two minutes beats failing I/O on a blip.
/lib/udev/scsi_id -g -u -d /dev/sdb # repeat for each path device
multipath -a <WWID>
multipath -r
multipath -ll
pvcreate /dev/mapper/<device>
vgcreate vg_san /dev/mapper/<device>Proxmox recommends leaving find_multipaths at its default strict, so only WWIDs you add get multipath devices. Red Hat’s iSCSI initiator docs add a gotcha: once dm-multipath manages the device, its fast_io_fail_tmo takes precedence over replacement_timeout. Set the timeout where it actually wins.
Then test the failover rather than the configuration. Pull one storage cable while a VM writes, watch multipath -ll drop a path, plug it back in and confirm the path returns. Repeat with the other cable, and with the switch if each path has its own. Multipath that is configured and multipath that works are different things. It also only covers cables and switches: a single-controller NAS rebooting takes every path at once.
6. Hand it to the hypervisor
# /etc/pve/storage.cfg
iscsi: nas-san
portal 10.10.10.1
target iqn.2026-10.lan.home:pve-lun0
content none
lvm: san-lvm
vgname vg_san
content images,rootdir
shared 1content none on the iSCSI entry stops anyone creating VM disks on the raw LUN. Snapshots on shared thick LVM arrived in Proxmox VE 9 as snapshot-as-volume-chain, which the LVM storage docs still label a technology preview. Don’t build your recovery plan on a preview.
Storage and backups: what bites at month 9?
Two things: thin provisioning outgrowing the pool, and treating a LUN snapshot as a backup. Alert on real pool consumption on the NAS, not on LUN allocation, because a thin LUN looks roomy right up until the volume underneath is full.
A LUN snapshot is a crash-consistent image of the whole LUN on the same disks. Roll it back and every VM on that LUN rewinds together. It protects you from a bad upgrade, not from a dead NAS.
Back up at the VM level to Proxmox Backup Server on separate hardware; a second mini-PC with a large SSD is enough. PBS does deduplicated incremental backups with client-side AES-256-GCM encryption and SHA-256 checksums. A backup stored on the array it protects is just another snapshot.
The restore drill, once a quarter: restore one VM to a new VM ID, disconnect its network, boot it, check the application data, delete it, and note how long it took. Run the first drill before the first production VM lands on the LUN, and repeat it after any change to the NAS, the paths or the hypervisor storage config. Until you have done that once, you have a backup job, not a backup.
Networking: should a SAN ever be exposed?
No. iSCSI stays on the storage segment. Don’t port-forward 3260, don’t push it through Cloudflare Tunnel, and don’t run block storage across a Tailnet to another building.
RFC 7143 makes IPsec mandatory to implement, not mandatory to use, so assume storage traffic crosses the wire in the clear and keep it on wire you control. Remote access belongs at the management layer: reach the NAS UI and Proxmox console over Tailscale and leave the data path alone.
Operations: updates, logs and alerts
Update this layer by hand: a NAS firmware update usually reboots the target and drops every session. Shut down the VMs on the LUN first, update the NAS, confirm sessions return with iscsiadm -m session, then update hosts one at a time.
For logs, iscsiadm -m session -P3 shows session state, multipath -ll shows path count, and the journal for iscsid and multipathd shows why either changed. Alert on three things: pool capacity, fewer paths than expected, and a backup job that didn’t run. If the SAN is up but slow, work through where SAN latency hides before buying a 10GbE card.
FAQ
Can I use a NAS as a SAN?
Yes. Any NAS that exports iSCSI LUNs is acting as a SAN target, including Synology Plus models through SAN Manager and TrueNAS through zvol-backed block shares. The NAS keeps serving SMB and NFS shares at the same time. What changes is ownership: the host that mounts the LUN owns its filesystem, not the NAS.
Is iSCSI better than NFS for Proxmox?
Not automatically. NFS is simpler to set up and reason about, because the NAS owns the filesystem and arbitrates access. iSCSI with LVM on top gives Proxmox shared block storage across a cluster, but snapshots on shared LVM are still a technology preview. For one or two hosts, NFS is usually the less painful choice (iSCSI vs NFS for VMware datastores walks through the trade-off).
Do I need 10GbE for iSCSI?
No. iSCSI runs over TCP/IP at any Ethernet speed, and a dedicated 2.5GbE link is a reasonable homelab baseline for VM disks. What matters more is that the link is isolated, error-free and consistent in MTU. Move to 10GbE when monitoring shows the storage link saturating, not because a forum thread said so.
Is Fibre Channel worth it for a homelab?
Rarely. Fibre Channel needs its own HBAs, optics and usually switches, plus zoning skills, and none of it shares your existing Ethernet. It is worth doing only if you already own the gear or need FC experience for work. The transport comparison covers where NVMe/TCP fits instead.
Related across the network
- Unraid iSCSI Target Setup: Plugins, LUNs and CHAP — iscsihub.com
- iSCSI Troubleshooting: Login, Timeout and Path Errors — iscsihub.com
