It was 1997. I was working my first full-time  job, and my phone rang with my first crisis.

“What happened to the K drive?” the caller asked.

I glanced over at my network drive cheat sheet, which listed all of our shares and what server they were on. In those days, most of our servers still had 300-400 megabyte drives and that meant every file server hosted, at most, a couple of shares. There was no K drive on our list. I was afraid this was about to get interesting.

My first IT crisis involved a system like this. It was 10 years old at the time and had every technology that lost inside.

So I put the caller on hold and asked one of the office’s more experienced veterans about the K drive. He gave me a puzzled look and said we decommissioned that server years ago.

The K drive was hosted on an old IBM PS/2 Model 80 with OS/2 3.0 installed on it. The thing about those old OS/2 servers was that they ran until something went wrong with the hardware. In the case of these then-10-year-old Model 80s, you’d be surprised how infrequently that happened. As best we could tell, when the server was decommissioned, whoever was doing the work got distracted and didn’t haul the server off. So one of the users plugged it back in, turned it back on, and continued using it.

Stuff like that still happens today, though we like to think it doesn’t. This server was more prone to it, since back then, file servers lived anywhere we had adequate power and cabling, which meant some of them were out in the open, where non-sysadmins could touch them. But it happens in datacenters too. If a system is powered off, one of two things happens: Someone plunders it for parts, or they turn it back on.

Today, I use ping sweeps and victory pings to reduce the chances of this happening.

In this case, an end user plugged it back in. So the server soldiered on until it was a decade old. Then the hard drive crashed and my phone rang. There wasn’t much we could do, of course. But the news director had files on the drive that he needed, and he had a lot of political clout, so the order came down to recover the data. We didn’t have any money–there was a reason we still had 386-based IBM servers hanging around in 1997–but orders were orders.

I called Ontrack. We faced a number of challenges. It was an EDSI drive attached to a Microchannel controller, and the drive was formatted HPFS386, which was slightly different from run-of-the-mill HPFS used by the desktop versions of OS/2. If there was ever a more obscure combination of outdated stuff, I never saw it. It was every poor decision IBM ever made, in a single box. We even had a token ring network.

Ontrack told us they could handle it, but we would need to send them the drive and the controller card, and be prepared to send them a Microchannel machine too, while we were at it. They thought they might have one, but would have to look. So I filled out their questionnaire, shipped off the drive and controller and tracked down an IBM Model 70 to ship. The “80” in Model 80 may have been a reference to the machine’s weight. They were big and heavy. We weren’t going to ship one of those. The Model 70 was the much smaller and lighter desktop version.

They found a system, so I never had to mail the Model 70.

About a week later, we received a box in the mail. Inside was the drive, the controller, a note stating the drive was no longer functional and we shouldn’t try to use it, a bill for about a thousand dollars, and half-full CD containing the contents of the drive. We had our data back. And it only cost $3 per megabyte to get it.

That summer one of my projects was to build a new file server with large drives running on current hardware.

When people are dismissive of Shadow IT, I tell them this story. It’s one of the best ways I’ve found to get systems rebuilt onto suitable hardware.