← All articles

Behind the scenes at Nameless 2026: data management and IT for the media crew

06 June 20265 min read

Behind the clips you scroll online there's a problem the crowd never sees: the data. At Nameless Music Festival 2026 SEM Devs handled ingest, redundant dual-NAS storage and the network that let the whole crew edit straight off the storage.

When you picture a festival like Nameless, you think of stages, drones, DJs and tens of thousands of people dancing under the mountains. What nobody sees is what happens behind it: every shot, every clip, every frame has to be offloaded, saved, protected and handed to the editors within hours. That's where we came in. At Nameless Music Festival 2026, SEM Devs ran the media crew's data management and IT, the invisible infrastructure that keeps an entire event's footage alive.

What Nameless is

Nameless is one of Italy's largest electronic music festivals. Born in 2013 in Lecco, it grew into an international event, and in 2026 it returned exactly where it all started: the Centro Sportivo Bione in Lecco, on the shores of Lake Como, with the Grigne peaks framing the main stage.

The 2026 edition ran from May 30 to June 1, across five stages, drawing a crowd from all over Europe. The booth featured headliners the size of Calvin Harris, John Summit and FISHER, alongside names like Pendulum, Andy C, Netsky, Sonny Fodera and Chris Lorenzo. To give a sense of scale: the 2025 edition passed 90,000 attendees over three days. Translated into crew language: a lot of cameras, a lot of footage, and zero chance of reshooting anything.

The problem the crowd never sees: the data

A festival media crew is a machine that produces data non-stop. Dozens of videomakers spread across stages, backstage, crowd and drones shoot for hours, every day, in high resolution. The result is terabytes of material per day that have to move from camera cards to safe storage, and from there to the editors, because social clips can't wait until the festival is over: they have to go out while the event is still live.

And there's one constraint that makes it more serious than a normal IT project: a festival can't be reshot. Lose a set's footage and it's gone forever. There is no "let's re-upload tomorrow". That completely reorders the priorities: data safety first, everything else after.

Two SEM Devs technicians at the Nameless 2026 data-management desk, with a laptop and workstation in the media crew tent.
The data-management desk: every videomaker's card passed through here before reaching the NAS.

Our role: data management and IT

Inside the media crew, SEM Devs owned the full lifecycle of the data: from the moment a card came out of the camera to the moment an editor was cutting with it. Three pillars: ingest, redundant storage, editing network.

1. Ingest: no file left behind

At the end of each shift, every videomaker brought their cards to our desk. From there began a structured offload: each card was copied to storage with integrity verification, giving mathematical certainty that the written file was identical to the original, byte for byte. Consistent naming, folders organized by day, stage and author. No material scattered across personal drives, no "I've got it on my own SSD". One single source of truth.

2. Dual NAS: two copies, always

The heart of the setup was two separate NAS units mirroring each other. Every incoming file didn't land on a single system, it was replicated to a second NAS holding a mirror copy. The principle is simple and non-negotiable: no single point of failure. If a disk had died, if one unit had hit a problem, the second copy was already there, in sync. Two copies of the footage, at every moment of the festival.

A SEM Devs technician in a branded polo backstage with the Nameless 2026 media crew, phone in hand.
Three days of continuous watch: copies, disk space and network monitored without a break.

3. The network: editing straight off the storage

This is the part that made the difference on timing. Instead of having every editor copy material locally, a bottleneck that would have blown the deadlines, we built a network that let every editor read and write directly on the NAS, working off the shared storage as if it were their local disk.

The sizing: each editing workstation connected at 2.5 Gbps, and the NAS ports bonded (link aggregation) into a dedicated 20 Gbps channel, isolated from the rest of the traffic. That guaranteed that even with multiple editors simultaneously pulling heavy video streams from the same storage, bandwidth never became the limit. Direct editing, no local copies to manage, no dead time waiting on transfers.

Why redundancy wasn't optional

In an office, a backup that runs overnight is fine. At a festival it isn't. A Calvin Harris set exists only once, and the window to publish the clips is hours, not days. Every single file had to be safe the instant it was offloaded, not "tonight when the backup kicks in".

That's why the dual copy across two NAS wasn't a luxury but the bare minimum: it's the difference between a hardware fault that becomes an anecdote and a hardware fault that becomes an irreversible disaster. For three days, our job was, very concretely, to make sure nothing got lost.

The result

The media crew got to do its job without ever stopping for a data or network problem. Clips went out on time, editors worked in parallel on the same storage without stepping on each other, and at the end of the three days the count that matters most was clean: zero lost files.

The full Nameless 2026 media crew, a group photo at the end of the event in the backstage tent.
The Nameless 2026 media crew. Behind every published clip there's also a piece of infrastructure.

What we take away

Designing IT infrastructure isn't only about writing code in an air-conditioned office. It's also about racking redundant storage and high-bandwidth networks under a tent, outdoors, under pressure, where a mistake can't be fixed the next day. Nameless 2026 was exactly that: data management and IT in the field, with the same care we put into our software projects.

If you run an event, a production or an operation that generates critical, one-shot data, the problem we solved here is probably yours too. And we know how to handle it.