User Tools

Site Tools


foundation:storage

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

foundation:storage [2025/12/16 00:05] – created - external edit 127.0.0.1foundation:storage [2025/12/19 23:44] (current) privacyl0st
Line 1: Line 1:
-= Storage =+===== Storage (NAS) Configuration ===== 
 +This page covers how to configure NAS storage devices for a Trash Panda–style Plex ecosystem.\\ 
  
-Covers NAS configuration, disk layouts, redundancy strategies, and backup considerations for building reliable 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 writesexcellent 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 plannednot 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 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.
  
foundation/storage.txt · Last modified: by privacyl0st