When old becomes Legacy

07 September 2011
Recycling old systems for re-use is one thing, but copying data off old systems prior to decommissioning is much better at showing the differences between a merely old and a truly legacy system. With reconditioning you replace components until it works, but with pre-decommissioning copying this is not really an option. In fact even partial disassembly might be undesirable if not impossible, and in any case you at least know there are no incompatibility issues by keeping everything together.

Today got round to copying all the data off a few systems I had stopped using but had yet to properly archive. My modus-operandi is to do an in-one-go copy of all data, ideally by cloning the partitions. This means I don't have to think about which data I want to keep, and in some cases these are systems that are uncomfortably close to dying anyway. Below are some of the hazards I met in trying to clone these systems.

Non-bootable CD drives

This is by far the biggest headache. For various reasons, the common way of making a complete copy of a system involves booting from a LiveCD (or specialised rescue CD), rather than using the installed operating system. The primary reason for doing this is that copying a hard drive is a lot easier when it is not mounted, as you simply don't have to care about stuff like active system files (Windows is particularly picky about these).

The headache comes because in the past many CD-ROM controllers did not support booting, and it was particularly common with SCSI-based CD-ROM drives I tended to use prior to the mid-2000s. Can't remember what performance reason attracted me to SCSI, as they were definitely no cheap option. To make things even more complex, even some on-board EIDE controllers did not support booting either, so I ended up having to fiddle with a load of EIDE cables in order to plumb in a bootable CD drive.

At the time these old systems were built bootstrapping boot floppy disks that automagically sorted this out, but these days you likley do not even have a production system available that can prepare the boot floppy. And that assumes you can find a suitable floppy image in the first place - I tried SmartBootManager, but that didn't recognise either my SCSI nor my on-board IDE-RAID controller.

Floppy drives

I no longer include 3.14" floppy drives in system I build, and neither does basically anyone else, but it is still surprising how many tasks become a massive headache without them. BIOS upgrades spring to mind, as most of these need to be run from DOS, and most people don't exactly keep a stack of empty USB sticks like people used to keep a stack of black floppies. Not sure of exact dates but there seems to be a significant gap between when floppy drives stopped becoming common, and when booting from USB became at least semi-universal.

EIDE/SCSI ribbon cables

Bulky as hell, particularly if like me you only put one device per ribbon cable (EIDE supports 2, and SCSI supports something like half a dozen). It is a pain up the arse to wade through a case full of these cables, and I certainly don't miss the master/slave/select jumper settings. Oh, and there is something unholy about having to unplug them by pulling them by the cable.

BIOS drive capacities

Inability to support hard drives above a certain size was a common problem with systems from circa 10-15 years ago, and quite often BIOS updates that rectified them did not increase the capacity limits by very much. I think this was partly due to hacks to get around CHS limitations and patchy support for LBA. Bit of a nasty shock when you picked up a 160GB drive (80GB ones are starting to become hard-to-find) and then found out your system didn't get on with it.

File size limits

In one case an old Linux box, rather surprisingly, recognised my USB memory stick. However when I tried tarballing my files it complained about file size limits when I tried copying the tarball onto my USB stick.

Dead CMOS batteries

A major pain up the arse for systems that might either be unplugged or suffer a power-cut. One system I have dealt with required the CPU speed & type to be manually set in the BIOS, and would not boot up otherwise. Even more of a headache with systems that have multiple hard drives, as the wrong one might be classed as the boot drive.

Slow (possibly dead) Ethernet

Gigabit ethernet is fairly standard these days, but the systems I was archiving were only equipped with Fast (i.e. 100Megabit) Ethernet adapters. These in practice can only shift 9-10 megabytes per second, so it takes a bit under 2 minutes per gigabyte. An annoyance optimal, as it is long enough that it consumes a fair amount of time, but not quite long enough just to leave it running overnight. To be fair some worn out hard drives don't react well to being read at full whack for long period of time, so having a deliberate bottleneck (e.g. by using in a non-gigabit switch) might actually be desirable.

One particularly awkward case was a dual-boot Linux install that fell into disuse prior to a network card upgrade, so the Linux install had no way of communicating with the outside world. And it was one of the systems that did not have a bootable CD drive..

Cloning vs. rsync

As a general rule, cloning is what you use when hard drives are either in a very good, or very bad, condition. For drives in good condition, cloning it means you have an identical copy and hence (by definition) the maximum amount of information (especially meta-data).

For drives (particularly FAT32 based ones) that have had quite heavy use, there is an accumulation of bad sectors that cause utilities like dd to abort, but have yet to cause problems for the filesystem in use on the partition. I have also come across cases where the semi-random accessing of a filesystem copy is better for drives that are at death's door, which is partly down to not copying unused disk sectors. Rsync is the bets thing for this, as it tends to preserve most of the date-stamps, and is good at making sure you've got all your files should copying be interrupted.

Of course if an uncleanly dismounted filesystem resides on a faulty hard drive (a case I had 2 years ago), you might not be able to mount the filesystem. In this case you have clone it, usually with a specialist tool such as ddrescue designed specifically for the task.