===== Storage (NAS) Configuration ===== This page covers how to configure NAS storage devices for a Trash Panda–style Plex ecosystem.\\ The goal here is not theoretical perfection or enterprise purity. The goal is **availability, performance, and predictability** in a real-world hobbyist deployment that serves Plex, ARR automation, and users who expect things to just work.\\ This guidance assumes:\\ * A NAS with **at least two physical network interfaces** * A segmented network with **NFS, LAN, and DMZ VLANs** already defined * Linux-based service hosts consuming storage primarily over **NFS**, with optional **SMB** access from LAN based Windows clients. ==== Design Priorities ==== Before diving into configuration, it’s important to be explicit about priorities:\\ 1. **Availability > Raw Performance**\\ Media that is temporarily unavailable is worse than media that transfers a little slower. 2. **Predictable Performance**\\ Large sequential reads dominate Plex workloads. We optimize for that. 3. **Operational Simplicity**\\ Recovery should be boring. Expansion should be deliberate. Maintenance should be rare. 4. **Security Through Segmentation**\\ Storage traffic stays isolated. User traffic stays convenient.\\ Everything below flows from those principles.\\ ==== Dual NIC Configuration ==== A dual-NIC NAS is foundational to this ecosystem to ensure total separation and isolation of NFS traffic.\\ === NIC Roles === **NIC 1 – NFS VLAN**\\ Dedicated, high-throughput storage traffic between the NAS and media services. **NIC 2 – LAN VLAN**\\ Management access and SMB connectivity for user-facing devices. These interfaces should **never be bonded**. They serve different purposes and different trust levels.\\ === NFS VLAN NIC === * Assigned exclusively to the **NFS VLAN** * No default gateway * Jumbo Frames enabled (MTU 9000), end-to-end * Access restricted to known service hosts only This interface exists solely to move large media files efficiently and quietly.\\ === LAN VLAN NIC === * Assigned to the **LAN VLAN** * Default gateway present * Standard MTU (1500) * Used for:\\ * NAS management UI * SMB shares * Backup monitoring\\ This separation ensures storage traffic never competes with user traffic and is never exposed to unnecessary risk.\\ ==== RAID Strategy: Availability First ==== Media libraries are large, slow-moving, and painful to rebuild. RAID exists here to **keep the system online**, not to replace backups.\\ === Recommended RAID Levels === * **RAID 6** (preferred for larger arrays) * Tolerates two disk failures * Slower writes, excellent availability * **RAID 10** (if disk count and budget allow) * Strong performance * Faster rebuilds * Higher usable capacity cost === RAID Levels to Avoid === * **RAID 5** * Rebuild risk is unacceptable with modern drive sizes * **Single-disk redundancy only** * Downtime during rebuilds is common and long ==== Hot Spares ==== If your NAS supports it and you can afford the bay:\\ * Configure at least **one hot spare** Automatic rebuilds reduce downtime and human intervention — both are wins. ==== Volumes and File Systems ==== === Volume Layout === Keep it simple. * One primary volume for media and metadata * Avoid unnecessary volume fragmentation * Expansion should be planned, not improvised Complex layouts tend to create operational debt without meaningful benefit for media workloads. === File System Considerations === The ideal file system for this ecosystem has: * Strong sequential read performance * Stable NFS and SMB support * Mature tooling and recovery options Common choices: * **EXT4** * Extremely stable * Excellent performance * Low overhead * **XFS** * Very good for large files * Scales well with volume size * **Btrfs / ZFS** * Powerful, but heavier * Snapshot features are useful, but come with complexity For first-time builders, **simplicity beats features**. Choose what your NAS platform supports best and what you understand how to recover. ==== NFS Configuration ==== NFS is the **primary protocol** for Plex, ARR services, and Unmanic in this ecosystem. === Why NFS? === * Lower overhead than SMB * Excellent Linux support * Predictable performance * Clean permission model for service accounts === Export Strategy === * Export only to **NFS VLAN IPs** * Use explicit host-based access controls * Disable root squash *only if you fully understand the implications* Typical exports include: * Media libraries * Incomplete and completed download paths * Transcode or processing work directories (if needed) === Performance Notes === * Jumbo Frames must be supported end-to-end * Avoid exporting the same paths over both NFS and SMB * Consistency matters more than micro-optimizations ==== SMB Configuration ==== SMB exists for **human interaction**, not core services. === Use Cases === * Browsing media from desktop systems * Manual file inspection or cleanup * Occasional direct access from Windows or macOS === Best Practices === * SMB access only on the **LAN VLAN** * Read/write permissions scoped to user accounts * No service containers or VMs should rely on SMB mounts This keeps automation fast and user access convenient without entangling the two. ==== Backup Strategy ==== RAID is not a backup. Snapshots are not a backup.\\ Backups exist to save you from:\\ * Accidental deletion * Corruption * Catastrophic failure * Poor decisions made at 2 AM === Primary Backup Method === * **External USB HDD** * Capacity large enough to hold the full media library * Directly attached to the NAS === Backup Characteristics === * One-way sync from NAS → backup disk * No live mounts * No automation that can delete backup data Backups should be: * Predictable * Boring * Verifiable ==== Final Thoughts ==== The NAS is the quiet workhorse of the entire Plex ecosystem.\\ If configured correctly:\\ * You will rarely think about it * Performance will feel effortless * Failures will be survivable Optimize for **availability, isolation, and simplicity**, and the rest of the system becomes much easier to manage.