Last week I was sent by my work to do the Red Hat Certified Engineer (RHCE) course, which was a compressed 4-day course (cramming in 8 days worth of content into half the time).  It was bundled with the RHCSA certification at the same time.

Since my Microserver keeled over and died and I didn’t have a good backup in place, I was in search of a quick and easy way to back up the USB key on a regular basis so I could recover easily.

A brief discovery…  If you use a script to back up your Microserver to a mount point somewhere in your filesystem, then your updatedb database will keep growing and growing without bound.  This is bad if you’re using a USB key for your root filesystem (I went from writing a 1.5Mb updatedb database once a day to writing a 60Mb one before I caught it).

Just got around to doing this.  There’s a lot of logging that goes on by default on a Linux box, and every log message that gets committed to disk shortens the life of the USB key you’re driving your Microserver with.  As such, suppressing spurious logging is fairly important.

Whew, been a while.  I’ve been a bit slack with keeping up with my projects lately - too busy with other things.  However, I have a few updates.

Well, it only took three months, but the USB key I was driving my Microserver from went bang over the weekend.  It started accumulating a lot of errors, and fsck fixed the errors, but they just came back again.  Doing some analysis, I don’t believe that I was committing too many writes to the key - I only would have made under 1Gb worth of writes, and with a 16Gb USB key, there’s no way I should have committed enough writes to be able to blow the read/write cycle limit of even one block on the key.