[Gb-ccb] An external CCB USB connector?

[Martin Shepherd]

On Tue, 22 Nov 2005, John Ford wrote:
> In reality this is how all network administration is done.  Boot to
> single user mode, mount the filesystems read-only, enable the
> networking, and dump the filesystem(s).

Except that when dumping the root filesystem one usually does this
with the root filesystem read/write, to allow the dump program to
write to /etc/dumpdates, just before it exits. One can get around
this, by telling dump to write this file on a different filesystem,
and then manually copy it back after remounting root read/write, but
nobody seems to actually bother to do that.

The reason that I want to be very careful is that whereas normally if
one has a bad backup of a desktop system, one can simply install a
more recent version of the operating system, this could be disasterous
for the CCB, since updates to the Linux kernel often significantly
change the device-driver interfaces, in non backwards-compatible ways,
and this could force us to rewrite the CCB device drivers.

What I think that we should do is ASAP make level 0 dumps of the root
and boot filesystems from the current CCB, and keep these
indefinitely, as master backups. After making these backups, they
should be restored onto the other CCB disks that we have, to ensure
they all start-out looking identical, with an /etc/dumpdates file that
has the date of the master backup. Thereafter, whenever a change is
made to a given CCB, we should propagate this change to the other
CCBs, either by repeating the modification verbatim, or by using the
rsync command. Having done this, we should then make incremental dumps
relative to the fixed master backups. The combination of the master
backups, and the most recent incremental dump, will be kept both for
disaster recovery, in case a microdrive has to have bad blocks
repaired, and for initializing replacement microdrives, whenever a
microdrive dies completely.

We should also keep precise notes of everthing that has been done to
the CCBs since the master backup was made, just in case we need to
redo everything from scratch, from that point. For example, if we
installed a patch to ssh on all of the systems, and only later, after
updating the incremental backup, found out that that patch also
contained a virus, then we would need to restart from the master
backup. Obviously, if there is room, it would also be good to keep a
few historical copies of the incremental backups, so that we don't
have to go back quite as far, after such an occurrence.

> What we *really* need to be sure of is that we have a complete backup
> of all the files that we modify from original, and not necessarily the
> whole operating system.

We need a backup of the whole operating system, as a base, because we
can't be sure that the Fedora Core 4 installation files and patches
will still be available on the net at a later date. Although I could
download the Fedora Core 4 installation ISOs, and burn them to CDs,
writable CDs don't last forever, and we would also need to figure out
and make backups of whichever RPMs were installed when I ran "yum
update" after the installation. It would seem easier to simply keep a
master backup of the current system, so that we never have to start
the installation from scratch.

Martin