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.
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)