Backing up the little stuff

It's not just the databases and filers that need to be backed up

I harp on this from time to time, but I still hear (and deal with) the negative ramifications from a failure to back up the little stuff. It can be nearly as catastrophic as failing to back up the big stuff. Every IT shop should have had backups hammered into their heads long ago and should be performing GFS-or-better backups for all the servers and the data. If they're virtual servers, you're backing up the images: databases, apps, terminal servers, all of it. But I'd be willing to wager that a significant number of these shops hit all the big stuff but miss the little stuff.

So let's define little stuff. In no particular order, they are router, switch, and firewall configurations; firmware images for those devices; and BIOS and controller images for servers, blade chassis, and whatnot. These are the things that you rarely, if ever, need, but when you do, you need them more than anything else in the entire infrastructure. The hardware failure rate for routers and switches is perhaps less than servers, but hardware failure is by no means the only reason to suddenly need a backup of a router configuration file.

[ White paper: Centralized Data Backup and Your WAN. | Keep up on the day's tech news headlines with InfoWorld's Today's Headlines: First Look newsletter and InfoWorld Daily podcast. ]

There are a few free/open source ways to automate these backups, preferably to a server that itself is backed up. One of my favorites is the now somewhat abandoned Pancho. Although the latest release is four years old, it works on hardened fundamentals (SNMP and telnet) to pull full configurations via TFTP from a myriad of different routers and switches on a scheduled basis. The configuration file syntax is extremely simple and basically boils down to:

SnmpCommunity=rwcommunity
[LAB-6509-1]
IpAddress=192.168.1.2
[LAB-POE-24]
IpAddress=192.168.64.5
[LAB-WAN-1]
IpAddress=192.168.1.5

Voila. With Pancho run as a cron job, those routers and switches will now have their configurations archived in perpetuity.

Another tool for this job is RANCID, which actually takes Pancho several steps further and provides configuration change management when coupled with CVS or Subversion. It can even perform e-mail notifications when changes are made to device configurations, which can help immeasurably when trying to figure out why an entire wing of the building suddenly fell off the network. Implementing RANCID is more involved than Pancho, but it also does much more than Pancho. Either way, implementing a configuration backup plan like this should be mandatory for a network of any size.

As far as the other little pieces, like firmware updates, BIOS images, and whatnot, they need a home. I'm guilty of this one myself -- downloading firmware updates for a blade chassis, say, and then leaving the files on the desktop of whatever system I was using to perform the update. I then promptly forget about them, or even remove the system altogether if it was a VM. In the face of a failure or a need to reapply the firmware, the time saved by not having to relocate and redownload the right image can be extremely valuable. As we all know, navigating hardware vendor's sites looking for that one image file can be a chore. Also, trying to decipher the filename of the image can also be a chore, so keep a text-file list in the directory detailing what is what. Even better, add it to the IT wiki (you do have an IT Wiki, right?).

All this could be summed up with a simple "be prepared," but I've found that reminders like these lead to smiles after a catastrophe is averted rather than madness when it isn't. You can thank me later.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies