Summary

I had a 'hard drive' (really, SD card) crash, and now I am in data recovery mode.  I will have to rebuild the server.  I will lick my wounds in the modern, containerized, way.

Deets

Youth

I have run a home server for decades -- I assume most have at this point.  Back in the day it was a relegated desktop system (a 66 MHz Pentium with the floating point bug, lol) but progressively it migrated to embedded devices like a WRT54GL, an NSLU2, a SheevaPlug, and finally to a RaspberryPi.  The server provided WWW, FTP, SSH, SMB, MySQL, SCM, and later VPN.  It primarily served media for the home, and a gateway into the home from outside.  Over the years, some of that responsibility was delegated to other things (such as a dedicated NAS for storage), and I use client-server database less now (preferring embedded application-specific databases using sqlite).  But it is still handy to have a server for the other things, either for legacy support or most critically for VPN.

The latest stage of that evolution led to using a Raspberry Pi 3, and a 32 GB SD card for the filesystem.  Both of those things are wonderfully cheap and compact and silent and low power, but they are neither server-grade components.  Hardware failures are more frequent with these consumer products.  I lost my SheevaPlug after many years of service (the device had a well-known design defect in the power supply).  Although it was a bit of a hassle to migrate to the Raspberry Pi replacement, it was surmountable -- just yet another lost weekend to home IT work.

Sorrow

My latest system failure was more catastrophic.  As best as I can tell, I think the Raspberry Pi is OK, but rather the SD card is intrinsically defective.  And I did not have recent backups, so I was faced with data loss and re-deploying software and configuration.  Shame on me, of course, but there I was nonetheless, and that was the task before me.

I did at length (I think!) manage to recover the data -- that's the most critical thing -- but it took several IT weekends.  My bulk storage was not on the server, and the web stuff and ancient database stuff hadn't been modified in many years, so I was able to recover that from old backups.  The source code control was my big fright (indeed, that's how I found out about the fault -- I couldn't check in code), however one of the great things about modern distributed SCM is that the clones can be used to reconstitute the one you consider as the 'master'.

Resurrection

The obvious path is to just, yet again, install all the software, and configure it appropriately, and refer to the existing bulk data.  Had I chosen that path, I would not be writing this log.  That path would take a while to do, however I have decided to make my life harder and instead re-design the server's configuration.  There is a more modern technology called 'containerization' that is increasingly becoming popular for deploying services, so why not use this opportunity to explore that?

'Containers' are somewhere in between a chroot jail and a virtual machine.  There are several alternative technologies involved, but the most prominent one at present is 'docker'.

So I am setting out to reconstitute my server, but as much as possible containerize my former services using docker containers.  What does this mean specifically?  Well, I'm going to find out!

Next

Dicker with Docker