Archive note: This describes a November 2025 home-lab build. It is a
record of a practical experiment, not a recommendation to build critical
storage around USB-connected disks.
A photography business produces an awkward kind of data. The files
are large, the volume only moves in one direction, and the value of an
old image can be difficult to predict. A discarded frame may be
irrelevant today and unexpectedly useful years later.
Cloud storage solves part of that problem, but recurring capacity
costs add up quickly when RAW files, layered edits, exports, and client
galleries all need somewhere to live. I already had a Proxmox host with
a 1 TB NVMe drive and three 4 TB hard drives. The question was whether
those parts could become a useful photography server without pretending
they were enterprise hardware.
The Compromise
The three drives lived in USB enclosures. That was the weak
point.
ZFS prefers direct, stable access to disks. USB bridges can obscure
drive identity, interfere with SMART reporting, disconnect under load,
or behave differently after a reboot. Passing USB disks through a
hypervisor to a TrueNAS virtual machine adds another layer that can
fail.
None of that made the experiment worthless. It did change the goal.
This was not going to become the only copy of irreplaceable work. It
would be a large, convenient working store with snapshots, monitoring,
and an independent backup requirement.
That distinction matters. RAID is availability, not backup. Snapshots
help with deletion and corruption, but they do not protect against
enclosure failure, theft, fire, or a mistake that affects the whole
pool.
Making the Hardware
Predictable
The first problem appeared before TrueNAS was installed. The Proxmox
host could freeze during boot when the enclosure was connected. The
likely interaction involved the USB Attached SCSI driver and power
management behavior of the bridge hardware.
For this particular enclosure, stability improved after switching the
disks from UAS to the older usb-storage driver and
disabling USB autosuspend. I then passed each disk to the TrueNAS VM
using its persistent /dev/disk/by-id/ path rather than a
volatile name such as /dev/sda.
That was an environment-specific workaround, not a universal
prescription. Disabling UAS can reduce performance, and globally
disabling autosuspend affects more than storage. The general lesson was
simpler: identify the actual bridge hardware, use persistent
identifiers, and test cold boots and sustained transfers before trusting
the arrangement.
The Storage Layout
Inside TrueNAS, the three 4 TB disks became a single RAIDZ1 vdev with
roughly 7.5 TB of usable capacity. I enabled lightweight compression,
disabled access-time updates, and used a large record size for the photo
dataset because the expected workload was dominated by large RAW, TIFF,
and PSD files.
The pool provided:
- One-disk fault tolerance
- Daily snapshots for accidental deletion
- Monthly scrubs for integrity checking
- Scheduled SMART tests where the bridges exposed enough data
- SMB access from macOS and Linux
I created a separate dataset for photographs and considered another
for Lightroom catalogs. That second use required more caution. Catalog
databases are latency-sensitive and generally safer on fast local
storage, with the catalog backed up to the NAS rather than opened
directly across an unreliable network share.
From Storage to a
Small Business Platform
Once the storage existed, it was tempting to make it the foundation
for every business application: client galleries, scheduling, invoicing,
contracts, email, and customer management.
The original plan proposed a separate Docker host VM for those
services while keeping TrueNAS focused on storage. That separation was
one of the better decisions in the design. A NAS should not become a
miscellaneous application server merely because it has a web interface
and available memory.
The proposed pattern was:
- Proxmox as the host and recovery boundary
- TrueNAS as the storage appliance
- A separate Linux VM for Docker applications
- A reverse proxy or tunnel for deliberately exposed services
- Private network access for administrative interfaces
- Database exports and configuration backups written to storage
The exact applications mattered less than the boundaries. Storage,
compute, public access, and backups were separate responsibilities.
What the Build Actually
Proved
The most useful result was not the RAIDZ1 pool. It was a clearer
model of risk.
Before the build, “the files are on three drives” sounded reassuring.
After the build, the questions became more precise:
- Can one drive fail without stopping work?
- Can an accidentally deleted folder be restored?
- Can the pool be rebuilt if the USB enclosure dies?
- Is there another copy outside this machine?
- Have I tested a restore rather than merely scheduled a backup?
The server improved local capacity and recoverability, but it did not
eliminate the need for another copy. If anything, putting the files into
a more organized system made the missing off-site backup more
obvious.
That is the recurring lesson of home infrastructure. The hardware is
often the easy part. The real work is deciding which failures the system
can survive, documenting the compromises, and refusing to call
redundancy a backup.