Putting several editors on one shared volume is easy. Making it fast enough that nobody quietly reverts to copying footage onto a local drive is the actual engineering problem.
A local film and video production company had outgrown a familiar setup: footage scattered across external drives and direct-attached storage, copied from machine to machine as projects moved between editors. It worked until it didn’t. Multiple editors increasingly needed to cut the same high-resolution footage at the same time, and the copy-and-sync habit was costing hours a week and creating version confusion, the kind where two people unknowingly grade the same sequence twice. They wanted a single shared workspace fast enough that working directly off it was the path of least resistance. As Malta’s only Synology Platinum Partner and a long-standing Eaton power partner, Sirap designed that workspace, and, just as importantly, the network, RAID and configuration around it that decide whether shared editing storage actually holds up in daily use.
The challenge
Editing high-resolution video off shared storage is one of the more demanding things you can ask a NAS to do. It isn’t only about peak throughput; it’s about sustained, predictable performance while several editors scrub, seek and render at once. A single editor copying a file is a gentle workload. Four editors randomly seeking around different timelines on the same array is not, and that is the load this system had to feel smooth under. The team needed enough bandwidth for simultaneous streams, capacity for project archives that only ever grow, and protection against the power events that can corrupt a large media file mid-write. Their existing storage couldn’t sustain it, and a single bad shutdown risked days of work.
Why a NAS, and not another stack of fast local drives
The obvious alternative to shared storage is to keep giving each editor faster direct-attached drives. It’s cheaper per terabyte and, for one person, often quicker. The reason it doesn’t scale is collaboration. The moment two editors need the same footage, direct-attached storage forces a copy, and every copy is a new chance for versions to diverge and for someone to grade or export from the wrong one. A shared volume removes the copy step entirely: there is one authoritative set of media, everyone points at it, and the question of “which version is current” stops existing. That single source of truth, not raw speed, is the real reason a studio moves to centralised storage. The job of the design is to make sure the shared volume is fast enough that nobody is tempted to break the model by copying footage back to their desk.
The hardware foundation
We deployed a Synology DS3622xs+, a 12-bay unit built for sustained multi-user workloads. Its six-core Intel Xeon D-1531 and 16 GB of ECC memory (expandable to 48 GB) deliver the kind of sequential read performance Synology explicitly rates as suitable for high-quality video editing. But raw box specs are the starting point, not the finish line. The performance an editor actually feels is decided by what sits around the drives: the network, the RAID layout, the cache, the file system, how footage is organised across tiers, and how shared access is configured. Those are where this deployment did its real work, and where most shared-editing rollouts that disappoint went wrong.
1. The network is usually the real bottleneck
The DS3622xs+ ships with dual 10GbE, and that headline number is meaningless unless the whole path is 10GbE. A fast NAS behind a 1GbE switch is a 1GbE NAS. We built the link end to end: 10GbE network cards in the editing workstations, a switch that can actually move that traffic, and the NAS connected over 10GbE so each editor works off the shared volume at speeds that make local copies pointless.
What 10GbE actually buys you, in editable streams
It helps to translate the network speed into something an editor recognises: how many video streams it can carry at once. A single stream of 4K ProRes 422 HQ at 30fps runs at roughly 110 MB/s. A 1GbE connection tops out around 110 to 120 MB/s in practice, which means it can just about sustain one such stream, with nothing left over. One editor, one layer, and the link is full. The moment a second person opens a project, or the first editor stacks a multicam or a few graded layers, 1GbE falls apart and playback starts stuttering.
A 10GbE link moves roughly 1,000 to 1,200 MB/s in real-world use, around ten times as much. That is enough headroom for several editors to each run multiple layers, multicam angles or higher-bitrate formats off the same volume at the same time without anyone dropping frames. This is the difference between storage that technically holds the footage and storage that the team can actually cut on simultaneously, and it is the single biggest performance lever in the whole build. For studios whose formats are heavier still, the DS3622xs+ can take a faster network card over PCIe, so 25GbE is a future step rather than a forklift replacement.
SMB Multichannel, with the caveats stated
On DSM 7.2 and later, SMB Multichannel lets a workstation spread a single transfer across multiple network paths, improving throughput and adding resilience if one link drops. It’s genuinely useful for editing, but it has real conditions: it needs matching interfaces at both ends and supporting infrastructure between them, and notably it cannot be combined with traditional link aggregation. The two are mutually exclusive, and we regularly see setups where someone has switched on both and quietly halved their performance. We configured the path so the feature does what it’s supposed to, rather than trusting the label on the box.
2. The RAID layout: protecting hours of work against a rebuild
On a 12-bay array of large drives, the redundancy choice is not a detail, it’s a risk decision. We configured the array with two-drive fault tolerance rather than single-drive, and the reasoning is specific to large modern disks. When a high-capacity drive fails, rebuilding its replacement can take many hours or longer, and the entire array is under heavy sustained load for that whole window. That is exactly when a second drive is most likely to give out, and with only single-drive redundancy, a failure during a rebuild means total loss. Two-drive tolerance means the array survives a second failure mid-rebuild, which on disks this large is a realistic scenario, not a theoretical one. For a studio whose array holds months of billable work, paying for one more drive of redundancy is among the cheapest insurance available.
3. SSD cache that helps the workload it’s actually serving
We added NVMe SSD caching to accelerate the active project files editors hit constantly, smoothing scrubbing and playback against the HDD array. The honest nuance, and the one we set expectations on, is that caching accelerates random I/O, not large sequential transfers. It won’t make spinning disks saturate 10GbE while you copy a folder of raw camera files; the mechanical array is already reasonable at that. Where cache earns its keep is the constant small reads of an active timeline, which is exactly the felt experience of editing.
The performance difference is most obvious in the parts of editing that involve thousands of tiny reads rather than one big one. Scrubbing back and forth on a timeline, jumping between clips in a bin, loading thumbnails, and seeking inside multicam all hammer the array with small random requests, and that is precisely what a hard drive is slowest at and an SSD cache is fastest at. With footage of an active project promoted into NVMe cache, those operations return at flash speed and the timeline feels responsive; without it, the same actions wait on mechanical heads physically moving across platters, which is what people describe as the system feeling “sticky.” The network gets the data to the desk; the cache decides whether moving around inside a project feels instant. You need both working together.
We also configured the cache correctly for safety: a read-write cache is mirrored across two SSDs so a single cache-drive failure can’t cost data, and because write caching is involved, power-loss protection and the UPS below are not optional extras.
Why not just go all-SSD?
It’s a fair question, and a few years ago it might have been the answer. An all-flash array gives every read flash-level speed with no caching to think about. The reason we didn’t, and don’t currently recommend it for a media archive of this size, is cost, and specifically the state of the storage market right now. Through 2026, NAND flash prices have risen sharply, driven by AI data centres consuming the bulk of manufacturing output, with most analysts expecting little relief before the end of 2027. SSD prices have multiplied while supply has tightened. At the multi-terabyte scale a video archive needs, an all-flash build today costs several times what the equivalent hard-drive capacity does, and that gap is wider now than it has been in years.
The hybrid design sidesteps that. A large hard-drive array provides the bulk capacity cheaply, while a modest amount of NVMe cache sitting in front of it delivers most of the felt responsiveness of flash for the data that’s actually being worked on. The studio gets the speed where it matters, on the active project, and pays hard-drive prices for the cold archive that doesn’t need flash at all. Given where storage pricing sits, that is not a compromise so much as the economically sensible architecture, and it is straightforward to add more flash later if prices ease.
4. Btrfs, snapshots and silent corruption
We built the volume on Btrfs for two reasons beyond the obvious. The first is fast, low-overhead snapshots, so an accidentally overwritten or deleted edit can be rolled back in seconds rather than recovered from backup. The second is quieter but matters for an archive that will live for years: Btrfs stores checksums and, through scheduled data scrubbing, reads every block, compares it against its checksum, and repairs mismatches from RAID redundancy before they become corrupt frames. Large media archives are exactly where slow, silent bit rot tends to hide, because old footage can sit untouched for months. Scrubbing on a regular schedule is how you catch it. We set that schedule as part of handover so it runs during quiet hours and never competes with an edit session.
5. Shared access without editors overwriting each other
Putting everyone on one volume creates a new risk: two people touching the same asset. DSM’s shared-folder permissions and file-locking let us structure access so editors collaborate on common media while the system prevents the simultaneous-write conflicts that corrupt project files. We also separated active projects from the archive at the folder level, so finished work moves out of the fast working set and the live volume stays lean. Combined with snapshots as an undo of last resort, the result is a workspace that’s genuinely shared rather than merely centralised.
6. The drives matter as much as the box
A detail that’s easy to get wrong: not every hard drive is built for this. Consumer desktop drives are rated for light duty cycles and tend to drop out of an array under the constant, vibration-heavy load of a busy multi-editor NAS. We populated the unit with drives rated for 24/7 NAS or enterprise use, with workload ratings matched to the throughput this team puts through it. It’s an unglamorous line item that quietly determines how often you’ll be doing rebuilds, and choosing it well is part of why the array stays healthy rather than becoming a maintenance habit.
7. Keeping raw, working and finished footage apart
A shared volume is not one undifferentiated pool, and treating it like one is how studios end up with a slow, sprawling mess. We separated the storage by the role footage plays in the workflow, because the three kinds of media have completely different access patterns and value. Raw camera originals are large, written once and then rarely touched, but they are also irreplaceable, so they belong in protected bulk capacity that doesn’t need to be fast. Working files, the active project media, proxies and project files an editor opens every day, are the only data that genuinely benefits from the SSD cache and the fast network, so that is where we kept the cache focused. Finished deliverables and completed projects move to an archive tier once signed off, out of the live working set.
This segregation pays off three ways. It keeps the active volume lean and responsive, because the cache and the array aren’t being asked to serve terabytes of cold footage nobody is editing. It protects the originals, since raw media sits in a defined place with its own retention and snapshot rules rather than being scattered through working folders where it can be overwritten. And it makes the whole archive easier to reason about: there is one obvious home for each kind of file, which is also what makes the offsite backup and the retention policy tractable. A common refinement is a proxy workflow, where editors cut against lightweight proxy files day to day and the system only reaches for the heavy raw originals at the final conform and export, which stretches the fast tier even further. The folder structure is not glamorous, but on a multi-editor system it is one of the biggest differences between a workspace that stays fast for years and one that silts up within months.
Sharing previews with clients safely, without exposing the archive
Editing is only half the job; the other half is getting cuts in front of clients for review and approval, and this is where a lot of studios fall back on bad habits. Uploading a review cut to a consumer file-sharing service, emailing a link that never expires, or worse, giving an outside client some form of direct access to the editing storage, all create real exposure. The footage on this NAS is commercially sensitive and, in many cases, under embargo until release. It cannot be sitting on a random third-party drive or reachable from the open internet.
We set the studio up with a hybrid-cloud approach using Synology’s own tools, so client-facing previews live in a controlled layer that is deliberately separate from the production archive. Review cuts and previews are published through secure, expiring share links that are password protected and scoped to exactly the files a given client should see, with access logged and revocable the moment a project wraps. Crucially, the client never touches the live volume: they see a rendered preview in an isolated sharing layer, while the raw originals and project files stay on the internal network behind the studio’s own perimeter. Where useful, that sharing layer can be backed by Synology’s cloud so links stay fast for clients abroad without ever exposing the on-site storage directly to the internet. The result is a clean separation between “the place we make the work” and “the place clients see the work,” which is both better security and a more professional review experience than a folder of download links.
Capacity planning, so the archive doesn’t surprise anyone
High-resolution video consumes storage quickly, and the failure mode we plan against is a studio running out of space mid-project. We sized the initial array against the team’s real shooting volume with deliberate headroom, because a volume run near full both slows down and removes the room snapshots need to do their job. The 12 bays also expand to 36 drives with DX1222 expansion units, so the project archive can grow without replacing the head unit, which is a real consideration for a studio whose storage need only ever moves in one direction.
The point that’s easy to forget: this NAS is not a backup
A resilient, redundant array protects against drive failure. It does not protect against the building, fire, theft, or someone deleting the wrong folder and emptying it past the snapshot window. RAID is uptime, not a backup. We were explicit about this with the studio and designed the system so the working volume can replicate to a second target for a true offsite copy, keeping the master footage to the same 3-2-1 principle any irreplaceable data deserves. The shared volume is the fast place the work lives; it is not, on its own, where the only copy should ever sit.
Power protection with Eaton
A storage system under constant write load is exactly where sudden power loss does the most damage, and, with write caching enabled, an unclean shutdown is the scenario you most want to avoid. We paired the NAS with an Eaton UPS. As Malta’s Eaton power partner since 1988, we sized the unit to ride through short outages and trigger a clean, automatic shutdown of the NAS during longer ones, removing the corrupted-volume and lost-cache risk that comes with an abrupt cut to a busy array.
The outcome
Editors now work on a single shared, high-speed volume over a properly built 10GbE path, with SSD-accelerated access to live projects, footage tiered sensibly into raw, working and archive, snapshot-protected edits, integrity-checked archives, two-drive redundancy and expandable capacity. Client previews go out through a controlled, expiring sharing layer that never exposes the masters. Power events that once threatened hours of rendering are handled automatically, and the original footage has a route to a real offsite copy. The team spends its time editing rather than copying, syncing and managing storage, which was the entire point.
Featured Products in this article
-
Synology Diskstation DS1825+ 8-Bay Tower NAS
Read more -
Synology Diskstation DS1525+ 5-Bay Tower NAS
Read more -
Synology Diskstation DS925+ 4-Bay Tower NAS
Read more -
Synology Diskstation DS723+ 2-Bay Tower NAS
Read more -
Synology Diskstation DS423+ 4-Bay Tower NAS
Read more -
Synology Diskstation DS923+ 4-Bay Tower NAS
Read more -
Synology Diskstation DS124 Desktop NAS
Read more -
Synology Diskstation DS1522+ 5-Bay Tower NAS
Read more
Kurt Paris
With an MSc in Software Engineering, and over 15 years in IT Management, Kurt Paris leads technology strategy at Sirap. Zebra Technologies, Domino and Cisco-certified, he helps Maltese businesses build resilient storage & backup infrastructure, Machine Vision & AutoID Automation
