Return to Home page
Return to Newsletter page
|Vol. 19 No.1||Supporting PC Platforms||Newsletter:. Jan..- Feb.. 2003|
|Backing up your computer files
By Bob Wallace
Given a relatively lengthy discussion at our January 9 meeting on backing up one’s hard drive, this makes a good time to spend on how to go about that routine. Several ideas need to be discussed before getting into the nuts and bolts of backing up, however.
Most of us will purchase a computer already set up for our use, meaning we’ll take whatever default setups made for us by the manufacturer, or OEM. In most instances, the OEM will set up your computer with a single partition on the hard drive, meaning the C: drive for most of us. Using this default means backing up to some other storage medium.
For those who choose to tinker with the computer, you might choose to make a second partition on the hard drive, then install all programs on the "C" drive, using the "D" drive as the backup drive. Depending on the total capacity of your hard drive, you may choose to set aside 1/4 or 1/3 of that total as your second partition.
The alternative to this method is to use a diskette, tape or Zip drive to get back up your files. Computer systems will most likely continue to include a diskette drive as a basic part of the computer, whether desktop or laptop. Tape or Zip units will be add-on units for most of us, and most likely external units sitting beside our computer.
Files to be backed up from your hard drive to a diskette, tape or Zip drive will require a copy command. Copying files to a diskette will use the Operating System’s internal command to back up files from the hard drive to a diskette. Depending on the number and size of files to be backed up, you may require more than one diskette. Tape and Zip drives may have their own proprietary functions for backing up your files, along with their own restore functions, should you need that at some point.
For those who choose to partition the hard drive into C: and D: sections, use of the Operating System’s Copy function will get your files copied to the appropriate folders on the D: drive in short order, much quicker than copying to a diskette.
Locating the files you want to back up means knowing the file names and their location in a folder (the Windows name for it) or subdirectory (the DOS name). Depending on the programs you use to make those files, and the default location used by each program to store your files, your search may be relatively easy or somewhat difficult. MS-Word uses "My Documents" as its folder/subdirectory, which is usually located just off the C: Root Directory in older versions of Windows, and looks like this on your monitor:
For users of WordPerfect, your files will typically be found in this file area:
Other software programs may store your files in folders other than those noted above. If you are unable to learn the location of those files from within the program, you should be able to locate them by going to the Find or Search function, depending on your specific version of Windows, type in the file’s name and have the system check for its location. Depending on the total size of your hard drive, the search may take a few minutes.
Before getting to the copying of files to back up, whether to a second partition on your hard drive (the D: drive), to a diskette, tape or Zip drive, a quick discussion on the naming of your files. With the newer versions of Windows you can easily name files that run out to the 255-character limitation imposed by the Operating System if you choose. This is far different from the naming convention used by DOS and the earlier Windows versions in which filenames were limited to eight-plus-three characters with the "dot" between each portion of the filename.
If you choose to do so, you can easily name a file as "everything I ever wanted to know about California.doc" and have newer versions of Windows save it with that name. The problem you’ll face is copying that file to your backup location. Copying to the second partition on your hard drive would allow for that filename to be the same on the D: drive, provided it’s been set up for long filenames. In most cases, the diskette drive will not be set up for long filenames, meaning any long filename on your hard drive will be truncated by the Copy program to something you may not recognize right away, unless you tell "Copy" which filename you want on the diskette drive as part of the Copy command.
Putting it another way, copying "Long-Filename.doc" to "A:\Filename.doc" will change the filename as part of the Copy command only if you provide that filename as part of the command. Not providing it will find the backed up version of your file being named as "Long-Fil.doc" on the diskette by way of truncating the filename to match the 8-plus-3 naming convention.
This is one of the reasons – despite having the ability to put long filenames on files under Windows 98 Second Edition on Lois’s computer, or long filenames on files under OS/2 Warp 4 on my own system – for continuing to use the short naming convention for the majority of files we work with. There are times when that puts a mild strain on the old gray matter, but that’s one very good reason for that gray matter being there!
Naming files, then, becomes a matter of thinking about it first, then following a convention for naming that is consistent for all your files. Two of my brothers have the same set of initials, for instance, so letters being sent to John or Jim could be named as JAW and the date of that file as part of the filename, but then that would require checking into a file to see if that specific letter had been sent to John or Jim. By naming those files as JOHN0111.LTR for John, and JAW_0111.LTR for Jim, each has been given a unique filename that will be easily recognized on the hard drive, and easily copied to the backup location, regardless of which backup method is in use here. A similar situation could easily be in play with other people in our lives, but can be resolved relatively easily by giving a bit of thought to which filename is assigned to documents being saved on our hard drive for those individuals.
Thus far we’ve discussed the methods of backing up our files and the naming of files to make our backups reasonably easy to do, regardless of where we back up our files – second partition on the hard drive, diskette, tape or Zip drive. With all that behind us, let’s get down to getting it done.
Getting those data files backed up can be relatively easy and painless, if we give that step a bit of thought first, too. Copying data files from the C: drive to the D: drive, at least here on one or the other of our computers, would be done by making similar folders on that second partition to match those on the first partition. Copying from "My Documents" on C: to "My Documents" on D: maintains some consistency in the folder you look to for a specific file. Sure, you could easily copy those data files to something like "My File Backups from C" if you like, but you’ll have to remember that folder name each and every time you do your backups. Follow the KISS rule: Keep It Simple, Sonny."
The next step is easy. At least it would be for my purposes: edit a batch file that will do your backups on a daily basis, weekly basis, whatever routine you choose to follow. And keep in mind that all those COM, EXE, OVL, OVR and DLL files do not require backing up, as they belong to the programs you run. You should have their backup on diskette and/or CD. All you should have to back up with some consistency are those data files you work on with those programs. With that thought in mind, one of the reasons for learning which default filename extensions are used by some of the programs you’re likely to be using. Microsoft’s Word program typically uses the *.doc file naming and saves those files to the Documents" folder on your hard drive. Microsoft’s Excel uses *.xls and saves them to the same folder. Microsoft Publisher uses *.pub as the default; FrontPage uses several types, including *.htm, *.html, *.shtml and *.shtm. If you use FrontPage, check to see which of these is being used for your data files. Microsoft’s Outlook Express uses the *.eml naming convention.
WordPerfect 6.1 for Windows uses *.wpd (document), *.wpt (template) and *.doc (document), so here again you have to check the folder or subdir-ectory where WordPerfect stores your data files to see which extensions you have to account for while backing up your files.
Hang in there, we’re almost there. The next consideration is whether
you want to copy your data files as they are on your hard drive, or to use
one of several utilities that will archive them in an ARJ, PKZip or WinZip
format. If you have one of these utilities, you can compress those files
to some degree, thereby saving space on your backup medium, whether that
be diskette, tape or Zip drive. (Do not confuse the Zip
For anyone unfamiliar with the archive utilities, ARJ will make a compressed file with any number of data files stored inside that archive with usually the ARJ extension on the archive. PKZip makes the archives, PKUnZip extracts your archives, the archive usually being named with the ZIP extension, as will the WinZip program, although the two programs with ZIP as part of their name may have very different command line options to add, view or extract files inside a ZIP archive.
Once you make the decision as to which method you’ll use to store your data files – copy from "A" to "B" or compress in an archive – it’s time to get your backup media ready to go. For diskette backups, insert the diskette in its drive door and start the copy procedure. Backing up to a tape drive or Zip drive will likely require the use of proprietary commands for the specific program being used. Check your user manual or on-line help file.
My personal choice is easy: no tape or Zip drive in use here means
using the compressed archive method, naming the archives in a way that
will make sense a few weeks or months later, then adding files to the
point that a diskette will store the archive without running out of space
on the diskette. That’s 1.44-megabytes of space on a diskette which
allows for backing up a fair number of files, depending on the size of
each of those files.
This month’s meeting on January 9 had a very small turnout, perhaps due in some part to the weather. Not everyone enjoys being out in rainy wether, or right after a storm has recently passed through the Bay Area. A total of four showed up at the Burlingame site for our meeting. We cleaned up the space and left by 9:00 p.m.
Upcoming meeting dates for the rest of 2003 are as follows: February 13, March 13, April 10, May 8, June 12, July 10, August 14, September 11, October 9, November 13, and December 11. As this issue is being completed on Monday afternoon, January 13, there is no topic available yet on the club’s web site for the February meeting. You can check the club’s web site later in the month to find the topic for February’s meeting by going to www.sfpcc.org and clicking on Meetings.
Genealogy folks may have a problem similar to that of your editor with changes made to the FamilySearch web site within the past couple of months. The gentleman named George Wallace who was born in Scotland in 1817 and moved to Canada somewhere around 1840 or so has disappeared from the IGI listing that had shown him and four brothers, all born not far from a small village or settlement located about 15 miles from Aberdeen, the Granite City. Several telephone calls made this date have not cleared up exactly where he and others may have gone to, aside from an Elder at the Family History Center in Salt Lake City advising that the Mormon Church had recently removed their DOS library and replaced it with what he labeled as an Internet library. Only time will tell if they are able to match up listings in the older library with what is or isn’t in the newer version now on-line at www.familysearch.org, for those looking for former generations.
As noted earlier in this issue, naming conventions can be relatively simple and still be useful, provided one is consistent in the naming of files on the hard drive, and the manner of backing up those files. For the file that ends up becoming this issue of the SFPCC Newsletter, the naming has been kept to three letters, the underscore character plus the Volume/Issue number. For this specific issue, that name would be pcc_1901.ltr, the file then being saved in the same folder or subdirectory that includes a number of previous issues. Archiving would also be kept to as easy a name as possible: pcc_news.arj or pcc_news.zip, depending on which archiving program we choose to use for that purpose.
A major change in the computer setup around our office will be taking place shortly. Your editor’s wife purchased a Toshiba laptop late last year, that laptop soon to be her main system, just as soon as we’re able to get the bits and pieces necessary to set up a Local Area Network or LAN here, tying in that Toshiba laptop, one desktop system and an additional laptop to be added shortly for learning about Linux. This computer user believes in having a solid system with which to work while trying out something new. Changes will begin over the next few weeks, depending on schedules for other things like day job, football playoffs, hockey games and the monthly computer club meetings. Speaking of those monthly meetings, your editor almost lost one New Year’s resolution, that being to attend every meeting this year. The day job almost had night work on the night of the meeting, January 9, but weather prognostications managed to change the contractor’s mind about it. Wow, that was too close!
As is the usual manner of editing each SFPCC Newsletter, this issue was
put together on a desktop system running AMD’s CPU (133-MHz), printed on
an HP 693C printer and copied at Kinko’s in San Mateo. Yes, that 133-MHz
CPU is slow, but it isn’t that slow! CPU speed will be picking up a bit
later this month when several changes are made around here.
Return to Newsletter page