Keep every editor and render node supplied at the same time
Post-production storage is not simply a capacity purchase. Codecs, concurrent streams, scrubbing, project metadata, caches, render traffic and recovery all shape the architecture.
& CAPTURE
& PROJECTS
& ARCHIVE
Each lane needs its own access, performance, protection and retention decision.
Design for the production stage—not for a generic “video workload”
Ingest, editorial, VFX, rendering and archive place different demands on storage and can compete with one another if they share the same resources.
Write sustained streams predictably
- Several sources may arrive at once while editors begin reading immediately.
- Verification, checksum and proxy generation create additional traffic.
- Landing space needs headroom for re-ingest and interrupted transfers.
Share media without confusing ownership
- Every workstation needs consistent paths and application-compatible locking behaviour.
- Scrubbing creates bursts that differ from simple sequential playback.
- Project files and media cache may belong on different storage lanes.
Absorb parallel reads and new frames
- Image sequences can generate high file counts and metadata activity.
- Render nodes may read the same sources while writing many outputs.
- Temporary data should not crowd out active editorial media.
Move finished work into governed retention
- Masters, source media and project metadata may need different retention periods.
- S3, file repositories and backup targets serve different access patterns.
- Restore time should be tested before active media is removed.
Separate what must be fast, shared, temporary and retained
Playback and scrub
Size sustained bandwidth and burst behaviour for the real codec mix and simultaneous streams.
Small but critical
Projects, media databases, thumbnails and permissions need responsive metadata and consistent paths.
Fast and replaceable
Local NVMe is often valuable where the application recommends workstation-local cache.
Broader access
Smaller derivatives reduce remote bandwidth and can feed review or asset-management workflows.
Policy and recovery
Retain masters and project context with known restore time, integrity checks and lifecycle rules.
Application guidance takes precedence: for example, Adobe recommends keeping Premiere media cache local rather than on shared storage, while shared project and scratch locations follow the chosen Productions workflow.
Choose the interface the application and clients actually understand
Protocol speed matters, but access semantics, operating-system support, locking, path consistency and failure behaviour determine whether collaboration remains safe.
| Access method | Often fits | Potential advantage | Validate before deployment |
|---|---|---|---|
| Local NVMe | Workstation cache, conform files, temporary renders and scratch | Very short I/O path and predictable local performance | Rebuildability, capacity duplication and whether data must follow the user |
| SMB | Cross-platform shared editorial and general media workspaces | Central namespace with common client support | Application recommendation, locking, path mapping, permissions and concurrent bandwidth |
| NFS | Linux/macOS pipelines, render farms and application-specific shared file access | Established shared file interface for Unix-oriented workflows | Exact application and OS support, locking, mount options, identity and caching |
| NVMe-oF | Qualified low-latency block volumes, render nodes, databases or specialised media applications | Efficient remote NVMe access over TCP or RDMA | Host support, multipathing, shared-filesystem requirement and application ownership of the volume |
| Fibre Channel | Established SAN workflows and qualified block-storage environments | Mature dedicated fabric with predictable operational model | HBAs, zoning, multipathing and cluster-aware sharing between hosts |
| iSCSI | IP-based block volumes for individual hosts or coordinated clusters | Broadly understood Ethernet block storage | Network isolation, multipathing and safe multi-host filesystem semantics |
| S3-compatible object | Archive, exchange, media repositories, cloud-style applications and automation | API-based access, scalable namespace and lifecycle-friendly design | Application S3 support, object size, request rate and restore/staging workflow |
No protocol creates collaboration by itself: validate the editing, asset-management or render application with the chosen client, filesystem and storage path. euroNAS is not presented as an Adobe, Blackmagic Design or other application-certified platform on this page.
A shared volume and a shared folder are not the same thing
This distinction prevents one of the most expensive mistakes in collaborative media storage.
File storage: the service coordinates the namespace
The storage service presents folders and files to several clients. It coordinates permissions and file access according to the selected protocol and application behaviour.
- Natural fit for a common media namespace
- Paths and identities must remain consistent
- Application locking requirements still need validation
Block storage: the host owns the filesystem
The storage presents a raw block device. Ordinary filesystems normally assume one owner; simultaneous access from several hosts requires a cluster-aware filesystem or application coordination.
- Useful for specialised, latency-sensitive volumes
- Multipathing protects the host-to-storage path
- Never connect multiple writers without a qualified sharing model
Calculate from the real codec mix and the busiest moment
Average transfer rates hide scrubbing, concurrent ingest, renders, backups, rebuilds and multiple layers on the timeline.
Codec and image sequence
Measure actual data rates for resolution, frame rate, bit depth, chroma format and compression—not a generic “4K” label.
Users, layers and cameras
Count simultaneous readers, multicam angles, timeline layers, ingest feeds and render consumers.
Playback is not scrubbing
Include seeks, thumbnails, project opens, small files, proxy creation and parallel render output.
Per-client and aggregate bandwidth
Switch uplinks and storage interfaces must sustain the total load, not only the speed shown on one workstation.
Protection consumes resources
Snapshots, replication, archive transfers, integrity checks and backup can overlap foreground work.
Plan for failure and rebuild
Define acceptable performance while a link, controller, node or drive is unavailable and data is recovering.
Distribute client access as the media workspace grows
In a distributed eEKAS file environment, IP Groups can place service addresses across selected gateway nodes. Administrators define primary, secondary and fallback nodes in the GUI and decide whether addresses remain together or are distributed.
- No command-line knowledge is required for routine endpoint configuration.
- Several service addresses can reduce reliance on a single gateway path.
- Client reconnect and application behaviour during endpoint movement still require testing.
Data protection and client access are separate: Ceph distributes protected data across the cluster; IP Groups organise how SMB or NFS clients reach file-service gateways.
NODE A
NODE B
NODE C
Graphical placement, relocation and distribution of file-service addresses.
Use a different control for each production risk
Snapshots
Fast recovery points for accidental changes or deletions. Retention and free capacity must be monitored.
Availability
Automatic failover or distributed services reduce interruption after component failure; they do not create historical copies.
Replication
A separate copy supports site or system recovery according to its schedule and recovery-point objective.
Backup and archive
Independent retention protects long-term project history. Restore access, catalogue information and integrity should be tested.
Keep the boundaries clear: euroNAS storage platforms provide snapshots, availability and replication options according to the architecture. Integrated Backup & Disaster Recovery and Instant Backup & Recovery for virtual machines are eEVOS capabilities.
Use euroNAS platforms as implementation examples
These examples show how requirements map to different designs. Application, client and workflow compatibility must be validated for every production.
Focused production workspace
A dedicated storage server for a defined workgroup using SMB, NFS or qualified block access. It can also be deployed as a Virtual Storage Appliance.
- Consolidated file and block services
- Useful where scale-out storage is not required
- Recovery and server availability remain part of the surrounding design
Two-node production availability
A local two-node design for shared file or block services requiring automatic failover, using either a synchronous Mirror or dual controllers with shared storage.
- Synchronous local continuity for the configured service design
- Separate asynchronous replication for additional recovery points
- Multipathing for supported block protocols
Scale-out media repository
A distributed Ceph platform for file, block and S3 services where capacity, service endpoints and client groups grow beyond a fixed pair of nodes.
- SMB and NFS through graphically managed service endpoints
- S3-compatible storage for suitable archive and application workflows
- Graphical protection, drive and service management without a CLI prerequisite
Virtual media services
eEVOS can host supporting virtual services such as qualified media-management, workflow or application servers and use internal, external shared or Ceph storage.
- VM high availability and live migration
- Integrated Backup & Disaster Recovery
- Instant Backup & Recovery for protected virtual workloads
Questions that reveal the real requirement
Which codecs, resolutions, frame rates, image sequences and audio formats are active?
How many ingest feeds, editors, timeline layers and render nodes operate at the busiest moment?
Which editing, finishing, MAM and render applications—and exact versions—must be supported?
Which operating systems, network speeds, path conventions and identity services are involved?
What must survive deletion, controller failure, site loss or archive corruption, and how quickly?
Will active bandwidth, archive capacity, users and service endpoints grow together or independently?
Check current application guidance
Vendor recommendations change with software versions. Validate the final design against the exact applications and clients in use.
Adobe: Productions on shared storage
Official guidance on shared NAS access, consistent paths, project locking, scratch locations, local media cache and per-workstation network capacity.
Open Adobe guidance →Blackmagic Design: DaVinci Resolve guides
Official product and workflow documentation for Resolve editing, collaboration and storage-related application behaviour.
Open Blackmagic Design support →Bring the workflow—not only a terabyte figure
We can review codecs, active streams, client applications, file and block semantics, network topology, protection, archive and growth for a business media-production environment.