Differences

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

--- foundation:storage [2026/02/15 23:17] – [RAID Strategy: Availability First] privacyl0st
+++ foundation:storage [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-{{htmlmetatags>
-metatag-description=(Complete Plex automation guide using Sonarr, Radarr, Prowlarr, Jackett, Overseerr, Unmanic, and NVENC-enabled NVIDIA GPUs)
-metatag-robots=(index,follow)
-metatag-og:title=(Plex Automation and NVENC Hardware Transcoding Guide – Trash Panda Wiki)
-metatag-og:description=(Step-by-step Plex automation and NVENC encoding guide)
-}}
-===== 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:\\
-. **Availability > Raw Performance**\\
-Media that is temporarily unavailable is worse than media that transfers a little slower.
-. **Predictable Performance**\\
-Large sequential reads dominate Plex workloads. We optimize for that.
-. **Operational Simplicity**\\
-Recovery should be boring. Expansion should be deliberate. Maintenance should be rare.
-. **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
-I use RAID 5 because that was the best compromise maximizing disk space with the available slots in the NAS I use. If you have a NAS with 5+ bays go ahead and use RAID 6, but for my setup with 4 total bays using 4TB disks RAID 5 was a winner.
-==== 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.