Ами то е ясно, че щом нещо продължава по-кратко от хилядни от атосекундата, няма смисъл да се записва "векове" преди и след него.
Човекът (участник в експеримент там) е описал тази фаза като за лаици, няма какво да се обяснява във форум (и то не "Физика") "по-технически" от това (дал съм в получер шрифт онова, което ми се струва съществено):

The data we store, after removing all the background, detector noise, things like that, will be 15 petabytes per year. This will be stored on magnetic tape at CERN, and copied over very high bandwidth links to a number of computing facilities all over the world. The tapes are pretty much indestructible, as they aren't read out very often, and the additional redundancy in storing it in several places on disk and tape makes it pretty secure.

The format we use is actually relatively simple. It is essentially a self-compressed file a little bit like a .zip that contains all kinds of extra information like the exact detector timestamp, the event ID (essentially a number that tells us what pair of protons we collided starting at zero when we turn on), and a lot of other bits and peices like the calibration information for the detector.

You're absolutely right though, reproducibility is vital. There are still people worling on the data from LEP, the last big collider experiment at CERN, and their data has to be guaranteed. It is about 10000 times smaller than the LHC Dataset will be, but it still takes up a fair chunk of space.

In order to make sure everything is not only reproducible, but also to make sure no mistakes have been made, the entire calibration information has to be available for each dataset, like the temperature of certain detectors, the current in other ones, the angular misalignment of still others... it is a big task, and making drat sure no data is lost is even trickier.

The data storage and computing requirements of the detectors is about as complex and vital as the detectors themseves. The way it works is a constant set of filters to reduce the bandwidth of the detector data a step at a time. The output from the thousands of fibre cables coming from every different part of the detector produces mind-bogglingly large amounts of data per second. We're talking hundreds of petabytes a second. The first thing that happens is that compute farms deep underground in the detector caverns 'zero suppress' the signal- if the component didn't see anything, don't bother storing the fact that it didn't see anything.

Next the triggers kick in. In particle physics, a trigger is a signal that says 'somewhere, some peice of detector saw something interesting'. The first of these is the level zero trigger. It is an extremely fast peice of computing, usually hardware only, with no software that is configurable, and it runs at the speed of the collisions- 40MHz. that sounds slow, but it is reading several hundred thousand parts of the detector once at each clock tick, 40 million times a second, so really it is 40MHz*1,00,000 = 4THz. This is the first thing to make a decision. Because it needs to be quick, we tell it not to be too fussy- basically, if it sees anything even slightly interesting, it 'triggers' and tells all the detectors to write out their data to the compute farm. This reduces the load quite a bit- by a factor of 4 roughly, so we only get 1 in every 4 massive wads of data. The L0 isn't actually a computer, it is a bunch of very high speed FPGAs right on the circuit boards for the individual subdetectors. It needs to be there in order to reduce the amount of latency it introduces to the system.

After the L0, comes the HLT or Higher Level Trigger. It has been told to look for specifically interesting stuff, so for example the decay I want has been programmed into it in software. It gets the data from the L0, and now asks 'Ok, so L0 thought you were interesting, but why?'. A lot of the things the L0 thinks is interesting is actually crap, but the HLT has a little more time to find this out. This is on a compact but mighty compute farm only a few metres from the detector, seperated by concrete/lead walls.

This reduces the data by many more orders of magnitude, down to a few gigabytes per event, and this gets shipped off to cern over a pair of redundant 12GB per second fibre links.

At CERN, even more processing gets done, the data is reconstructed using the calibration information of the detector so that now instead of having abstract stuff like 'this detector pixel got hit' and 'this calorimter saw a few flashes of light' we instead get 'This looks like an electron that came from here' and 'this muon had a momentum of a few GeV'.

At this stage, we write to disk buffers, compress the data, and dump it onto one of the world's largest storage systems. We've a couple of tape robots that look like the assembly line of a car factory.

The data finally gets sent to various compute facilities all over the world where the analysis is performed. In this final stage, all of our graphs, plots, and hard numbers are produced, and this takes quite a while. Most of the test analyses I run take up to a week to complete on 60 or so core 2 duos. This is expected to vastly increase with real data.

Happiness is merely the remission of pain