The story as Robert tells it
According to The Register, Robert worked for a media-monitoring outfit. It scanned newspapers and websites for mentions of its clients, then cut out the articles and sent them over. Business was poor, and Robert said the company was nearly bankrupt by the time he left. He thought a fire sale followed.
That backdrop explains why the firm clung to legacy kit. Robert said one of the three internal fans in a 2U "pizza box" server wore out, and the machine was too old for a replacement to be available. His team's answer was to take the lid off and put a bigger fan on top of the component that needed airflow. The server kept working.
Six months later a second internal fan failed, and the team added another ill-fitted fan. The server then had one original fan, no lid and two non-standard fans resting over exposed components. Robert said it mostly worked, but staff had to take care near it because too much shaking could knock the fans over. When the third original fan died, management finally bought a new box.
What we don't know
The anecdote leaves out several things:
- Temperatures and alarms. There is no word on component temperatures or on any fan or thermal warnings.
- Fan specifications. We don't know how the improvised fans were powered or connected, or how well they matched the original airflow.
- Damage. Nothing says whether any hardware was harmed, so "it survived" is all we can say.
- Cause and effect. The firm's finances are colour in the story. They are not evidence about the safety or cost of the workaround.
Surviving once doesn't make a practice sound. Plenty of risky fixes work right up until they don't.
What vendor guidance says
Server cooling is designed as a system: fans, cover, baffles and layout together. Lenovo's ThinkSystem SR650 reliability guidelines show how strict one vendor is. They say to refit the server cover before powering on for proper cooling and airflow. They also say not to run the server for more than 30 minutes with the cover removed, because components might be damaged.
The same Lenovo page says a failed fan must be replaced within 48 hours of the malfunction. It adds that every air baffle supplied must be installed at startup, because running without one might damage the processor. With more than one processor installed, the fan population rules for each server must be followed strictly.
Those figures belong to the SR650, which is not Robert's server. Other vendors set their own limits, and Oracle's service manuals show how tight some of them are. One Oracle SPARC manual says the top cover fan assembly door must be closed within 60 seconds to maintain adequate airflow. Leaving it open longer while the server runs will cause an automatic shutdown. Another Oracle manual says that if a removed fan module isn't replaced in time, the service processor takes protective action. That means shutting the system down to prevent thermal damage.
Together these show the general pattern. Many servers expect to be closed, baffled and fully fanned, and some are built to shut themselves down when they aren't. Robert's old machine evidently didn't force the issue, but that was luck of the design, not a standard to count on.
Why "more airflow" isn't the same as "right airflow"
A bigger fan sounds sensible, and Robert's reasoning is easy to follow. The problem is that a server's airflow is channelled. Baffles and the cover push air across the CPUs, memory and drives. An open chassis with a fan perched on top can circulate air, but not necessarily through the places that need it.
Redundancy is also easy to get wrong. A fan-engineering article on N+1 cooling design makes the point that installing two fans does not automatically make a cooling system redundant. Shared connectors, controllers or narrow airflow paths can still leave a single point of failure. In Robert's rig, loose fans resting on components added a new failure mode of their own: they could tip over.
What to do when a server fan fails
This is general practice, drawn from the vendor guidance above rather than from Robert's account:
- Identify the exact model and read its service guide. Fan types, positions and time limits differ by vendor and by model.
- Check the management controller and logs. Cisco's fault reference, for example, tells admins to review the fan module's temperature range and to verify that airflow isn't blocked. It also says to replace the faulty fan module and consult the server-specific service guide first.
- Use the specified replacement part. Don't mix fan types if the vendor says not to, and don't substitute generic fans unless the vendor documents it.
- Keep the cover and baffles in place. If the cover must come off, keep it off only as briefly as the model's documentation allows.
- Plan the replacement. If parts are truly unavailable, treat any workaround as temporary. Consider a refurbished donor unit, a third-party support contract or a migration.
- Watch temperatures while you wait. Tell the people near the machine that it's in a degraded state.
The takeaway
Robert's story is funny, and the "tiptoeing" detail is the best bit. It's also a small lesson in technical debt. Each improvised fix bought a few more months, and each one made the machine more fragile and more dependent on tribal knowledge. If an old server is truly business-critical, the cheapest time to plan its replacement is before the second fan fails.
The anecdote shows what can happen, not what is advisable. Whether a system like Robert's stays up depends on its design, its workload and its room temperature, and none of those are known here. Vendor documentation is the safer guide.