Hey everyone,

Sorry if this question has been asked before—it probably has. I’m new to Unraid, and I used ChatGPT to help set up my rig and wrap my head around some of the basics of NAS storage.

I’m a professional filmmaker working on a project that currently has about 16 TB of footage. The footage is high quality and low compression. generally around 280mbs reads and up to 800mbs depending on if it was Braw or not. My current setup is:

• 3x Seagate IronWolf Pro 18TB drives in the Unraid array (one parity, two data = ~36 TB usable)

• 1x 1TB SSD cache drive (2.5, not m.2)

• 1x 16TB HDD (separate from the array, used for other storage)

• Old PC hardware: ASUS Maximus Extreme VIII, 64 GB RAM, running Unraid

• 10 ghz network connection

• My editing PC has 20 TB of M.2 SSD storage dedicated to this project

The NAS is primarily for storage and archival—not live editing—though I might occasionally edit directly from it if my PC storage is tied up (like now).

In my industry, we follow the 3-2-1 backup rule:

• 3 copies of the footage

• 2 copies stored locally (my editing PC and the NAS)

• 1 copy stored off-site (external drive in a different location)

Right now, my Unraid setup uses standard parity for the 3x 18TB drives. I’m starting to wonder if I should reconfigure into RAID 5 (or something similar) for more speed, since I’m not editing from it full time.

Given my workflow, would you recommend sticking with Unraid’s single-parity setup, or moving to a RAID 5 configuration? I’m open to other suggestions as well.

What do you NAS pros think?

The advantage of Unraid vs. RAID-5 are:

• With Unraid each data disk is its own file system. With RAID-5 (or with ZFS raidz pols or with btrfs raid1/5) your data is 'striped' across all the devices. This means if you want to read a single file or set of files within a directory, with Unraid typically only a single hard drive will spin up - the one containing your data. When writing only the target drive and parity need to spin up. With RAID-5 or ZFS zpools (or btrfs) all the drives must spin up. If all your hard drives are constantly spun-up of course this doesn't matter but for larger arrays in energy-conserving setups it can make a difference and save some wear and tear.

• If catastrophe happens, and for some reason 2 or more hard drives totally fail, then at least with Unraid you don't lose all your data - just the data on the drive(s) that failed. If you have 2 parity drives then you can tolerate 2 complete failures before possibly losing data.

Disadvantage of Unraid vs other striping organizations:

• More effort may be required to keep collections of files on the same drive (this is where 'split-level' comes into play).

• Read/Write is definitely slower than striping. In the days of 1GB ethernet this hardly made any difference but with 10GB becoming more predominant this is a consideration.

Something else that you can do with Unraid is this: Suppose you have "critical" files on disk1. You can Stop array, physically remove disk1 and store off-site. Then install a replacement drive, Start array and let server rebuild disk1 contents. You would set up your critical shares so that they exist only on disk1. Note if you end up routinely doing something like this I'd recommend have 2 parity devices just to be safe in case another drive fails during rebuild.

Thank you for the quick reply and the pros and cons list. I initially prioritized both archiving and parity protection, but now I'm having doubts— the slow transfer speeds are starting to be a bottleneck, which I'm wondering if that will be a problem later as my needs grow past what my editing rig can maintain internally. Currently the array is get around 150 MB/s when using parity protection, is that normal?

For context, I’m currently copying footage at ~150 MB/s, whereas individual drives were capable of hitting ~280 MB/s before I enabled parity. I have added an image showing the settings for the parity setup. Do you have any suggestions that can speed this guy up?

With reconstruct write enabled you should be able to write at the max speed for the slowest disk at that position, since all the disks are the same, and assuming no controller bottleneck, and the disks are xfs formatted, it should only slow down as the disks get fuller, as they are much faster on the outer sectors vs internal ones.

Basically, you should get the same write speed as during a parity check at that position.

10 hours ago, JNM said:

The NAS is primarily for storage and archival—not live editing—though I might occasionally edit directly from it if my PC storage is tied up (like now).

In my industry, we follow the 3-2-1 backup rule:

The first question I would ask myself is what's more important, speed or uptime, or both? The second would be what are the future storage plans, will it need to grow?

You don't need the 'protection' from redundancy since you have good (tested I hope) backups, and if you don't plan on adding more drives for storage I'd steer you towards striped pools for speed (or even a different OS altogether)

If you create a RAID Z1 with the three drives, your transfer speed should be about double of a single drive. One drive will be used for parity.

Thank you everyone for the replies and information!

On 8/8/2025 at 5:17 AM, Michael_P said:

The first question I would ask myself is what's more important, speed or uptime, or both? The second would be what are the future storage plans, will it need to grow?

You don't need the 'protection' from redundancy since you have good (tested I hope) backups, and if you don't plan on adding more drives for storage I'd steer you towards striped pools for speed (or even a different OS altogether)

Currently, the NAS is primarily part of the backup workflow and won’t require extensive uptime for this project. To improve read speeds and minimize spin times, I’m testing a 2.5" 1TB SSD cache drive (a Samsung 860 EVO I’ve had since this PC was used for rendering/backups—it’s still in good health). I’m considering adding a larger cache drive in the future, but that would mainly be for smaller projects, since a full film would move through the cache quickly.

What OS would you suggest? The NAS is built on an older editing PC from the Intel 6th-gen era, which is why I’m testing Unraid. I believe 36 TB will cover the current film—I doubt I’ll reach 24 TB, though I may come close once shooting wraps. I’ll also be using these drives for future projects, as there should be plenty of room left—unless another setup would be better.

As a follow-up on scaling: in my situation, is it better to expand the pool of drives within a single array/RAID, or to create multiple RAIDs? My projects don’t share assets or footage—if I’m working on multiple films at once, they remain separate. Once finished, most projects move into archival (LTO's for longevity). However, if this turns into a docuseries or needs additional support for years for whatever reason, I plan to keep footage on these drives for 4–5 years before fully offloading. If a project remains active beyond that, the NAS would serve as the main hub for the footage, with only the bulk media offloaded from the M.2 drives.

It’s difficult to predict future client needs, so I've gone down the archival road, but that may not be the best use of the NAS and I'm wide open to correction.

On 8/12/2025 at 8:13 PM, Morris0 said:

If you create a RAID Z1 with the three drives, your transfer speed should be about double of a single drive. One drive will be used for parity.

Is RAIDZ1 like RAID 5? If using striped drives like this, would they get sustain read speeds of a SSD like 400 mb. They internal cache of the drive starts actually hits 700-800 mb, but then drops to the 200's once that has filled up.

On 8/8/2025 at 2:27 AM, JorgeB said:

With reconstruct write enabled you should be able to write at the max speed for the slowest disk at that position, since all the disks are the same, and assuming no controller bottleneck, and the disks are xfs formatted, it should only slow down as the disks get fuller, as they are much faster on the outer sectors vs internal ones.

Basically, you should get the same write speed as during a parity check at that position.

Any ideas of why I'm only seeing speeds between 150-180 mb? I've been thinking the slower write speeds where due to parity writing as well as writing to the HDD. Is that not the case?

OK, in your case I would suggest you look at something like truenas where the benefits of striping would be of more use to you than unraid's ability to add random drives to increase your capacity. You could do it with pools in unraid, but it wouldn't be optimal.

The speed from traditional striped RAID arrays is proportional to the number of drives being striped, you can make use of the combined speed of the drives vs single drive performance of non-striped arrays like unraid

13 hours ago, JNM said:

Any ideas of why I'm only seeing speeds between 150-180 mb? I've been thinking the slower write speeds where due to parity writing as well as writing to the HDD. Is that not the case?

It should be the max. write of the slowest disk at that position, including parity. Please post the diagnostics saved during a large file transfer.

Also install the diskspeed container and run both the disk and controller tests and post the results, in case there's an issue there.