Two drives failed on the RAID 5 that holds the current season’s footage. One of them failed months ago and no one replaced it. The rebuild started on Friday, ran through the weekend, and stopped somewhere Sunday night with the array in a degraded state that the controller cannot resolve. Or the Avid Nexis workspace went offline in the middle of a Monday morning conform and hasn’t come back — the metadata engine is reporting an inconsistent state and the vendor’s remote support has spent two days trying to bring it back before recommending that you get the data recovered elsewhere. Or the Facilis TerraBlock stopped presenting one of its shares after a power event. Or the Synology NAS the whole team edits from on 10GbE reports two drives failed after a firmware update, and every editor on the crew is sitting there with no timeline access. Or the Fibre Channel SAN feeding four DaVinci Resolve suites won’t present a LUN this morning.

These failures are not measured in gigabytes. They’re measured in editor-days lost, delivery windows blown, and rental gear coming back due before recovery has finished. Gillware handles editing shared storage recovery as a distinct discipline from single-drive work — different tooling, different sequencing, different economics. This is one of the spokes under our broader video production data recovery page. For related NLE-side failures once the storage is back, see the sibling pages on Avid Media Composer, Adobe Premiere Pro, Final Cut Pro, and DaVinci Resolve.

What editorial storage actually looks like

Post-production shared storage isn’t a typical IT environment. The bandwidth requirements are extreme by ordinary standards — a single 6K RAW workflow can consume more sustained throughput than a mid-size company’s entire file server. The redundancy models are correspondingly aggressive, and the vendor ecosystem is specialized. A few of the platforms we see across the lab door:

• Avid Nexis. Avid’s own editorial storage platform, common in broadcast and network TV facilities. Presents workspaces to editors over the Nexis client, with a proprietary metadata engine coordinating multi-user access. Failures cluster around metadata engine inconsistency, drive failures within the storage nodes, and network fabric events between head and storage components.
• Facilis TerraBlock. Fibre Channel and iSCSI shared editorial storage with a dedicated management appliance. Frequently deployed in commercial post houses. Failures involve share metadata corruption, controller failures, and RAID-level failures in the backing storage.
• EditShare EFS. Scale-out shared media storage with clustered metadata. Failures often involve metadata inconsistency across nodes or backing RAID failures.
• Synology and QNAP editorial NAS. High-end Synology and QNAP boxes on 10GbE or 25GbE are common in smaller shops and freelance operations. Failure patterns match general NAS failures — RAID controller drops, filesystem corruption, firmware update failures. See our NAS data recovery hub for platform-specific pages.
• TrueNAS and custom ZFS builds. Some post houses run custom TrueNAS deployments for cost or flexibility reasons. Failures involve pool import errors, zpool degradation past the redundancy threshold, and metadata block corruption.
• Fibre Channel SANs. Older but still common in facilities running 4K, 6K, and 8K editorial workflows. Failures involve LUN presentation issues, controller failures, and RAID-level failures in the backing storage.
• DAS RAID enclosures. Direct-attached RAID storage — Thunderbolt or SAS-connected — used by individual editors handling high-bandwidth footage. Failures involve controller failure, individual drive failures, and enclosure electronics failures.

What all of these have in common is that when they fail, the failure is rarely limited to a single drive. Editorial storage is designed to keep working through single-drive failures — that’s what the RAID is for. When you actually can’t get your data back, the failure is usually multi-drive, controller-level, filesystem-level, or metadata-level, and often several of those at once.

Why editorial RAID recoveries are different from ordinary RAID recoveries

The general RAID data recovery process — image every member drive, run parity reconstruction against the imaged copies, rebuild the filesystem — is the same discipline whether the array holds an accountant’s file share or a colorist’s 6K DPX sequences. What changes with editorial storage is the scale, the file structure, and the operational context.

Scale. An editorial array can hold 100 TB, 500 TB, or well over a petabyte of media. Imaging every member drive of an array that size is a physical undertaking measured in days of continuous read operations, with dedicated bandwidth into a staging environment large enough to hold the working set. Recovery time is often bounded not by the difficulty of the reconstruction but by the raw physics of reading tens or hundreds of terabytes from drives that are themselves in various states of health.

File structure. Editorial file sets have specific structural expectations that a general filesystem recovery may not preserve well. Media files reference each other through NLE project structures (Avid MediaFiles indexes, Premiere media caches, Resolve database references). A “recovered” filesystem that returns the files but scrambles their directory placement can be technically successful and practically unusable — because the NLE can no longer find its media. Recovery for editorial arrays has to preserve the specific directory hierarchies and file naming that the NLE expects.

Operational context. The failure often happens in the middle of active production. A show is being cut, a spot is being colored, a mix is being finished, and the storage has to come back on a specific schedule to avoid cascading delays through the entire post production pipeline. This shapes how the recovery is sequenced — high-priority workspaces first, less-active archives second, whatever can be brought back partially while the rest is still being reconstructed.

Why editorial RAID rebuilds fail

The specific failure that turns up most often at the lab is a rebuild that didn’t complete. RAID 5 is common in editorial storage for its balance of usable capacity against redundancy, but it has a well-known second-drive failure problem: during a rebuild, the controller must read every remaining drive in full to reconstruct the failed one. If a second drive is marginal — has undetected bad sectors, or is close to failure itself — the rebuild will often finish it off. The array drops into a degraded-past-recovery state, and the controller cannot bring it back.

RAID 6 with dual parity protects against a single drive failing during a rebuild of another failed drive, but not against systemic problems that affect multiple drives at once — a batch of drives from the same manufacturing lot developing similar failures on similar timelines, a shelf of drives affected by an environmental issue (heat, vibration, power quality), or a controller-level fault that corrupts writes to multiple drives simultaneously.

Modern editorial storage also fails in ways that don’t map neatly to classical RAID failure. Metadata engines can lose state independently of the underlying disks. Object storage layers can develop bucket-level inconsistencies. Distributed filesystems can lose cluster consistency after network events. In all of these cases the drives themselves may be perfectly healthy — the storage layer above them has failed.

What recovery looks like for an editorial storage system

Editorial recovery begins the same way every RAID recovery begins: with imaging. Every member drive of the failed array is imaged sector-by-sector to healthy replacement media. This is done in a controlled environment with dedicated hardware, and it is done to imaged copies — never to the original drives, which are preserved as read-only reference throughout the rest of the recovery.

From the imaged copies, the array geometry is reconstructed: stripe size, parity distribution, drive order, offset, and any vendor-specific metadata that determines how the array was assembled. For proprietary editorial storage platforms — Avid Nexis, Facilis, EditShare — the reconstruction includes the platform’s own metadata engine, not just the underlying RAID.

Once the array geometry is reconstructed, the filesystem is examined. Editorial arrays commonly run XFS, ZFS, or vendor-specific filesystems tuned for high throughput. Filesystem corruption is characterized and repaired to the extent possible, preserving the original directory structure and file placement. Bad-block substitution and header repair are used where individual files have been affected.

The recovered filesystem is then mounted read-only in the lab and the media is extracted. For active production recoveries, we work with your post supervisor or IT lead to prioritize which workspaces, which shows, or which projects come back first — the entire array does not have to be reconstructed to a single point in time for editors to get back to work.

What not to do while shared editorial storage is down

• Don’t let the vendor keep running rebuilds on the original drives. Every additional read from a marginal drive reduces the probability that the drive is readable at all during recovery. If a rebuild has failed once, subsequent attempts on the same physical media are typically counterproductive.
• Don’t replace drives and swap them in without imaging the originals first. A hot-swap of a marginal drive into a running array can trigger a rebuild that finishes off other marginal drives before it fails.
• Don’t power-cycle the storage system repeatedly. Restarts can trigger recovery routines that write to the drives, altering the state we would otherwise recover from.
• Don’t accept a “rebuild anyway” recommendation from generic support. Vendor first-line support is often trained to try one more rebuild; if the array is far enough into a failure that a first rebuild already failed, the additional attempts usually reduce recoverability.
• Don’t reformat, initialize, or reset the array. Any of these operations write over the metadata that recovery depends on.
• Don’t ship the drives without labeling positions. When drives arrive at the lab, we need to know which drive was in which slot. Labels, photos, or a clear documented slot-to-serial mapping — captured before the drives are removed from the enclosure — matter to the recovery.

Working with Gillware on editorial storage recovery

Gillware has been recovering editorial and multi-drive storage for more than two decades, from single-editor DAS enclosures to facility-scale Fibre Channel SANs. Our lab in Madison, Wisconsin operates dedicated RAID and shared-storage recovery workstations alongside the ISO 5 (Class 100) cleanroom used for drives that need physical intervention.

Editorial recoveries are quoted before work begins. Unlike single-drive recoveries, multi-drive arrays generally carry engineering charges reflecting the imaging and reconstruction work required regardless of outcome — quoted at intake, no surprises. Expedited service is available where a show or delivery is on the schedule; the lab has coordinated with post supervisors and facility CTOs across time zones to keep recovery timing aligned with the production calendar.

For general (non-editorial) multi-drive recovery, see our RAID data recovery and NAS data recovery hubs. To return to the routing hub for other post-production failure modes, see video production data recovery.