[bct] Re: Backups

  • From: Steve Matzura <number6@xxxxxxxxxxxxx>
  • To: blindcooltech@xxxxxxxxxxxxx
  • Date: Sat, 20 May 2006 03:00:35 -0400

Mary and Kelly, you're both solid gold on your backup strategies.  I
might add one item, which would give you even more space, and that is,
to compress files or directories and just store the compressed files
for expansion or extraction when you need them.  Unfortunately,
neither SmartSync nor Synchro Magic are capable of compressing before
backing up, or using a compression program such as WinRAR or PKZIP to
do it for you.  The ideal software solution would be to take a program
like SmartSync or Synchro Magic and add on a feature that could use an
external file compression program with user-supplied parameters to do
exactly what I just explained.  For example, I'm an Agent user, not an
Outlook user, and Agent does not name its database files where it
holds messages with real names like Outbox.DBS.  Instead, they're all
eight-digit numbers and some extension (I can't remember offhand and
am too lazy to look at this hour), but what I would prefer is to
compress the entire folder where all the message files and database
master file reside, rather than copying the individual files, which
can get pretty big if I leave a lot of messages hanging around.

The problem with doing things this way is that you don't have any
control of deleting old or non-existent files unless you re-create the
entire archive, which, of course, you could very easily do by deleting
the old one first, then make the new one in its place.  If you're
handy with writing batch programs, you could certainly whip one up to
do this for you, then stick it in the Windows Task Scheduler to run
before SmartSync or Synchro Magic runs.  Of course, they could run
concurrently, but that presents problems of its own.  Firstly, any
archive (.ZIP, .RAR, .ARJ, etc.) should be as contiguous as possible.
If there are two job writing to the backup disk running concurrently,
files will be fragmented. Of course, you could defragment the drive on
occasion, but this presents its own possibilities for problems, such
as, what if the system crashes in the middle of the defrag?  THen
you're truly and totally left holding a very empty, very unuseable
backup drive!

The other problem with running jobs simultaneously is, of course,
performance.  Windows is not a multi-threaded multi-tasking operating
system, as much as Microsoft or others would like you to think it is.
What makes it appear to be multi-tasking is its speed (such as that
is).  However, given what backup jobs do, which is mainly read a lot
and write a lot, having two of them running concurrently could
actually take longer than running them back-to-back.

The other thing which neither of your otherwise excellent messages
addressed is the subject of recovering or re-creating a system disk or
boot drive.  It's potentially a three-part problem, and unfortunately
I can only help with a solution for one of these parts.

1.  Partitioning:

Normally, when an internal drive is purchased, it comes with
formatting characteristics on it which mark the boundaries where the
drive writing assembly can be positioned to write on the physical
surface of the disk.  However, different operating systems and file
systems have different rules about how that data is to be physically
laid down on the platter inside the box.  You've no doubt heard of
such units of measure called blocks, tracks, sectors and cylinders.
Some of these are combinations of units of others, but there is
usually one standard measure, the sector I believe it is, which is
common to all drives. When a disk is purchased, there's usually a
piece of paper or a sticker attached to the outside of the disk which
tells how many sectors it contains.  Each operating system formats the
sector differently, holding a different number of actual bytes of
information.  All the sectors available for writing on a disk comprise
yet another unit of measurement called a partition.  By default and
definition, since new disks have no other formatting on them, they
come from the factory with one unformatted partition which takes up
all the useable space on the drive.  The problem is, with large drives
being, well, large as they are, lots of folks like to break them up
into multiple partitions.  Take a 200GB drive, for instance.  It might
be broken up into two or more partitions of differing sizes--40GB for
a boot and software drive, 60GB for office stuff, 100GB for audio
projects, and bingo, there's your 200GB drive.  Of course, each of
these so-called logical drives can be managed as if they are three
separate physical drives, but what happens when the real physical
drive--the 200GB disk in my example--needs to be replaced in case of
failure or you simply want one of a different size?  What's out there
to re-partition, or reset the boundaries between logical drives?

The de facto standard for drive partition management is called (what
else?) Partition Magic, and last I saw of it, was not very accessible.
It also did not have a feature in it which I would think would be
something pretty standard given what else the program does--the
ability to save partition information in a file on a floppy or CD and
use it to partition a disk automatically at another time without
having to answer a lot of questions.  Somebody please correct me on
this if I'm wrong, or if there's another, better, utility than
Partition Magic that's come along recently.  It would be great to just
boot a floppy diskette or a CD-ROM, have it play a short musical
sequence to let you know it was ready to go to restore your
partitions, you press ENTER, off it goes, and plays another musical
sequence to let you know it was successful, or not.  If it wasn't
successful, of course you'd need to get someone to read the screen for
you, but if you were running it on an already running system, using
the new drive as a secondary or slave drive, you could read it
yourself if your operating system and speech programs were already up
and running.

2.  Using a Drive Imager:

So now we've got our new disk drive re-partitioned (if we needed to do
so) and we have it installed back into the master position on the
drive chain. And now what?

Now is when we break out our specially-prepared re-imaging CD's which
we've previously made with a program such as Driveimage.  The nice
thing about Driveimage is that it can be used with speech to prepare
the setup for exactly what you want imaged, then it reboots, does its
thing, then reboots again and your speech comes back. When done, you
have a bunch of CD's (or now, of course, you can use DVD's as long as
you have a DVD drive that can be booted, which most can these days)
that you use to re-create that all-important boot partition.  In fact,
if you're fortunate enough to be able to have a running system on
which you can run your partitioner (should you need one) and your
drive imager, that's the best of both worlds, but the program called
Driveimage is pretty automated--you boot, press Enter a few times to
bypass the usuall warning screens reminding you of what you're about
to do, then off it goes, you change CD's or DVD's when it tells you to
and opens the drawer for you, and when it's done, your system is back.

When you use a drive imager, it's very important not to pick up every
single thing on the drive and image it. For instance, in the above
example of a 40GB boot partition, suppose you had 15GB of data
(documents, email, whatever) which you normally back up daily, weekly,
etc.  You don't need to include those directories in your imaging
process.  It just takes too long to create and restore. Better to
image a drive with as few data files as possible, then restore them
separately after your system is back up and running with your
preferred access methodology software (speech, Braille, lp, etc.)

3.  The JAWS Problem:

I've not had Driveimage long enough to know the answer to this one,
but it seems to me, knowing what I know about how JAWS authorization
works, that Driveimage might thing the JAWS key file is bad data
because of the scheme HJ/FS used in its creation, having to do with
non-standard sector sizes and such.  Be forewarned, I have not tested
this yet, but your JAWS may not be authorized after a system restore
using any one of the various drive-imaging programs out there.  Check
with the manufacturer of the one you want to test out before buying
(they usually give you a couple test-images to try before  you buy the
software) to find out if they can handle non-standard sector sized
files. If they can, you may have hit a good one. But of course you
won't really know until after the test restore is done and your copy
of JAWS either works or doesn't.

I hope this addition to Mary and Kelly's thoughts and techniques was
helpful.  BACKUP is very important, now so more than ever, since our
systems are now larger and more complex and, perforce, more difficult
to rebuild after diasaster.
Steve Matzura
Master of Disaster (Recovery)

Other related posts: