Welcome to the Tuesday Teardown series, about looking inside the technology around us.

Today’s episode will be a short one, it’ll become clear why halfway down this page…

This is a little bargain LED flashlight, nothing to it really:

Three AAA (not AA) cells, a toggle button, 24 + 4 white LEDs, and that’s it. Press the button once, and the 4 LEDs on the side turn on, press again to light the 24 on the top, and again to turn it off.

Quite a bright light BTW. The 4 LEDs draw 190 mA, with 16 it rises to 270 mA. That’s perhaps 4 hours of use with 16 LEDs before the batteries run out.

The circuit is as ridiculously simple as can be – one 4.7 Ω resistor and a switch:

That “metal” reflector is actually plastic with a chrome finish. The PCB is one-sided, no doubt to lower the cost:

(it won’t take much bending to create a short with that top wire!)

Using Ohm’s law (V = I x R), we can deduce that the LED’s forward voltage is 4.5 – X = 0.190 x 4.7 – in other words, X = 4.5 – 0.190 x 4.7 = 3.6V. Note that the light intensity will vary considerably with battery voltage and that this lamp won’t work at all with 3 AAA EneLoop batteries which only supply 1.2V to 1.3V when fully charged.

The reason I’m opening up this trivial little gadget is not to marvel at the deep electronic engineering that went into it, but to show how custom plastics and a custom case makes something quite practical and nice to the touch. The top and bottom have a rubbery feel to them. The bottom has a little plastic hook in it, which can be folded out.

The bigger news today is a bit of a mess, unfortunately.

Last night I decided to upgrade the JeeLabs server from Mac OSX 10.7.3 to 10.7.4 – that update had been out for a few days, worked fine on two other machines here, so it seemed safe to apply the update to the server as well.

It failed.

This server is connected via wired Ethernet, and I usually only look at the GUI via a VNC-like “Screen Sharing” mechanism built into Mac OSX. It works well, because that connection is re-established even when the machine is in an exclusive “Updating…” mode, so you get to track progress even while the system is busy replacing some of its own bits and pieces. No screen needed, even though part of admin interface sometimes uses the GUI.

Last night, the server failed to come back online. Which is a major hassle, because then I have to move it to another spot to hook up a mouse, keyboard, and monitor to see what’s going on. Never happened before.

Trouble is (probably), that I turned the darn thing off forcefully. I knew that all the VM’s had been properly shut down, and I heard the characteristic reboot “pling”, so I thought it was waiting for a GUI response… or something.

Then the trouble started. Hooked it up, did a restart: no go. So I restarted it in recovery mode, and did a disk check/repair of all the disks. Guess what: the startup disk with all VM’s could not be repaired… whoops!

Time to kick my backup strategy in gear. I have two in place: local hourly Time Machine backups to a second drive, and daily backups for all VM’s to the cloud.

To make a very long night story short: the local hourly backups are fine, but they do not include the VM’s (whole-file backups of a VM disk every hour is not really practical). And the daily backups? Well, they are indeed all there – I can get any day in the past 3 months back, for any of the 4 VM’s. Awesome.

But Turnkey Linux does things a bit differently. Very clever in fact: it only backs up the minimum. The Linux Debian packages for example: these are not backed up, but re-installed from some other source. The rest is a well thought-out mix of full and incremental backups, and it all works just as expected.

Except that my VM’s are about two years old now, and no longer the latest base images used by Turnkey Linux. No problem, they say: you can get the latest, and then recover your own stuff on top of that.

So I spent about 6 hours trying to work out how to get my VM’s back up from the Amazon S3 storage. No joy. I can see all the files being restored, but the result is not a working VM. At some point, package installs & updates hang, with either udev restart problems or bootdisk image generation problems.

And now the crazy bit: the JeeLabs weblog + forum + café sites are all back up again (phew!). I restored from Time Machine to a freshly freed disk partition, and restarted the Mac – it’s alive! Right now, the server is running from the new disk partition, but with the 4 VM disk images still on the damaged partition. So apparently they did not get any damage, although the Mac file system structure on that disk seems to be hosed.

I’ll spend some time thinking about how to clean up this mess, and how to avoid it in the future. The good news is that I lost no data – just a lot of time and some hair. Yikes … this really was uncomfortably close to the edge!

The moral: test the backup strategy regularly. It can still break, even when not changing anything!

Update – All systems are “go” again.

Update 2 – Final diagnosis: one of the 2 internal disks was getting too hot, leading to intermittent failure, so it was hardware after all – unrelated to the 10.7.4 software. And it was probably all my fault, because I placed a (fairly warm) router on top of the Mac Mini. I’m going to replace the failed system drive with with an SSD.